Add Boostagram indicator to podcast:valueRecipient

[thebells1111]

A useful feature for apps would be the ability to show a boostagram enabled tag on the podcasts that are setup to read boostagrams. Something like this would suffice to indicate the recipient is able to view boostagrams.

<podcast:valueRecipient
    name="[name of recipient(string)]"
    type="[address type(string)]"
    address="[the receiving address(string)]"
    customKey="[optional key to pass(mixed)]"
    customValue="[optional value to pass(mixed)]"
    split="[share count(int)]"
    fee=[true|false]
    boostagram=[true|false]
/>

[dellagustin]

Pros:

• A more refined user experience - as an app developer I would only show the boostagram option if it is actually supported on the receiving side

Cons:

• Added complexity on producer and consumer side, as there are extra steps, you not only have to support it, you have to announce you do

General comment: Nodes will store the incoming TLVs together with the invoices in their own DBs, regardless if they are used or not be the receiver, so it is possible to actually start supporting boostagrams retroactively. As an node operator, you would be able to inspect the transaction metadata of past payments, and find boostagrams, among other information, send to you in the past.

[daveajones]

Good comments and ideas here. If we go down this road it makes more sense to me to put in a general “capabilities” attribute where future tech can be flagged/included.

Something like capabilities=“boostagram;royalty;lsat”.

It would keep from having a slew of new attributes.

[dellagustin]

Something like capabilities=“boostagram;royalty;lsat”.

I actually thought about that, but my lazy programmer brain liked the comfort of getting a boolean directly from the attribute.
I understand the idea of keeping the namespace more stable with a generic attribute though.

[brianoflondon]

Wouldn't we rather force boostagram decoding and surfacing to be an integral part of actually receiving funds?

It has to be the norm, if you're going to run your own node, you either need the technical skills to decode or more realistically, hopefully, someone will do the work to package up a decoder for Umbrel or other node options.

[dellagustin]

Wouldn't we rather force boostagram decoding and surfacing to be an integral part of actually receiving funds?

I would not make it a forced feature - maybe a podcaster does not care about receiving messages with boosts and this would be her/his/they way of saying "don't bother writing, I'll not read it".

[brianoflondon]

Force was perhaps the wrong word, encourage is what I meant at the tech level.

Obviously if a given podcaster gets them and ignores them, I suspect that podcaster won't get that many more!

I don't think this is a bad idea, infact I could put it into the majority of value blocks in the index right now because every one of the value blocks which redirect to Hive via v4vapp receives boostagrams by default already.

[jooray]

Before we finish discussing 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.