Proposal: <podcast:valueRecipient> boostagramMessage attribute for denoting which recipients should receive the boostagram message

[mitchdowney]

This attribute would indicate to apps which recipients should receive the boostagram text message when the user sends a boostagram. The expected client-side handling I'm imagining would be:

1. If no recipients have boostagramMessage set, assume all recipients should receive the message.
2. If all recipients have boostagramMessage set, send the message to all recipients.
3. If only some recipients have boostagramMessage set, only send the message to those recipients.

I imagine apps may still allow users to send boostagram text messages to the other recipients, even if boostagramMessage is set, so this proposal isn't intended to address security / privacy issues, but rather a default that the podcaster is asking apps to follow.

I don't have a preference on the name for it if anyone has a different naming idea. Also, I don't think this is a high priority namespace proposal, unless there is enough podcaster demand for it.

[theDanielJLewis]

I like your thinking, I only don't like this feature.

First, I hadn't even thought about who receives the messages until you brought this up. So thank you for highlighting that!

I don't think it would be good to automatically pass messages to third parties like this. It seems like a violation of privacy and trust in some ways.

Maybe a different fallback approach would solve my concern:

1. If no recipients have the attribute, assume only the largest share recipient (or multiples, if they're near equal) or channel recipient receives the message.
2. Otherwise, send the message to only those with the attribute set.

Even if that major concern could be resolved, I think this kind of feature would complicate UIs and confuse or frustrate audiences.

As for naming the attribute, how about msg or receivesMessages?

[mitchdowney]

Maybe a different fallback approach would solve my concern:

1. and 2) are reasonable...although I think if we did 1) today then it would break people's integration with BoostBot, which the podcaster adds to their value split when they deliberately want to broadcast boosts to ActivityPub. If we did 2) obviously no one would receive boostagram messages.

Even if that major concern could be resolved, I think this kind of feature would complicate UIs and confuse or frustrate audiences.

I agree if we render this in the UI it would be excessive and confusing. I'm thinking this would be handled in the background without displaying to the user (unless in an advanced mode).

As for naming the attribute, how about msg or receivesMessages?

I like both of them better than boostagramMessage. I tend to go with more descriptive naming conventions like receivesMessages, but if people are comfortable with msg that works for me too.

[theDanielJLewis]

As a host, I would not want my messages going to other value recipients unless they're official cohosts. As a listener, I wouldn't want multiple outsiders having access to messages I send the podcaster.

[jooray]

Agreed with @theDanielJLewis

Before we implement this, I would just add to the specification that recipients with fee=true should never receive boostagram messages. For example BluBrry's PowerPress automatically adds their recipient to the RSS fee (which is OK, it's a free plug-in, they are allowed to do that), but I would like clarity that apps are not sending the boostagrams to parties with fee=true set.

[daveajones]

I agree with this.

[daveajones]

Generally speaking, if it's not a "fee" split, then you would (most of the time) like the message to go there. It seems to make more sense (at least to me) to have in the specs to disable message text to fee recipients and then have an attribute to disable messages on certain recipients rather than an attribute to enable them.

[keunes]

I imagine that could be quite annoying if you set your splits at the level of episodes. You would potentially have to set 'no messages' every time on some folks that support you in the background but shouldn't receive the message.

I think the 'privacy' principle should prevail here.

[Alwin-Stockinger]

This creates problems for services like ours (Conshax), it makes sense for us to be added as a fee. But we still need to get the messages so that we can display them to the podcaster.

[mitchdowney]

Maybe the msg attribute should be a boolean? If true, include message. If false, don't include message. If missing, then apps decide how to handle it.

[adamc199]

I disagree with apps making these decisions.
The feed is the source of truth.

[mitchdowney]

Yes, but what about the case where the podcaster hasn't specified one way or the other which valueRecipients should receive boostagram messages?

I lean towards defaulting to all recipients receiving messages in that case, because as I understand it boostagram messages are publicly viewable without exception, so assuming the most private handling (not sending boostagram messages to recipients unless specified in the RSS feed) would create problems without much benefit.

[adamc199]

I perceive Boostagrams t be open and can stay that way everywhere. A flag to allow an app to display them is all I feel is needed, this would allow apps like fountain to display them if flag is true.

I've never had a complaint about publicizing a Boostagram. Ever.

Everything else is complicated and appears to be a solution looking for a problem.

The V4V format explicitly calls for a feedback loop of reading the Boostagrams on the show. Privacy is not to be expected and has not been an issue in my experience.

[theDanielJLewis]

On review, I now prefer @mitchdowney's fallback proposal in his original post.

And I still think messages should not go to fee destinations unless explicitly set.

Are boostagrams technologically public? I'm thinking of that option of Patreon that allows someone to hide how much they're earning and show only how many patrons they have. I wonder if this thread can support that kind of privacy.