V4V without bitcoin

[ryan-lp]

I thought it would be interesting to sketch out how the value tag would work with PayPal. The tag was designed to be flexible enough to support different cryptocurrencies and payment layers, although in practice I don't think it will be adopted for anything else until we have a specification covering the different slugs that are recognised in a standard way.

Would someone like to sketch out in a comment below how this would, for example, work with PayPal? From my understanding, I believe it is possible to use an email address as the value recipient address.

The second aspect to this is that, although this tag was designed with this flexibility in mind, lightning over bitcoin seems to have this desirable quality of supporting micropayments, and one might wonder whether this value tag would be useful for anything other than cryptocurrencies given how podcasting features are evolving.

To that, I have several thoughts:

1. For me, podcasts have always been something I've listened to in "offline mode", and will continue to be so. I have intentionally not purchased any data plan for my phone so that when I leave my home's WiFi radius, I can walk peacefully with my headphones plugged in, and listen to my daily podcasts without any distractions or interruptions from the Internet, such as email notifications or beeps from social media. For offline use cases, it seems we really want a way to buffer payments while offline, and then send them all in one go when we return to the Online world. But pushing that idea further, as soon as an app starts buffering up value payments, we could in theory buffer them up to a point where we can minimise the fees that would normally be associated with making many smaller payments.
2. Hearing about how Podfans deals with some of the limitations of PWAs, it sounds like it is already doing a similar type of buffering, where it has a sats-per-minute value, and it multiplies that by the total duration of the podcast episode, and then pays that whole amount as a lump sum. So just extending that buffering a bit further, I think would bring it into the realm of making PayPal a feasible option.
3. Of course there is also a segment of people out there who are either disinterested in bitcoin, unconvinced by it, or in some cases staunchly against it. We don't need to argue with people about this, since I'd like to think of it more as a matter of choice, and of course attitudes may naturally change over time. But in order to have an actual choice, we need to standardise some options besides satoshis, and give them standard slug values and valid recipient address formats etc. so that they can be supported in a standard way by apps.
4. (Edit): One other thought is that some app developers may be on board with bitcoin's technical benefits, but may not be in a position to support Bitcoin payments. E.g. There may not be any library/SDK yet to implement it on a certain platform, or maybe the app developer already has a PayPal-based infrastructure and is simply "more" ready to adopt that one, or maybe the app developer doesn't yet have the financial resources to either build out an unfamiliar payment layer or hire the legal/accounting professionals to consult with in order to ensure that it gets done in a way that is legal under local and/or International laws, for example with respect to tax, and also with respect to any app store legal contract that might be binding in the particular case (i.e. bypassing Apple's own IAP solution, although that equally applies to PayPal), etc. etc.

This does raise another question, though, of how these different alternatives can coexist. I could imagine that some podcasters would conceivably want to welcome payments in either bitcoin or via PayPal. Certainly the Podcast Index welcomes payments in different forms, but I don't think the current value tag spec was designed with that consideration in mind, partly because the spec says there should only be one value tag, and within that single value tag you can of course only have a single payment type (because you can't divide up splits across different currencies... although that suggests that splits should be grouped by currency rather than payment layer, maybe.)

[agates]

Regarding point 2, I think everyone should buffer as much as possible. There is no real point in doing individual minute-by-minute payments. I say this even if no one implements anything outside of bitcoin lightning. There are other means of including the listening metadata which I've detailed elsewhere.

That should help translate into making more payment options possible, but we'll still need a standardized method of sending out-of-band payment metadata to "attach" or "link" messages to the payment. I intend to try this, in the future, with Monero + JPT + ActivityPub/XMPP, but I suppose someone could put a JSON payload into a PayPal message also.

Another way to say that is I think the payment destination is the easy part, someone already documented that for Nano for example. However, reproducing the other aspects of v4v over lightning (messages over keysend) will be more difficult.

[silverpill]

I'm working on a similar problem in ActivityPub world, and I wrote this spec for adding payment targets to various objects: https://codeberg.org/fediverse/fep/src/branch/main/fep/0ea0/fep-0ea0.md
The idea is to use URIs, because they are very versatile. One can use bitcoin: URI scheme to describe bitcoin recipients, monero: to describe monero recipients, or use https: URIs when dealing with legacy processors like PayPal. Some cryptocurrency URI schemes are already standardized and widely used, so we won't be reinventing the wheel. Also, apps can interact with wallets via URI handlers.

[arnold1313]

this interesting

[jamescridland]

the spec says there should only be one value tag

The spec actually was changed to allow more than one value tag, but that change hasn't been updated in all the documentation, which is a bit irritating. Podnews has two value tags - https://podnews.net/rss - and that doesn't appear to have broken anything.

The spec has just been updated.

pays the whole amount as a lump sum

I agree - though I'd like this to be something the creator has control over.
For something like PayPal, perhaps the method of achieving this is...

<podcast:value type="paypal" suggested="USD0.05" minimum-payout="USD5.00">
<podcast:valueRecipient payee="[email protected]" split="50"/>
<podcast:valueRecipient payee="[email protected]" split="50"/>
</podcast:value>

In my head, this lets you listen (at a suggested 5c per minute).
You get a message saying "You're listening at $0.05 per minute. We'll transfer this to [Podnews] when you hit $5."

Once you've listened to $5's worth (an hour 40 minutes), then the system kicks off a PayPal payment, somehow, for $5. In this case, it's $2.50 for each of the people in the split - it's up to the creator to set the minimum-payout value sensibly, and it's a toss-up between lost revenue and the PayPal charges.

I don't know enough about PayPal to understand if this is possible like the above, or whether the podcast app would need to hold cash in a wallet - and whether that has regulatory issues.

[jamescridland]

Boosts/Boostagrams would, I think, work this way:

###Send a boost? For how much: $

• We'll send this boost when you next hit $5 to [Podnews].
• You already have a payment of [$3.50] pending, so to send it instantly, make it more than [$1.50].

It's a bit of a kludge, but it could work.

[ryan-lp]

I don't know enough about PayPal to understand if this is possible like the above, or whether the podcast app would need to hold cash in a wallet - and whether that has regulatory issues.

I'm not sure of regulations relating to wallets (keeping in mind this is not a traditional wallet in that it doesn't actually contain money). Although there are other rules that come into play when doing online payments with dollars, namely PCI DSS. It's not particularly fun to maintain compliance, but one of the benefits of PayPal in particular (as opposed to Stripe) is that they take care of PCI compliance for you:

https://www.paypal.com/au/webapps/mpp/pci-compliance

This convenience is also shared by payments made through Google's and Apple's app platforms, although of course they will take a mandatory 15%-30% (don't say "split", er...) "tax" :-)

[jamescridland]

@ryan-lp I guess it depends how the money is sent - I suspect it's likely that a podcast app can't initiate a payment to a third party, so it would need to go via the podcast app. Which doubles the cost, I suppose, but also means that there's money held by the podcast app.

With Stripe, if you only use Checkout or similar, then PCI compliance isn't a thing you need worry about.

[ryan-lp]

Just doing a little research, it looks like there is a thing called PayPal.me which allows you to share a link which people can click on to send you payments whenever you want, and it also protects your email address. And according to someone on StackOverflow, you can pass the amount as a parameter (but without a currency):

paypal.me/johnpayments/25.00

So one way this could work within an app is that rather than automatically sending it in the background, you could just have a "send payment" button next to the wallet amount allowing the user to send the buffered amount at a time of their choosing. I think prompting the user to send the payment is also another way to do it.

[ryan-lp]

According to this page, the currency can actually be given in the paypal.me URL along with the amount, like this: paypal.me/YOURNAME/{amount}{currency}.

So modifying @jamescridland 's example slightly to reformat the currency and changing the payee attribute to address, this would become:

<podcast:value type="paypal" suggested="0.05" minimumPayout="5.00" currency="USD">
    <podcast:valueRecipient address="paypal.me/person1" split="50"/>
    <podcast:valueRecipient address="paypal.me/person2" split="50"/>
</podcast:value>

Along with buffering payment and the additional attribute minimumPayout, I think that works.

There is still a question about how different payment methods will coexist. We can simply have two value blocks, one for Bitcoin, and one for Paypal. Then listeners can choose how they prefer to support the show and the other value recipients, either by the app providing that option, or by the listener choosing the app that provides their preferred option.

Now considering the extreme attitudes towards Bitcoin, where on one end some people are staunchly opposed to it, and on the other end some people treat it like a religion, there are some scenarios to consider. If a podcast offers both Bitcoin and Paypal methods, then either the app gives the user a choice of how to pay, or the listener chooses the app that gives them the option they want to pay with. But if a potential value recipient doesn't like one of the methods on religious grounds or environmental impact grounds or what have you, then they may appear in one value block and not the other, so will not get a share of all payments. Similarly if the podcast author has a strong preference and doesn't give either listeners or value recipients a choice, some potential value recipients won't get a share, and some listeners will use the lack of options as a reason not to pay. All of this should naturally influence the payment options podcast authors offer in the future, whether people want to contribute value in the first place and which apps people will choose to use.

[samsethi]

This article in Podnews Daily about the V4V trends is interesting. The number of people sending SATs is declining but of those still sending SATs, their amount is increasing.

The other trend that this interesting is The average monthly audience for individual shows in 2023 is half of what it was in 2019 - and downloads are down.

Regarding Sats, I think we are still in the visionaries stage. - see image below. What we are facing now is how to cross the chasm. I am someone who likes to think I understand tech and even I have moments where V4V & Lightning payments cause me to scratch my head and think twice.

I think the point where lighting addresses become universal and personalised will help hide some of the complexity. If like email I could just send you the invoice amount by just knowing your lighting address that might be more useful. In fact that works today but is not easy for people to understand how to do it. There was a proposal to add the lightning address to the ValueBlock but that doesn't seem to have been implemented. @daveajones ?

Apple Pay, Paypal, Stripe etc could all support micropayments and V4V if they wanted to using Fiat currencies simply by removing the 3%+ fee payments but they won't and Strike App is still US-only.

When I was at Netscape we introduced the concept of the Web, HTTP, URLs etc but it was a massive challenge. The utility of the web meant people overlooked and overcame the technical hurdles until the mass adopted it. Wallets, Sats, Invoices, Lightning Address are all similar vocabulary challenges that once understood are no more difficult.

I should really whisper this but it took Microsoft to introduce the web to the masses via Internet Explorer and MSN. In a similar way it might take Spotify to introduce micropayments and V4V. I had high hopes under Jack Dorsey that Twitter would introduce Sats and V4V. The tech is all there in Twitter and ready to go but they never really talked about it or pushed it. Had Twitter introduced the concept of the Wallet, Sats, micropayments and V4V then about 300m people would have heard about it and maybe 10% would have started to use it. Elon has threatened to do something with micropayments.

IMHO the other thing people need to do is market the utility of using P2P SATs and streaming per minute along with splits. Advertising sucks and is falling. Subscriptions suck and are not being widely adopted. But I suspect the mass market is not hearing about the V4V alternative SATs model. How we get that message out of our echo chamber is the challenge.

[jamescridland]

If like email I could just send you the invoice amount by just knowing your lighting address that might be more useful. In fact that works today but is not easy for people to understand how to do it. There was a proposal to add the lightning address to the ValueBlock but that doesn't seem to have been implemented. @daveajones ?

I think this is the wrong thing to do - the ValueBlock is for robots, not humans.

There's absolutely a case for ensuring that creators can enter their lightning address into their podcast hosting service, and it does the lookups to populate the ValueBlock properly. But I would push back on adding more complexity to the tech, and leaving it to podcast apps to do the lookup. That's not needed here.

[jamescridland]

The more I'm thinking about this, it is a wallet mechanism, but for fiat currency. And I think it becomes a UX issue not a technology one.

"Put $5 in your wallet. We'll share it with podcasters as you listen."

What happens under the hood is that the $5 is turned into Bitcoin; payments are made by Lightning; and at the other end, the Bitcoin is turned back into fiat currency. None of that is important.

A creator can either sign up to an Alby wallet and fund it with MoonPay and get a lightning address and turn three times round at sunset while chanting "podfatherpodfatherpodfather" OR we can do it for them.

So, a listener...

1. Puts $5 in their wallet
2. Listens (using a compatible app) and the value splits work as normal.

A creator...

1. Signs up with Example.com and supplies them with a PayPal account. Example.com does the PodcasterWallet data.
2. Listeners listen. Example.com maintains a Bitcoin wallet under the hood for the creator.
3. When the Bitcoin wallet reaches a certain amount ($10? Up to the creator) then the Bitcoin is automatically converted to fiat and is paid to the creator by Example.com

The benefit of this approach is that a creator can STILL sign up with Alby, get an Umbrel box, do the incantations, etc, and that's fine. Or they can just sign up with Example.com and not have to worry about any of that stuff. It's entirely backwards-compatible and listeners using Bitcoin/Alby/Lightning are still paying this podcaster.

[adamc199]

Example.com is now a custodial man in the middle acting as a money changer. You need licenses for this function and KYC/AML processes.

[jamescridland]

a custodial man in the middle

The vast majority of people have no issue with this, or banking in general. If they do, then they can buy Bitcoin and do all that stuff. I'm not against it: but it's much too complicated to do that right now.

need licenses for this function and and KYC/AML processes

Well, then we need to think of whether there's a way of doing this without that. I don't have to undertake ID checks when I buy a bag of biscuits from Amazon, so there must be a way.

[adamc199]

When you are handling money for people, every country requires you to be licensed.

What you are describing, tokens representing money, is the definition of alt-coins and will be recognized as unregistered securities or money counterfeiting without registration and licensing.

Actual biscuits would be ok.

[brianoflondon]

I started answering here but it turned into a Hive post.... There's a video embedded on Hive.

The Problem

None of the sat streaming systems we're currently using have any concept of a USD or other fiat value. They require all participants to be comfortable with Bitcoin and Sats. That's great for the Bitcoin Maxis who are currently the leading users, but not great for everyone else.

In addition nearly all the current systems in Podcasting 2.0 involve giving your sats to a custodial solution to send on your behalf, and most of the receiving systems are the same. Whilst it is possible to self custody sats in Lightning, as I've written at length, it's a technical challenge.

The Solution: Hive Wallets and HBD for Listeners

Listener: buys $10 worth of Bitcoin (has to buy this by whatever local means there are in their locale).

Sends that Bitcoin to a Hive account as HBD (Hive Backed Dollars) via the system I’ve built which released a new version yesterday v4v.app

That 10 HBD is denominated in USD and my system has no ability to control it. The pass from sats to HBD takes under 3s and once the HBD is in an account with Hive keys controlled by the listener. Neither I nor anybody else can’t touch it.

The eventual aim is for the gateway I’m running to be open sourced and there be a few of them as that’s the only central point here.

Once in the wallet, and with a change coming in Hive which will be deployed in the next few weeks, there will be an interface to schedule repeat payments with your keys to any podcast with a value block.

Once scheduled, the only person who can affect the schedule is the listener/hive key owner. My site (again open source) will allow the listener/key owner to edit delete etc their regular payments.

Regular scheduled payments pass back through v4v.app gateway and send out as sats.

If a listener's wallet is out of funds, they’ll get reminders (if they want them probably via email or telegram or something I can bot).

Counterparty Risks

There are three counterparty risks:

1. During the transfer in and out of HBD, there is a very brief period when a service could swipe the funds. Right now that is me and my reputation on Hive is worth so much more than $10 that Hive people are happy to trust me with much more than that for the very short time.
2. HBD itself and the entire Hive blockchain continuing to exist. This is a more complex issue I can explain at length elsewhere to anyone who wants to hear it. I’m confident that the economics and personalities on Hive mean it will continue to operate with little or no chance of it suddenly collapsing.
3. HBD keeping its peg to the USD. Again this is a debate beyond the scope here, happy to explain this in other forums.

Limitiation

Without taking control of the funds, I can’t see a way with Hive to make a streaming payment. As far as I can see almost every one of the current systems has this issue which is why almost all of them are custodial wallets. It is only when Hive extends its very limited smart contract system at the next hard fork that I’ll be able to let the user set up scheduled payments in the future (of fixed value in either Hive or HBD).

There might be a way in the future I'll offer a way to put a small amount in a hot wallet which can be used for ad-hoc payments, got to think this through some more.

[jamescridland]

The Solution: Listener: buys $10 worth of Bitcoin

Nope. That's the whole point of this.

[FlameRow]

Good work

[WindWalkerKZ]

And if you just use a bitcoin wallet as an identifier?

[redimongo]

So what is the point of V4V if we are offering paid subscriptions to RSS feeds? I just think while sure some podcasts might be technically savvy to figure out V4V it's the consumer who is not. Also most of them use Spotify, Apple Podcasts etc which currently (unless I am wrong) does not support V4V.

It would be easier to have V4V be more like a payment link where a person can donate to the show. However a show wants to split that sure let them do that themselves.

Also as @samsethi said "The number of people sending SATs is declining" (yes I know the amount is going up). So we might need to look at a more sustainable model if we want people to give to a show.

Keeping it simple and allowing a donate button or buy me a coffee button, would work better. I like the idea of PayPal links or even if a podcast does use Stripe they should be able to redirect to that pay url.