The Podcast Namespace 'value' tag in AntennaPod

[kingonly]

Hi all,

I’m Roy from Breez. We’ve been communicating by email and thought it might be a good idea to share what we know here instead of having multiple discussions.

While I would be happy for you to be able to stream payments using Breez, I don’t think it’s feasible in the near future. Breez runs a full Lightning node. In order to stream payments, it must run and take CPU and networking. Lightning payments can take some time (up to a 1-2 minutes) so not something notifications can handle.

I’ve suggested to start with a “lite” integration. Since streaming payments is challenging, why not create a “donate” button? The button would invoke Breez to pay in Lightning and allow users to donate ad-hoc to a podcast containing a Lightning value block.

I imagine the interface would be very simple. Something like:
SendPodcastPayment(feedURL, amount)

The amount UI should in AntennaPod or in Breez (whatever makes most sense in terms of UX), Breez can fetch the value block info and split the payment accordingly.

Roy

[keunes]

Hi Roy, @kingonly,

Thanks for chipping in here! Best to have a single discussion indeed.

With barely having a clue about development, I understand that Breez and the whole streaming payment process is still quite young. But I really like the idea of such streaming payments, that, for me, is really revolutionary.

Although it’d still fall under the value for value model, I’m much less convinced about a Donate button.

The thing is: donations have been possible for ages already - it’s nothing new. I would feel uncomfortable for AntennaPod to introduce a Donate button specifically to quickly open Breez and enable a Lightning payment, while we all the same could have the donate button open the podcast’s Patreon page (or any of its alternatives) and enable payment there. Or, in The Netherlands, Belgium and Germany we could quickly open the app Tikkie and enable a simple debit card payment.

Having a donate button for one payment channel and not the other for me is an editorial choice that we shouldn’t really be making. Streaming donations, however, change the story completely and clearly provide an advantage over other (current) systems.

For me, an acceptable middle ground (because it brings something innovative) would be to simulate the behaviour in Breez, Podfriend: store listening progress and prepare payments based on that. Then every week or so we settle this in the background, or prompt the user to do so (if it can’t be done in the background). But I understood you’re not a huge fan of this approach?

Thanks again for your contribution, much appreciated! Cool to have this discussion

[kingonly]

Users should be able to donate in the form the podcasters have chosen. The value block isn’t specific to btc (Lightning)… Podcasters can define a web link as well. In the case of Lightning, I’m offering you a Breez integration, but it doesn’t have to Breez specific. It could be something “standard” to other apps can register for.

The way I see it, if it’s not real time streaming, I think it should be a form of UI. I just find the UX to be weird for users to open Breez and be prompted to pay for something that happened in the past (could be weeks, months). I’m also not sure how you would convey in AntennaPod that they need to settle the payment. And if you will have a settle UI in AntennaPod, the interface would be the same to donate interface I’m proposing (it doesn’t have to be a button in your app, it could be based on the playing time). But I feel there should be a UI that takes you from AntennaPod to Breez to settle the payment. W/o this type of integration, the UX seems to a bit off to me.

[ueen]

The streaming money idea is wired either way and I’m not sure how this could be really secured, so accidental payment don’t happen (podcast plays in the background/overnight etc.

If we have a donate button it could open any app that supports that, could be patreon, breez or any other app, as far as I know breez is the only app to support the value tag so I don’t really see it as an editorial choice here, if there are other apps, the user could select the preferred one.

I think most sensible would be to have a UI in breez and AP just sends the value block, this way it’s clear how and where the payment is handled.
If the podcast has a funding tag that could also be linked to the concret donate button (If multiple ways to donate are available AP could display a selection).

[keunes]

Hi both,

Sorry for not replying earlier. It’s difficult matter, and I didn’t want to rush a reply

@kingonly

Users should be able to donate in the form the podcasters have chosen. The value block isn’t specific to btc (Lightning)… Podcasters can define a web link as well.

Right, agree about the first part (podcaster defines). But as far as I understand from the Value specs, the value block is for direct micro-payments (without middle man) through “so called ‘Layer 2’ crypto-currency networks”. Just to say that the ‘Tikkie’ scenario I mentioned above is (should) not be covered by the Value tag. Instead, such weblinks should go into the Funding tag (which we already support).

@kingonly

I just find the UX to be weird for users to open Breez and be prompted to pay for something that happened in the past (could be weeks, months)

I agree - we must make sure the UX is good and there’s no surprises

@kingonly

I’m also not sure how you would convey in AntennaPod that they need to settle the payment. And if you will have a settle UI in AntennaPod … I feel there should be a UI that takes you from AntennaPod to Breez to settle the payment. W/o this type of integration, the UX seems to a bit off to me.

Absolutely! It could be something like this:

I just included the screen from your app to show the idea - not sure that’s the actual screen you would present on your side. I didn’t create a mock-up for the ‘details’ page, but I imagine a list with podcasts, with per podcast the number of listened minutes & boots (plus sats for each).

Also, I assumed here payout day is based on time, but we could show this based on the amount waiting on AntennaPod’s side. E.g. prompt payout every 1.000 sats.

@kingonly

The way I see it, if it’s not real time streaming, I think it should be a form of UI

This would indeed not be real-time payment streaming. I hope the proposed UX/UI would work for you. In the specs I saw this:

The “time interval” for calculating payments is always 1 minute. However, the actual interval between when payments are sent can be longer. The interval should be chosen with a few factors in mind such as connectivity (is the app currently on-line?), transaction fees (batch payments together to reduce fee percentage)

So on ‘payout day’ AntennaPod could send a batch of transactions - one per listening per minute and one per boost. Would that technically be possible for/in Breez? Or would this fall under ‘streaming payments’ that you indicated aren’t possible currently?

@ueen

The streaming money idea is wired either way and I’m not sure how this could be really secured, so accidental payment don’t happen (podcast plays in the background/overnight etc.

Streaming payments together with boosts are the whole point of the Value tag. Indeed in Breez you could be accidentally playing a podcast overnight, losing money. Then again, there’s also a bit of a user responsability, especially when money is involved.
But it’s a valid point. In my proposed UI/UX in the Detail view we could make it possible to ‘delete’ a payment to a specific podcast (before it’s sent to Breez).

@ueen

I think most sensible would be to have a UI in breez and AP just sends the value block, this way it’s clear how and where the payment is handled.

I disagree: as Roy indicated, it leads to payments for something that happened weeks, months in the past. A UI in AP can ensure a smooth UX.

@ueen

If the podcast has a funding tag that could also be linked to the concret donate button (If multiple ways to donate are available AP could display a selection).

Exactly. But that’s a whole different method than streaming payments & boosts. We could discuss (elsewhere) a ‘Donate’ button based on the Funding tag (which shouldn’t be too complicated, given that we already parse this tag). Would be a nice addition for sure.

[kingonly]

Hi keunes,

Thanks for taking the time to review.

I’m OK with the UI you’ve proposed. If we could do a one podcast at a time, the interface would be clearer I think and the API would be as simple as:

SendPodcastPayment(feedURL, amount)

Also, the interface we will add on the Breez end will be simpler, something like:
“You are requested to pay [IMAGE] NAME_OF_PODCAST xxx sats.”

You don’t need to send us multiple txns, just the total amount to pay per podcast (stream and boost combined).
If you are set on paying multiple podcasts at once, we’ll have to check if/how it can be implemented.

Roy

[kingonly]

@keunes Just FYI: some of our users have picked up on this thread and are very excited about our possible integration.

[kingonly]

@keunes where are we with this? Is there interest on your end?

[keunes]

Hi Roy,
Sorry, general live and a short holiday came in between.

If you are set on paying multiple podcasts at once, we’ll have to check if/how it can be implemented.

I think I would be, from a UI perspective, in favour indeed of paying multiple podcasts in one. This would allow to have a single ‘Podcast payout day’ for all podcasts (which can be a ‘festive’ event like a boost) and reduce the number of times we need to disturb users to handle payment.

@kingonly

You don’t need to send us multiple txns, just the total amount to pay per podcast (stream and boost combined).

I’m wondering - does that mean that all micropayments are merged into a ‘regular’ payment? Would that mean that it’s not possible any-more for recipients (podcasters) to see when the boost was made? Or could that info still be provided somehow? From Adam & Dave’s discussions, I understand knowing the ‘when’ is one of the attractive points of a boost.

@kingonly

Is there interest on your end?

If with ‘your’ you refer to me personally, then yes I believe that also @tonytamsf was interested, but put his time & skill to other Podcasting 2.0 stuff within AntennaPod first.
However, as I’m not a developer, I wouldn’t be of any help implementing this. I was thinking to put out some calls for contributions in this area for people who have experience with Java & Android development. I’m hoping that somewhere in the Podcasting 2.0 network there’s someone willing to take up this challenge

[kingonly]

Hi keunes,

Thanks for your reply. I think I understand the gap between us that leads to a different product definition. A Lightning payment, although much faster than regular btc tx, takes a few seconds - up to a minute (let’s say 10 secs on average). Each podcast can contain multiple splits, meaning a few payments.

When the user is prompted to pay in AP and sent to Breez to complete the payment(s), it needs to be fast. It doesn’t make sense for users to wait minutes till all payments are completed (which can take minutes).

That’s the reason I’m suggesting:

1. Paying for one podcast at a time (the UI in Breez will be clearer as well, allowing use to show the context of the payment).
2. Batching multiple payments into one. You can still pass Breez the boost information (e.g. array of boost timestamps) and will include it in the payment metadata, so this isn’t a real issue.

Roy

[keunes]

Hi Roy,
Sorry for the late reply again. I am only starting to learn about bitcoin and lightning, so forgive me if I make stupid assumptions or ask stupid questions Can’t Breez execute payments in the background, like, after the user accepted its execution?

If not, it’s indeed not a great experience for end-users.

@kingonly

1. Batching multiple payments into one. You can still pass Breez the boost information (e.g. array of boost timestamps) and will include it in the payment metadata, so this isn’t a real issue.

I guess boost timing is indeed the most important not to put on one big pile (as their timing and individual amounts are a message in and of itself).

Should we maybe discuss this further at one of the Podcasting 2.0 developer meetings? My knowledge is limited and I’m sure there’s great minds there that can think along.

[kingonly]

The app needs to be in the foreground and UI is required for the user to keep the app in the foreground.

[kingonly]

And the clarify: there’s no issue with the boost. We will pass the actual boost metadata in the batched payment.

[Moritz_K]

Hey, ByteHamster pointed me to the discussion here.

It´s great to see that you have already been discussing to add V4V payments to AntennaPod.
For purposes like this we have built an API that let´s users connect their Bitcoin Lightning wallet to any app to send payments via this app. That would mean any payment functionality is outsourced for app developers.

Podverse.fm is an example:

1. Users can opt-in to connect their wallet via an standard OAuth flow.
   

   

2. The first step could be to allow listeners to send boosts (one-time payments) and boostagrams (payment+message). (can´t share another picture unfortunately)

3. In the background the podcast app connects via this API to the Alby server that runs the Lightning accounts and a node for the users.

4. Payment streaming could be another iteration. In this case, you could send the payment details per minute or as a batch. Furthermore, AntennaPod could ad a little fee to the sender of the payment as a contribution for the service.

Since we build on OAuth we use an established and open standard. Any other wallet provider following this standard could be connected to AntennaPod, too.

Would be great to work together with you on this when it comes to the integration, testing and announcement. Happy to have a deeper discussion or phone call on this topic. Let me know what you think.
I expect that such an integration will cause quite some attention in the podcasting 2.0 community.

Best regards,
Moritz from Alby

[keunes]

Hi Moritz,

Thanks for chipping in.

@Moritz_K

expect that such an integration will cause quite some attention in the podcasting 2.0 community.

Of this I’m sure

On the other hand, unfortunately, we would also get backlash from our general userbase. So from our side we will have to tread carefully (in our communication). (And I say this based on prior experience.)

@Moritz_K

we have built an API that let´s users connect their Bitcoin Lightning wallet to any app to send payments via this app

How ‘interoperable’ is the solution? I understand it would be possible with other wallets/wallet systems as well, right?

One other important question I have: will this work ‘off-line’? Is it OK/safe to store/cache transactions and ‘sync’ them once in a while (e.g. together with feed refreshes), or only when connected with WiFi?

Would be happy to have a call, but I’m am a functional Analyst and not a developer, so can’t guarantee implementation. (Though if we have concrete ideas it might be easier to find a contributor for this.)

[Moritz_K]

That interoperability is a great achievement of the bitcoin lightning network. It is part of the official spec and up to wallets to implement it.
Regarding offline: AntennaPod would not make the transaction in the app. The transaction is made on the Alby servers. Let´s have a call to discuss how that could look in detail to ensure a good UX.
Do you want to propose a time for early next week? moritz@getalby.com.

[keunes]

Great, sent you a message!

[faradayfedora]

Any update on if Alby support will be added soon?