Proposal - Add visibility Attribute to <podcast:value> Tag

[MerryOscar]

There is no explicit guidance in the <podcast:value> tag around whether Boosts should be public or private.

Since there is no specific mention in the spec of the private nature of Boosts - I don't see why it's a problem for apps to display them publicly.

However I do think it's important that both listeners and podcasters have choice over what happens.

• For Listeners - Fountain has a toggle option in the settings to switch boosts to private. Other apps should offer the same if they want to show Boosts publicly.
• For Podcasters - We need a way for podcasters to signal what they want.

I propose we add a visibility attribute to the <podcast:value> tag which could have either public or private. Of course defaults matter here but I think the attribute should be optional and if it's not set apps should be able to decide what to do.

Happy to create a PR if we get consensus this is a good idea.

[thebells1111]

Ultimately, any tag is a means for a podcaster to share his content with the world, and dictates what content he wants shared with the world. We assume if he doesn't have a chapters tag, then he doesn't want chapters, and shouldn't open up a means for listeners to create audience created chapters, no matter how cool it is. Even if it would be cool for the audience to share in the creativity of the podcast, ultimately, that's the podcasters choice, so the lack of a tag indicates they don't want the content attached to their feed.

Since we're talking about value though, we have to determine what we think the podcaster assumes with a certain tag, and since most podcasters don't read the specs, we should try to understand what is most intuitive to most podcasters. I argue that most people assume a Boost is similar to a Direct Message, thus a private message to the podcasting team (value block). If this assertion is true (and that's really what we need to determine when deciding the default for visibility), then I think the default should be private, and the podcaster has to make the conscious choice to opt into public.

[adamc199]

Two changes fixes the 'lightning comments' for me.

1. Label them Boostagrams, not Comments. They do not have the properties of comments. The are simply not the same.

2. Boostagams are being surfaced in many ways, this is an agreement between podcaster and audience. This would surface as a hierarchical list of boostagrams. Not threaded like comments. This flag would signal this agreement has been made and it is ok to display boostagrams publicly.

[thebells1111]

Brainstorming the problem based on @adamc199 comments.

1. I agree Boostagrams and Comments aren't the same.
2. If an app wants Boostagrams to made public, then a url needs to be provided so an app can display all of the Boostagrams.
3. lightning:comments already provides a url, but per point 1, that tag should return a comments thread.
4. perhaps a new tag similar but different called lightning:boostagrams which
   a) indicates the podcasters wants Boostagrams to be made visible in the app
   b) provides the url in which to retrieve the Boostagrams

The podcaster would have to have some sort of service that aggregates the Boostagrams for a particular episode and returns the appropriate data structure for all of the apps to parse, but Fountain has already solved that problem for podcasters using a Fountain wallet.

This also opens up a neat opportunity for the boostagrams.json file to contain other things in it, such as top ten boosters of all time, a running total of value the podcast has received, pledge drive goals/totals, etc.

[MerryOscar]

I argue that most people assume a Boost is similar to a Direct Message, thus a private message to the podcasting team (value block).

@thebells1111 I'm just not sure this is true. I think the tools / services to publicise boosts just haven't been built yet. My assumption was always they would end up being public. Again it's all about choice and if a podcaster wants them public this should be allowed - hence the need for something like the visibility attribute to enable choice and reduce confusion.

---

Label them Boostagrams, not Comments. They do not have the properties of comments. The are simply not the same.

@adamc199 up until now you're right that boosts have not had the properties of comments. But does that mean that they can't be integrated? Again it should all be about choice - but if a podcaster chooses to let their listeners to reply to each other's Boosts - is that wrong?

---

This flag would signal this agreement has been made and it is ok to display boostagrams publicly.

@adamc199 agree this is why the flag is needed and Fountain will respect it and not show Boosts publicly if instructed to by the feed.

[thebells1111]

I'm just not sure this is true

@MerryOscar I'm also not sure it's true. That's my assumption and intuition, but everyone's different, and I could be very wrong on what most people find intuitive and expect the default to be. I hope we can get some more input so we may have a better feeling of what most people expect the default to be, because my only concern with visibility is what the default value would be. I personally don't care either way, I'm just trying to look out for the podcaster as much as possible and make this intuitive for them.

[adamc199]

up until now you're right that boosts have not had the properties of comments. But does that mean that they can't be integrated? Again it should all be about choice - but if a podcaster chooses to let their listeners to reply to each other's Boosts - is that wrong?

I didn't say it is wrong, but they are not comments. I may choose to show boostagrams myself, but I also want comments.

I've stated my case: Boostagrams should be labeled as boostagrams. Surfacing should be at discretion of the feed.

[MerryOscar]

I didn't say it is wrong, but they are not comments. I may choose to show boostagrams myself, but I also want comments.
I've stated my case: Boostagrams should be labeled as boostagrams. Surfacing should be at discretion of the feed.

@adamc199 ok makes sense - if we can get this attribute added I think we'll be good 👍

[MerryOscar]

I'm also not sure it's true. That's my assumption and intuition, but everyone's different, and I could be very wrong on what most people find intuitive and expect the default to be. I hope we can get some more input so we may have a better feeling of what most people expect the default to be, because my only concern with visibility is what the default value would be. I personally don't care either way, I'm just trying to look out for the podcaster as much as possible and make this intuitive for them.

@thebells1111 yep I'm not sure if my assumption is true either! I think if we can add the visibility attribute we can give podcasters the choice - but by making it optional we give apps the freedom to experiment - which in my view will push Podcasting 2.0 forward even if sometimes we get things a bit wrong.

[harvhat]

boosts and boostagrams should to be public, else they are just "donation buttons", use a funding tag for that I say.
The real question is rather they'd are anonymous or not, might want an attribute for that.

[SpencerPearson]

I feel boostagrams evolved naturally as the lightning equivalent of the PayPal donation note but without the middleman and standardized fee of PayPal.

There is no obligation for the podcaster to read a donation note, whether it be PayPal or Boostagram. They certainly are not surfaced to the audience by default, and if they are surfaced to our audiences thus far it has been by explicit choice and has been discussed on our shows. I can think of a few examples:

On No Agenda often people request anonymity in donation notes. Other times there may be a "no need to read this part on the show" section. Impossible if donation notes were programmatically surfaced by default.

On Angry Tech News producers are thanked by name but no notes or donation levels are read.

I recall a Podcasting 2.0 episode in the early days of the boostagram that mentioned there was a "rude boostagram" on Podland that was not read. On the other hand Podcasting 2.0 have chosen to read all their boostagrams, even the rude ones. Not possible to make that choice if the boostagram is revealed automatically.

Helipad surfaces boostagrams automatically but privately, to the node operator.

The IRC bot and Boost Bot have also been built in a way that the podcaster must explicitly activate these services to surface boosting, and the audience is made aware how and where these surface.

I think certain audiences have come to expect the boostagram to appear in certain places like IRC or fedi, but ultimately the podcaster should be able to direct how this goes down and opt in at the level of surfacing they wish the boostagrams to have.

[adamc199]

Agree. And if they are surfaced, they are "Boostsagrams", not " Comments"

[theDanielJLewis]

I like the points this discussion is raising.

I think as a means of financial support, Boostagrams should be assumed private by default. This protects both the privacy of the listener and the private financials of the podcaster.

In consideration of privacy policies and privacy laws, I think the safest thing is always to build in automatic privacy, allowing people to opt-in to tracking/publicizing. But, of course, I expect the podcaster to receive the information and handle it properly.

[cottongin]

As a listener I would enjoy if this functionality were implemented, and in such a way that it could be overridden per boost (I realize apps would need to also surface this).

Some apps surface splits which enables me to exclude nodes/bots that automatically relay things publicly but nothing is really obvious about what that does or means currently; something like this proposal I think works a great deal of the way towards addressing this.

[daveajones]

@MerryOscar Could this be folded into #466 ?