Proposal: <podcast:metaBoost> tag and API standard

[agates]

This proposal is to add a new <podcast:metaBoost> (Boost Metadata) tag which specifies an API where the podcaster would like the application to send payment metadata to, allowing separation of the payment and what's currently sent via the keysend TLV record.

This API would be payment agnostic and support methods of verification that the payments are legitimate.

I propose verification be done via something like the JSON Payment Token (JPT), albeit updated to be based off an JWKS signing method where an issuer can sign a the payload with a well-known public key. This way, providers such as fountain and alby can provide verifiable messages with minimal performance impact. A provider such as strike may need verification via their API if they are unwilling to participate.

Similarly, I will be working on a version of JPT to support Monero.

A proposed (to be debated) OpenAPI spec can be found here. (paste into https://editor.swagger.io/ if needed)

Lastly, we can always delegate payment verification to some time in the future via the "trust me, bro" method.

Parent

  <podcast:value>

Count

  Single

Node Value

  The HTTP endpoint where the MetaBoost API is defined.

Example

<rss xmlns:podcast="https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md" version="2.0">
    <channel>
        <title>test feed</title>
        <description>Bare minimum test feed</description>
        <link>https://podcastindex.org</link>
        <language>en-US</language>
        <pubDate>Mon, 02 Dec 2024 23:00:00 GMT</pubDate>
        <image>
            <url>https://example.com/images/pci_avatar-massive.jpg</url>
        </image>

        <podcast:value type="lightning" method="keysend">
            <podcast:metaBoost>https://metaboost.example.com/</podcast:metaBoost>
        </podcast:value>
       
    </channel>
</rss>

[brianoflondon]

This sounds sensible. This would fit easily with what I built years ago to receive payments for all Hive users.

The only problem is the massive bloat in work for the sending app which will have to call different api end points for each recipient in a block.

[agates]

The more I think about it, the metadata should be a singular set of payment proofs for all recipients. Each one being a single "boost" or "user initiated payment event" (to include what's now known as streaming sats). And that API implementation would be more efficient.

[thebells1111]

I like that this spec is payment method agnostic. I'd like API spec to include some sort of url (or some other query method) that is returned back to the app in response to sending the metadata. The app can then forward this query method to each of the splits through some other method that is specific to each payment method. So in the example of BOLT 11, the url that returns the metadata could be included in the comment field of the BOLT 11 invoice request, and each of the splits can fetch that data if they so choose.

[agates]

@thebells1111 is the get by id endpoint not sufficient? Can you provide an example?

[thebells1111]

Returning an id that can be used to look up the payment info is more than sufficient.

Can you walk me through a simplified work flow explanation (it helps me to understand when I'm able to fully explain something), e.g.

1. Listening App sends payment to Main Podcast Wallet
2. Main Podcaster Wallet sends back successful payment
3. Listening App sends Metadata to Payment Metadata server with proof of payment
4. Metadata server stores metadata then returns id
5. Listening app can now send payments to all other splits and include the Payment ID as a comment for other splits to use the get by id endpoint to retrieve the metadata.

[agates]

You have the gist of it, except 5 is a little unnecessary because any app will be able to get any boost metadata for any episode under the provided API.

I need to write a more full walkthrough for the guys at XMRChat anyway so I will do that separately and @ you when I have it.

[theDanielJLewis]

I like the purpose of this, but I think this is exactly the kind of thing that should go into the podcast's webhook/events/activitystream through a universal tag and endpoint instead of a value-specific tag and endpoint.

[redimongo]

It's not a bad solution, the only thing I see is this may not fit with what others are doing. For PodToo we are currently coding a boostagram live app (it will be open source and free to use and you don't need a podtoo account) that uses the options.json file with a field called boostCallback since technically anything can go in the options.json file we believe that it's best to keep it in there.

Also that boostCallback allows the user to send amount & comment to the invoice generator and once paid the comment is stored in the local DB for the creator of the podcast, they can select if they want it to be public or not.

How we stop the comment being attached to the invoice?

In our code we follow the L402 method (https://l402.org), we store the macaroon and purchase invoice data in our db, and then when the payment is made the podcast app can either send us the confirmation (preimage + macaroon + additional data like voicemail or video message) the only thing linking in the lightning wallet is an internal db ID so this allows us to then do lookup with the database later on.

How does it stop other splits from receiving the boost comment?
For best practice we recommend that apps only send the comment to the largest split, if there is an even split then the comment would go to all.

What if a app doesn't send the preimage?
If the boostagram app is running it will do 5 second pings to your wallet and check if a payment has been confirmed or not, if it has not you wont see the comment, if it has you will see the comment - this removed the need for the app to send the confirmation however saying that the app won't be able to attach a voice message or video message if they don't use the preimage and macaroon and only the original message that was sent with the invoice generator will be shown to the creator.

How do you get around character limits
As comments are NOT attached to the wallet transaction the comment length can be unlimited.

What if I want my comment to be public?
This could be achieved by sending &public=true with the boostCallback

What if I am a creator and I want my comments to appear on Nostr Events or AP?
This can be achieved by linking your podcast Nostr npub - I am looking at how we can allow the podcast app to say the message was saved on Nostr event and Boostagram to fetch it from there instead of it being attached to the DB (still early stages, but downside is if the nostr relay server goes down your messages are lost). This will be the same with AP servers but still early days.

Can my Boostagram + Boosts be public for other apps to lookup?
Yes, with the Boostagram LIVE app you will be able to click a setting that says make all public, this will output a search JSON which can be included in each item level of your podcast it will look something like this.

https://(domain.com)/boostagramLive/public/(GUID)/comments

This will return the comments/boosts made by everyone for that podcast episode.

What do people think about this?

[agates]

I don't see how what you're doing can't work with a standard metadata API that's payment agnostic.

However, most of what you're describing seems application- and payment-specific.

[redimongo]

The difference between the way I am proposing rolling it out, utilises the BOLT11,BOLT12 preimage signing capability (which we also use already for SecureRSS - launching very soon), this means that we don't need an additional signing tool like you have used above.

Additionally if a user wants to include the comments in their Podcast item level this could be done via the contentLink tag #614 which has already been approved - This removed the need of adding an additional tag.

Up til now, the sender (KeySend) has handled comments on their end without the need to add it into the RSS feed. From my side I would think if we can keep it that way, why not?

Now if there is a technical reason we can't, please let me know as then what your proposing might make a little more sense to me.

[agates]

I don't know enough about it to say. If we can include it as an option for the payment proof, I won't object. But this API specifically is payment agnostic.

[agates]

My intentions are supporting other payment methods. I am working on Monero.

[redimongo]

Awesome, well I would be more than happy to jump on a call with you and see how we can make it work.

I agree we need more than BTC so happy to at least talk about other coins.

That's if you're up for a call.

[francosolerio]

This proposal is to add a new <podcast:metaBoost> (Boost Metadata) tag which specifies an API where the podcaster would like the application to send payment metadata to, allowing separation of the payment and what's currently sent via the keysend TLV record.

@agates when you say "specifies an API" do you mean every different podcast can support a different API as a different set of functions with different parameters and results, or you mean every podcast specifies a different "API endpoint" and every endpoint implements the same exact API with the same functions, parameters and result values, just at a different URL?

[agates]

This is the latter. The podcast brings their own API endpoint with the exact same standard. This way, they own their own boost metadata and to the app it's an endpoint following the same functions at a different URL for any given podcast.

[thebells1111]

This is exactly what I want. The podcaster alone gets to decide what happens to the message tied to the podcast. If you're in the value block, it doesn't mean you're privy to the message, just the split. If the podcaster wants to let you see the message, there can be some other way for that to happen, just as a callback in the options.json file for each split, but that's handled on the podcaster's metaBoost server. This tag is simple and elegant, and still gives control of the message to the podcaster alone and it remains true to one of the central tenants of RSS, which is THE FEED IS THE SOURCE OF TRUTH.

It's also great for the app because they're already going to have to make far too many calls to simply send a payment, then add a message call for every single recipient. Nope, one call to one api with all of the metadata for the boost, and the podcaster can decide what they do with that data. Want to post it to activity stream? Do it from your server. Want to send it to nostr? Do it from your server. Want to share it with a third party? Do it from your server. The app only has one concern, get the metadata to the server the podcaster tells it to.

[redimongo]

But we already have the ability to do this, with ContentLink tag #614 which has already been approved - This removes the need of adding an additional tag.

We can link the comments at the item level using that tag contentLink like domain.com/public/(EPISODE_GUID/comments This allows the app to load all the public comments for the episode.

Up til now we have used keysend, and its been on the sender side.

Bolt11 & Bolt12 gives a lot more control than people think.

For example say I want to send a comment to you I would use your callback with /callback?amount=10000&comment=(The comment - as long as you want)

(Also this can be a POST, which would open up file uploading ability which would allow voicemail and video messages)

In the code you would NOT attached the comment to the invoice but instead store the comment in your local database, this database _id gets attached to your lightning wallet in it's comment section instead.

then when the preimage is signed or your cronjob check if payment is made.

example code:

require('dotenv').config();
const { Wallet } = require('nostr-wallet-connect');
const { MongoClient } = require('mongodb');

// Load environment variables
const nwcUrl = process.env.NWC_URL;
const mongoUri = process.env.MONGODB_URI;

// Replace with your BOLT11 invoice and comment ID
const bolt11Invoice = 'lnbc2500n1p...';
const commentId = '60f5a3b5c9d3b41f8a7d9f21'; // Example ObjectId

async function checkInvoiceAndUpdateComment() {
  const client = new MongoClient(mongoUri);

  try {
    // Connect to MongoDB
    await client.connect();
    const db = client.db('mydatabase');
    const commentsCollection = db.collection('comments');

    // Initialize the wallet with the NWC string
    const wallet = new Wallet(nwcUrl);

    // Check the invoice status
    const result = await wallet.checkInvoice(bolt11Invoice);

    if (result.paid) {
      console.log('Invoice is paid:', result);

      // Update the comment in the database to mark it as paid
      const updateResult = await commentsCollection.updateOne(
        { _id: commentId },
        { $set: { status: 'paid', paidAt: new Date(), preimage: result.preimage } }
      );

      if (updateResult.modifiedCount > 0) {
        console.log('Comment marked as paid in the database.');
      } else {
        console.log('No comment found with the specified ID.');
      }
    } else {
      console.log('Invoice is not paid yet.');
    }
  } catch (error) {
    console.error('Error:', error.message);
  } finally {
    // Close the database connection
    await client.close();
  }
}

checkInvoiceAndUpdateComment();

This allows us to seperate the comment section from the lightning wallet while using the lightning wallet as proof that the payment was made.

By using contentLink inside the item level we can then do a look up for matching comments with that episode GUID.

Now how do we mark a comment was for an episode, we can do that in so many ways. I would recommend adding an additional parameter to callback called &episodeGUID and then the app can send that along with the invoice generator.

This allows the podcast creator full control over what happens to the comment. Clearly it would require making a custom callback URL that is designed for podcasting - which is currently in development.

[thebells1111]

contentLink was initially proposed in the context of liveItem to allow podcasters to provide external destinations where the same livestream can be consumed.

contentLink Attributes
href: (required) A URL pointing to an external platform representing the same content as the parent tag.

contentLink has nothing to do with this. You're suggesting repurposing a tag that is to drive a listener to an external location to consume content to one for an app to send metadata. Although the structure of the two tags are similar, it's not the purpose of contentLink.

[thebells1111]

Also, you're unnecessarily complicating what can be an extremely simple tag. A podcaster wants his boost data, this gives an app a place to send that boost data. It's that simple. I'm not saying any of your ideas aren't without merit, but they can all be accomplished as a separate thing by the podcaster on their own server. I don't give a flying BOOST what the podcaster does with his data, store in a database, post it somewhere as a comment, I don't care, it's none of my concern as an app. I send them the metadata that traditionally went in a TLV, they do whatever they want with it. If they want to share their stored comments, there's already a tag for that, socialInteract they can post their boostagram comments to whatever method they already decided in their socialInteract tag.

[redimongo]

So firstly i'll correct myself and say your right about the SocialInteract tag.

Also, you're unnecessarily complicating what can be an extremely simple tag.

This is where I disagree with you. Have you looked at BOLT11 and BOLT12 and how comments are default in both?

Additionally metaBoost doesn't work at least at the current specs where I am playing V4V music in my podcast and a listener comments and technically the comment should also go to the V4V musician.

This metaBoost tag, only communicates with the podcast creator, where current boosts communicate to everyone in the value split.

Questions for @agates are:

1. How does comments get to splits for example, if I am listening to an interview on Podcast A which John is a guest of, he is in the valuesplit but he is not the owner of the feed?

• Because with the basic BOLT11/BOLT12 callback url John would see the comment and would not have to do anything as each split gets the same data in comment field.

2. How does comments get to a V4V musician who again is a value split? (this is the same as above - technically)
3. What are the advantages of metaBoost?
4. If metaboost is to allow unlimited comment length, why is that better than adding a comment catcher in your callback url, that stores it elsewhere and it would be up to each split to sort out how they store comments sent in a BOLT11/BOLT12?
5. Do you have a working example of use of the tag?
6. Who does this tag serve?
7. Why not use the default comment= part of the Bolt11/Bolt12? (besides if supporting alt-coins)?
8. If this is designed to support alt-coins, then which players currently support alt-coins?
9. Why not use the preimage from the BOLT11 invoice once the invoice has been paid, this is validation and would solve the token concern I have with your example.

I believe these are valid questions that we should be asking.

I should also say that I don't believe creators should use a strike wallet as you may not get full control over what you can or can't do, like you may not get a NOSTR+CONNECT address which in that case I can see the advantages of metaBoost but we should not be saying to people go use strike and we will work around their technical limitation, we should be asking strike to work with our community that solves our issues. Anyone can make a nostr+connect callback (PHP, NODEJS etc) url, it's really easy and hosting it, well you would need to host the metaBoost url somewhere too.

[algrid]

I think we should try to separate the proposed podcast:metaBoost tag spec from the actual protocol that is used to save/fetch the metadata. I would be happy to have a single protocol that everyone is using, but it looks like for now we may have several approaches to this and it would be desirable to at least agree on the podcast:metaBoost spec making it more flexible.

Maybe we should go with something like this:
<podcast:metaBoost type="protocol" href="some_url" connectionParams="some_protocol_specific_params"/>

This way the tag can be used with different protocols/implementations (looks like we have at least 3 proposals: by @agates , by @redimongo and by Oscar Merry from Fountain who proposes to use nostr for boostagram metadata).

[redimongo]

Reply to @thebells1111 and @algrid:

Thank you for the thoughtful questions and feedback! Let me break down why Boostagram LIVE (BGL) takes a different approach and how it compares to the proposed MetaBoost.

---

@thebells1111's Points:

1. What happens if the Boostagram LIVE server crashes?

   • If the BGL server is down, the podcast app will detect this and show an error message to the user, informing them that the server is unavailable. If the script crashes before generating the invoice, it will return an error to the podcast player, which can communicate the issue to the listener.
   • This ensures that users are aware of the problem and no sats are lost due to failed boosts.

2. Can’t any server store comments after verifying payment?

   • Technically, yes. But verifying payments after the fact introduces complexity and potential failure points. BGL keeps it simple and reliable by storing the comment first and only then processing the payment. This avoids situations where verification issues could cause data loss.
   • Pruning metadata if verification fails is a “patch” solution, while BGL’s approach is preventative — ensuring everything is solid before the payment even happens.

3. Is BGL just another third-party service?

   • Not at all! BGL is designed to be self-hosted. You can run it on your own server, meaning you’re in control. It’s not a commercial product from PodToo — it’s a tool for podcasters who want control over their infrastructure. No need to rely on a central service unless you want to.

4. Does BGL require a standard for metadata?

   • Yes, BGL uses a defined set of metadata fields:

     • Required:
       • comment
       • amount
     • Optional:
       • appName
       • appIcon
       • username
       • userProfileLink
       • userProfileImage
       • episodeGUID

   • If optional fields like episodeGUID are not provided, BGL may not be able to link the comment to a specific episode. However, during live events, BGL can track changes in your RSS feed and assume comments are for the latest episode based on the publication date.

5. Isn’t BGL a single point of failure?

   • If you self-host BGL, it’s no different from running any other part of your infrastructure. If your server goes down, payments pause temporarily — but that’s true of any system, including MetaBoost. The difference? With BGL, you’re in control and can set up backups or failover options (AWS route53 for example and have multiple servers running if you want).

6. Isn’t BGL just storing metadata?

   • At its core, yes, but the way it does this is key. By storing metadata before generating the invoice, BGL ensures that payments are always tied to valid metadata. This avoids the risk of lost sats or failed boosts, which is a big deal for reliability.
   • See below as we do have a way to fetch the comments for each episode.

---

@algrid's Points:

1. Is pasting a URL really that error-prone?

   • While pasting a URL sounds simple, mistakes happen — URLs can break, expire, or misconfigure easily. BGL avoids these pitfalls by tightly integrating metadata storage and payment processing, reducing complexity for podcasters and app developers.

2. What’s the alternative to podcast:metaBoost for fetching recent boostagrams?

   • Boostagram LIVE (BGL) will have a public URL for fetching recent boostagrams. This endpoint will use the episodeGUID to link comments to specific episodes. For example, the URL structure might look like this:

     domain.com/api/{episodeGUID}/comments
     

   In the feed it will be in item level and could look like this

   <podcast:socialInteract
        protocol="json"
        uri="https:// domain.com/api/{episodeGUID}/comments"
   />
   

   • This feature is currently in the works, and I am finalising the details. While it’s not yet coded, this approach will provide a straightforward way to retrieve comments tied to episodes without relying on additional protocols or decentralised networks.

3. Would a type attribute in MetaBoost help with flexibility?

   • Sure, a type attribute adds flexibility, but it also increases complexity. We’ve seen how hard it is to get everyone to follow standards (like GUIDs in RSS). BGL keeps things simple and predictable by ensuring metadata integrity from the start.

4. What about infrastructure reliability?

   • Reliability is a concern for any system. The advantage of self-hosting BGL is that you control your infrastructure and aren’t at the mercy of a third-party service.

---

In Summary:

• Boostagram LIVE ensures reliable and predictable payments by storing metadata first, making sure no sats are lost.
• It’s designed for self-hosting, so you stay in control — no need for third-party dependencies.
• While MetaBoost offers flexibility, it introduces more risk and complexity compared to the straightforward approach of BGL.

BGL isn’t just another metadata storage tool — it’s a practical way to make value-for-value payments & comments rock-solid and dependable.

---

[agates]

@algrid I'm not opposed to adding a type indication. It won't hurt. Will think about it.

@redimongo I realize you're passionate about this, but these walls of text don't help anything. This is not my day job. I am not getting paid for this. I have no ulterior motive nor incentive for my solutions to succeed beyond the desire to do things correctly.

I realize you joined the community, for the most part, after I largely quieted down. My concerns about Nostr have been discussed at length elsewhere previously and no longer have the energy to argue against what appears to be a religious debate. I am not ignoring that it exists. I don't think it's the right solution.

And lastly, please don't tell me what to do. I've stopped trying to convince people who don't understand things. A proof of concept will be provided one way or another. I do things right and sometimes slowly. Again, this isn't my job.

[redimongo]

@agates just to be super clear. I don't believe nostr is the "only" solution either.

I just believe that validation of payment is needed for comments to be stored.

Also there are many ways to code correctly and we shouldn't say one way is correct and all other ways are not correct.

Am using payment validation which is key and XMR offers that, am close to adding it as a sample in our system.

Just because I am new to this group doesn't mean I haven't been coding for over 20 years (also doesn't make me an expert either and always learning).

Am just trying to reduce the number of tags in RSS and keep it to a minimum, if we can fix your issue without needing an additional tags that is a good thing isn't it?

And when I said an example I wasn't saying you had to rush it. I was saying would be nice to get some sending standards as the tags being sent to that endpoint also need to be standardised in my view.

[agates]

Am just trying to reduce the number of tags in RSS and keep it to a minimum, if we can fix your issue without needing an additional tags that is a good thing isn't it?

@redimongo No. The feed is the source of truth and should declare the podcaster's intention to the consumer as unambiguously as possible.

[redimongo]

The feed is the source of truth and should declare the podcaster's intention to the consumer as unambiguously as possible.

@agates while I get that and agree when it comes to titles, follows, links, pubdate, audio mp3, etc. We have not done that for boosts we have relied on the TVL record and sent the boost data to that.

All I am saying is if the RSS feed is truth, then in each item level the comment/boost should be listed in there if the person wants to fetch boosts for that episode (the feed is truth).

<podcast:socialInteract
     protocol="boosts"
     uri="https://domain.com/api/{episodeGUID}/boosts"
/>

The above inside the item level does that in my view.

why?

The socialInteract tag allows a podcaster to attach the url of a "root post" of a comment thread to an episode. This "root post" is treated as the canonical location of where the comments and discussion around this episode will take place. This can be thought of as the "official" social media comment space for this episode. If a protocol such as "activitypub" is used, or some other protocol that allows programmatic API access, these comments can be directly pulled into the app, and replies can be posted back to the thread from the app itself.

source: https://podcasting2.org/podcast-namespace/tags/socialInteract

[jamescridland]

In terms of the contents of boosts, I've written #680 which is a new suggestion for how the socialInteract tag might work.

I hope it is relevant here, since it could allow comments - including "boosts" - to be handled by the payment receiver. It is entirely platform agnostic - both in terms of comment platform and payment method. The podcaster is then free to verify messages it receives along with payments, in whatever form the payment platform makes available. It could even - for example - only accept comments if a user is a monthly supporter with their MasterCard.

All the app would do is to (if the podcaster chooses) display "boosts" alongside other types of comments, by simply parsing a simple JSON file.

[sa8ab]

Hello everyone!
I am a contributor on XMRChat.
From what I understood on this discussion looks like you are trying to extend podcastindex not to just support BTC but XMR too. We can provide API for confirming transactions based on the specifications. The general flow in here is still not super clear for us, however in XMRChat we are able to wait for specific payment on specific address and confirm the tipper has made the transaction so we display their message on the tip history of podcaster.

Worth mentioning we are not keeping the keys of tipper. In other words we do not create wallet for tippers. We prove their transaction is made listening on blockchain and we require Monero primary address and secret view key of receiver for this.

[agates]

Hi @sa8ab,

Thanks for checking in!

Yes, I owe you some flow documents to help clear it up for you and will have some changes to the OpenAPI spec as well. The day job has been crazy but I'm going to have a lot of time to hammer away at this starting this weekend, through the holidays.

Excited to get working on this with you!

[ericpp]

@agates Where would the typical TLV info go? Is it just sent as extra fields in the POST (e.g. {"jpt": {"foo":"string"}, "type": "bitcoin-lightning", "action": "boost", "sender_name": "somebody" } ) or does it get encoded into the JPT?

I had an LLM cook this test site up https://metaboost.vercel.app/ based on your spec and it chose to add the podcast/episode guids into the main metadata fields.

[agates]

That's what the JPT was for, but now I think we'll remove the "jpt" and "type" fields and replace them with "tlv". Have to change the the verification mechanism as we discussed on Mastodon, so that's a rough idea for now.

But for testing purposes using a "tlv" field probably makes the most sense as a direct transition from keysend. Not that tlv in this context means anything, merely a holdover for terminology.

[mitchdowney]

I'm very interested in this proposal, and looking to add V4V + Boost Messages to Podverse NextGen soon.

<podcast:metaBoost> seems like it would be simple enough to implement. I imagine we may want a type or version attribute so we know what data schema format a metaBoost endpoint accepts?

I'm also wondering if, as per @jamescridland's suggestion, it makes sense to include this in the socialInteract tag? I don't have a strong preference and am willing to experiment here. We could potentially support both approaches.

I do however remember parsing Activity Pub data to be rather complex, due to needing to crawl and cache federated comments across many servers. As a starting point regarding Boost messages, I'd like to be able to post or retrieve comments with JSON using a simple endpoint. Also, I still need to dig into how to make JPT work, to reduce spam.

[MerryOscar]

@jamescridland if listeners want a way to keep their payments private between them and the podcaster - apps could offer this option and the spec could be adjusted.

I'm not opposed to a tag where podcasters signal where to send the payment or what payment metadata spec to use - but I think this current <metaBoost> proposal is way too complicated and is evidenced by the fact that no-one has implemented it since it was first proposed in 2024.

The rss::payment metadata is a simple way to share payment metadata between apps, hosting companies, and podcasters - and has been implemented by two of the Podcasting 2.0 apps (Fountain, Castamatic) - with 2 others working on it (PodcastGuru, Truefans).

[ericpp]

For sure this spec is overly complex. But I think some of the ideas could be used and combined with the rss::payment spec to allow for podcaster-defined boost boxes and support for Monero and other crypto/stable coins.

[agates]

The fundamental merit of a podcaster-defined endpoint -- a core requirement for a decentralized ecosystem to enable all podcast apps to see boost data -- is entirely independent of any specific API iteration. By dismissing the concept based on the 2024 origin of the <podcast:metaBoost> proposal, you are committing a textbook case of chronological snobbery. Furthermore, citing a lack of current implementation as "evidence" of invalidity is a circular appeal to popularity, which you abuse and benefit to your own ends.

If the complexity of the API were a good-faith concern, the logical response would have been to engage in the design process to refine it. Instead, you’ve opted to ignore the discussion entirely, only to now weaponize the proposal's age as a pretext for enforcing a Bitcoin-only technical silo.

Conflating a critique of the implementation with a dismissal of the fundamental requirement -- while ignoring the payment-agnostic benefits of the original idea -- is disingenuous. I will not engage further with ad populum, ad ignorantiam, or these logical fallacies. This is my final word on the matter.

[MerryOscar]

The fundamental merit of a podcaster-defined endpoint -- a core requirement for a decentralized ecosystem to enable all podcast apps to see boost data -- is entirely independent of any specific API iteration.

I agree - that's why I said I'm open to a simple tag that allows podcasters to define this in the rss feed.

If the complexity of the API were a good-faith concern, the logical response would have been to engage in the design process to refine it.

I have engaged in the design process by proposing a simpler alternative that has been adopted by multiple apps - there is no rule that says the design process needs to build on the first spec proposed.

Instead, you’ve opted to ignore the discussion entirely only to now weaponize the proposal's age as a pretext for enforcing a Bitcoin-only technical silo.

I haven't ignored anything - I've been having discussions on how to solve this metadata issue with pretty much everyone in this community including app developers, podcasters, and others who have influence over the spec. I do think highlighting a proposal's age combined with lack of adoption is fair - it's not personal it's just the reality of putting ideas into the world and seeing what sticks.

---

I think we should continue the discussion as even though it's difficult it is important if we want to make open podcast payments work.

I think two important questions are:

• what is the current rss::payment spec missing / how could we improve it?
• what is a simple tag podcasters could include in the feed / value block to signal where to send metadata?

[thebells1111]

A simple tag would be <podcast:metadata url="myserver.com" />.

The v4v apps are already currently creating a TLV JSON to send with the TLV record. The easiest solution that all apps could implement in a few hours is to take that TLV JSON and POST it to the metadata server found in the feed.

The podcaster or host would need to build a database to store that data, and the problem seems to be no host is interested in providing that service for their customers so the apps are being forced to fill in the role of metadata host.