Episode 202: Walletpocalypse - podcast episode cover

Episode 202: Walletpocalypse

Nov 29, 20242 hr 35 min
--:--
--:--
Listen in podcast apps:

Episode description

Podcasting 2.0 November 29th 2024 Episode 202: "Walletpocalypse"

Adam & Dave are joined by Oscar Merry of Fountain.Fm to discuss the switch to new V4V Wallets

ShowNotes

We are LIT

Oscar Wallets

Pod Pay

nostr pay info

Pod Pay Payment Demo

What a payment message looks like (JSON)

Why video?

GitHub - kagisearch/fastfeedparser: High performance RSS, Atom and RDF parser in Python.

-------------------------------------

MKUltra chat

Transcript Search

What is Value4Value? - Read all about it at Value4Value.info

V4V Stats

Last Modified 11/29/2024 11:19:34 by Freedom Controller  

Transcript

Podcasting 2.0 for November 29th, 2024, episode 202, Walletpocalypse. Hey, hello, everybody. Oh, yeah, bright and early. We got the coffee flow in time for the official board meeting of Podcasting 2.0. This is where we discuss it all. And there's a lot to talk about today, including the Wallapocalypse, or whatever we're going to call it. This is the only boardroom that serves brunch on casual Fridays.

I'm Adam Curry here in the heart of the Texas Hill Country and in Alabama, the man who can stop a hell thread dead in its tracks. Say hello to my friend on the other end, the one and only Mr. Dave Jones. Is this business casual today? It's not even business casual, just casual casual. I wore jeans. Yeah, jeans. Yeah, you have a t-shirt or I got a hoodie. So I figured that would be good. Yeah, I've got a hoodie. Here we are, everybody in the United States. It is the day after my mic sounds weird.

Does this sound weird to you? It sounds okay to me. Yeah. Well, I made a huge mistake this morning. Yeah, I gotta be honest. I did it. It was you. You installed updates. Yeah, I sure did. You did, guess what? I did too. For the Roadcaster? No, no, for Ubuntu. I've been refreshing the Roadcaster to see if there's been an update for a long time. You installed updates on the Roadcaster this morning? Yes. Oh, that was deadly. I know, I know. I'm like, why am I even doing this?

Because you can first download it and it's downloading and you scan the code to see what the update will be. And I'm looking at it's like, oh, new virtual inputs. And oh, this is an exciting update. Install. Oh no, why am I doing that? Yeah, you know, you're asking yourself why you're saying I shouldn't do this as you hit the button. Yeah, I know that. There must be a psychological thing with that where you're like, I know I shouldn't, but I'm going to do it anyway.

It's complete stupidity is what it is. Anyway, I did it. There we go. So we are early. It is the day after Thanksgiving here in the United States, a day where we honor people with turkeys and funny hats and belt buckles on their shoes. And their belt buckles on their hats. And on the hats is right. And today, of course, even though Thanksgiving is not celebrated, I think Canada celebrates their own Thanksgiving in October. We do today.

Friday is a great tradition in the United States, which is, I think, a global phenomenon at this point known as Black Friday, Black Friday, Black Friday. So we're celebrating that by by purchasing nothing. It's more like Black Friday is less of a day now and more like a month. It lasts forever. Forever. It's true. It is one of, it's kind of disgusting. Oh, it's horrible. Like, that's the most, it's the worst part of, you know, capitalism is the, is the best of the worst thing that we have.

You know, like, it's, it's not like, like, nothing, no other economic system has the benefit to, has the benefit to bad stuff. It's 930 in the morning. I'm struggling here. It's all right. I'm having trouble listening to you. Don't worry. No, no other economic system has a closer to one to one pro con ratio than capitalism, but that doesn't mean that there's no cons. And one of them is just rampant commercialization of everything in our entire life. And Black Friday represents the worst of that.

Yeah. And, and it really hit me this morning as I was looking at my Bible app and the Bible app had some Black Friday offer. Oh, no, no. Like, what is that? Oh, man. Um, thank you, Chad. I just, uh, I just pinged the pod. I completely forgot to update to live and hit the pod ping. So that's why there's not, not everybody's here. I'm sure. And of course it's Thanksgiving and it's holiday. It's the winter holiday season. So I woke up sick two days ago.

Yeah. I mean, it's just, you know, I usually typically, I usually get sick around Thanksgiving and then it goes away sometime in March. Yeah. Yeah. Buckle up. My dog caught on fire last night. Okay. I'll bite your dog caught on fire.

Yeah. So we, um, we had the kids over for, uh, Thanksgiving supper and, uh, had all the, um, we had all the stuff like, you know, I mean, it's such a great Thanksgiving meal and Melissa had put some of these little candles out on the windowsills in the, in the diner. I'm already feeling it. Yeah. And the, these are all, this is an old house. And so the, the windows are less, they're really stretchy. You know, they go down real low to the, they, they go down to about two feet off the floor.

And my dog is like 105 pounds when I'm sitting down, his head comes up to almost my shoulder. Yeah. And so, yeah, big, big guy. And he's, he's in, he's a great Pyrenees. So he's in full fluff right now, like three, four inches of fluff all over him.

Cause for went for winter and he comes over and it's like staring at me, we're playing a game after dinner, we're playing a board game and he's staring at me and I, and I look, I look at him and I, everybody's, we, we all at once sort of like stare, like, like turn and look because we hear this like crackling sound. Yeah. We hear a crackling sizzle and we all look over to him and then I'm like, Oh my God, he's on fire. His butt was over one of the candles and his butt was on fire.

So I like jumped up and like started hitting him and knocking the fire off. He never even knew because he's so fluffy. Here we go. Yes. That was it. That was it. What is that? I smell over here in the, in the, in the pod Sage household. Hmm. He thought I was, he thought I was giving him a spanking for, he did something wrong, but he didn't do it. He never even noticed. I'm telling you, this fire was as big as my hand. Oh no. Yeah. That's great.

He's got a big chunk out of his fur on the back of his butt. Oh man. Oh man. I mean, I've heard good Thanksgiving stories. This is, this is, this beats most of them. A friend of his grandma keeled over dead into her, into her, into her plate of food at the table. Yeah. That happened once. That's pretty good. And then they just propped her back up and kept on eating. No he did not. Yes. Shut up. Yes. While they waited, because she was old and they were kind of expecting it. That's not an excuse.

I don't know. I don't know. I feel like that beats the dog story. No, no, that's the, I like the dogs on fire and no one told me the dog doesn't even know it. Bet he smelled horrible in the room. Oh yeah. Burnt dog fur was, is not the right ambiance for Thanksgiving. So we are, we're doing the board meeting. First of all, because, well, we can, but also we really wanted to, and we weren't able to do, now, did we not do a board meeting last week? That's right. Yeah. We didn't.

Do we, do we miss one? No, we did. Yeah, we did. We did two weeks ago. We missed the board meeting. Right. Okay. No, but Oscar couldn't make it. And we wanted to have Oscar on to talk about the, the walletpocalypse. Yeah. Yeah. Yeah. How everything's broken. Yes. And, and in, in between, in between the last board meeting and today's board meeting, it has been, it's been a bumpy ride for some of the passengers on, on, on the, podcasting 2.0 health thread.

There was a, there was a health thread, but you know, as health threads go and as communities go, wow, congratulations to all of us for kind of pulling through it, like a huge dysfunctional family reunion where a fight broke out and then, you know, people are like, you know, threatening to throw chairs and there's a bloody nose or two, but then it all kind of just, it kind of calmed down. And I was proud of us. I really wasn't like, look at us. We didn't, we didn't explode.

No one, uh, rage quit and forked off, you know, the whole, you know, the whole namespace or anything like that. I mean, seriously for a, what are we, a four-year-old community? That was impressive. That was, and, and I was just as, as guilty of it as anybody else. Well, I mean, everybody just kind of, you know, griped and yelled at each other and then sat down and had checks mix. Checks mix. It was fine. It was fine.

I mean, of course everybody's, everybody's gripey and aggravated because, you know, we have to change fundamentals here and it sucks. I mean, there's nothing great about having to go and re engineer a spec that everybody was already used to. That's never going to make anybody happy. It doesn't make me happy. I hate it. Um, but you know, I mean, it is, it is what it is.

And the thing is like specs, you know, I'm sure we'll get into this with Oscar, but specs will, um, they become a victim of their own success always, always. And you just really can't, you, you can't let that own you. You have, when the changes need to happen, you have to change them. And if you, if you don't, if you don't, if you're not willing to ever break anything and move to a different model, this spec will just die. It, it's just like, you can't, you can't force it.

Yeah. So, you know, it's time to, it's time to break some stuff and it sucks. So there were a couple of things going on that I noticed. First, there was a general misunderstanding of terms of, uh, different elements that were being talked about. Not everybody has the same level of understanding of the lightning network or different payment protocols. Um, yeah, there are also different agendas.

There's, you know, there's a general, not everyone sees a wallet as, you know, a listener wallet as something different from a podcaster wallet. Um, you know, there's the app developers have different issues that they need to deal with for, uh, for payment wallets versus podcasters. Um, there's also what is kind of beautiful and also out of the ordinary for our development community is that we don't really sit down and I'll write a spec on GitHub and then say, okay, this is it.

Let's go and implement it. No, we, we, we break off into little places and we go, Hey, uh, you know, three or four people are in that corner and let me try and build this over here. And, and I think that was, that was quite confusing for, um, I know it was probably for Boomi who was like, well, what are you doing? You have no spec, you know, and, and he hasn't really been a part of that process where we, where we just run with scissors and make stuff happen.

And so I wound up actually in the Stephen Bell telegram group, the general group of the Stephen Bell telegram, uh, cinematic universe. Yes. No, the SBCU. Yes, exactly.

And, and, you know, Eric PP was in there and, um, you know, and, and then there's also a contingent, um, just trying to get it all out there and make sure I covered all the bases, you know, when, when we started this podcast index, just to go back to the Genesis was really for one main reason is to enable, uh, people to have a place to develop apps and services on an index, a database with an API of all podcasts who want to be published in it.

And without fear of, you know, political or any other reasons other than strict 100% U S legal code where we couldn't have that RSS feed made available, uh, which I think has been, or, you know, we're just taking stuff out that has, you know, that is not, you know, like a test test one, two from, uh, from anchor. So we, we don't, we try to kick that out.

Uh, and Simon, so that was for deplatforming that it all started with, with, uh, Apple taking things out of their index that P everyone was talking to. And then the financial platforming, which for over four years ago was pretty rampant. It's not that it's led up that much. And that kind of crossed over into value for value with the idea that you could be sending value back to a podcaster while you were listening initially streaming.

And then later on the group actually developed the boost and the booster gram. Um, and we chose the lightning network because at the time, and arguably still is, you know, the best kind of open source way to do this with micropayments, um, best in, in, in the term best encompasses a whole lot of things. Like, it's not just, it doesn't mean technical. It also means best it best as far as like technical trade-offs, um, adoption of the underlying currency is all kinds of things.

Yeah. Yeah. And, uh, and so what that brought with it was, uh, people with, uh, people with Bitcoin, Bitcoin ethos. Um, so, and you know, that's, that's been a kind of a bubbling under thing in general. So, and we get into these almost religious things like, well, you're using high for podcasting 2.0. It's a shit coin. You're not real Bitcoin. It's not, we're just trying to make solutions, make stuff that works, that will work long -term. Um, so, so kind of stuff like that came into it.

And so, and that just made for a big, big ball of a gooey mess. And so here we are, and it really, it's all Oscar's fault. Good morning, Oscar. How are you? Hey guys. It's all your fault. Happy Thanksgiving. Yes. Thank you. Thank you very much, brother. Thank you. You guys don't have any type of, I mean, certainly not the same day. Do you have any kind of Thanksgiving type celebrations in the, in the UK?

I think we probably have the same vibe at Christmas, you know, everyone just getting together and having fun and, you know, spending time with family. So it's probably a similar vibe. And then the next day y'all hit each other with, uh, with boxing gloves, boxing, boxing day, boxer day, boxer day, boxing day, boxing, boxing day. Yeah. Boxing day is the, uh, the football day in the UK though, because they play, I think it's the only day of the year where every team in the Premier League plays.

So most people are just sat at home watching football, right? That's very similar to our, to our, uh, Christmas, but certainly Thanksgiving here. It's like everyone's, you know, having fun, being thankful. And in the corner of the TV is with the, the New York, uh, the New York versus Dallas, you know, it's like, we got to have that game on, got to see what's going on with our team at all Detroit versus somebody. Yeah. So Dave, where do you want to start with Oscar?

You want to hit him below the knee and then we're all kind of crouched behind him and you push him over me. So he falls backwards. One of those. Yeah. If you gut punch him into me, I'll get, yeah. Let's see. Um, well, I think I want to start with the whole, with what you released last week, the proof of concept for the pay, uh, pay a podcast. Um, this it's open, it's open source, uh, I believe, but have you opened that to, is it a public repo yet? Yeah. So I've actually just updated it today.

That's kind of why I was scrambling around, but yeah, it's on a new domain now. Oh yes. I see. It's gone. The original is the full, the full repo is open source. And also as part of the repo, um, I've actually worked on a library that you can pull into your own project if you want. Um, so what I'll do is just, um, maybe like share the links in, um, stick it in the board room and I can pick it up. Yeah. If you stick it in there, that'd be great.

But yeah, basically there's three URLs that are useful. There's the main URL, which I just went and bought a domain called pod pay.org. Um, oh, okay. Great. Deployed it there. And then there's the GitHub link, which has the full link to basically what you see on pod pay.org, which is the demo site. And then there's also a, uh, JSR, which is a JavaScript package manager. There's also a link to the library that the live demo is using.

So if anyone else wants to, um, it looks like that last link didn't go through the JSR one, but yeah, that's like a library that you can use that makes like some of the stuff, um, around Ellen address a little bit easier. So yeah, that's where the demo is.

And yeah, it's essentially the same thing as you guys talked about on the last show with the addition of an idea on how we can share the boost metadata, because obviously I think as people rightly pointed out, um, you know, this past week, the big issue with bolts 11 is that most of the providers limit the character account for the memo to 200 characters. So, you know, trying to put everything that we had in the, uh, keys and TLV that kind of won't really work. So yeah, it's all there.

Encourage people to play around with it. And I'm happy to kind of talk through it if that's helpful. Yeah. Why don't you just, well, you, I mean, you heard what we talked about last week and you saw the comments and I think you may have actually talked to the Albie guys this week. Um, can you just give your overall, uh, I've got my impressions of where we're at right now, but what, what do you think about where we're at?

Yeah. Yeah. I'll, I'll try and give my best like high level, uh, overview and thoughts on where we're at. So I guess like, I think one thing that was maybe, um, made this situation feel a little bit more intense than it actually is, is because I think there's actually multiple things happening here and they're not actually linked. They just happened to be, you know, happening right now. And actually it's beneficial that we do them all at once.

Um, so I guess from my perspective, there's like three things that I think we kind of need to do to take podcasting 2 .0 payments and the value spec to like the next level and make it easier for more people to participate. I think the first is the onboarding issue. Um, it's just very difficult and also confusing for people that are new to Bitcoin to kind of enter this world and send their first payment.

And one of the things we've seen time again with fountain is that, you know, once people get over that, um, kind of once people jump through that hoop, then they love it. But if you've never purchased Bitcoin before, it's very, very difficult. So I think solving the onboarding is a key piece. I think making the UX of sharing the payment payment info easier is also a key piece. And then finally separating the boost metadata from the payment is also a key piece.

And I think the most important one of these is the onboarding and it's onboarding for all of the kind of players it's onboarding for listeners, it's onboarding for app developers, it's onboarding for podcasters. And I think the thing that's held us back is key sent. And, you know, key send is amazing as a protocol, but the challenge with it is that it's not really seeing adoption outside of

podcasting 2.0. And, you know, there's every kind of like couple of months, there's new players in the lightning wallet space, you know, there's multinational banks that are adding support for lightning. And every time we see one of these new wallets, the thing that they always add is the lightning address and bolt 11.

And none of them are adding key send and none of them really have a reason to add key send because it's just not really used outside of podcasting 2.0. I think we might be like the only, you know, people actually using it on a regular basis. Last last of the Mohicans here. Yeah, exactly. And it works really well. It's just that it's just confusing to users because and the thing with lightning address is that it's amazing user experience.

It makes sense to people because it's just like an email address. And so we have to say is, this is like an email address for money, go and get one from your favorite wallet, and then you're ready to go. But the issue we've had is that people would do that they'd go and get a strike lightning address, they'd go and get, you know, another wallet lightning address.

And then there's that other step, which is actually Oh, no, you actually need a new lightning address, which is a key send enabled lightning address. And then in order to share that with someone, you have to find the value block like custom TLV stuff and share that. And I think that onboarding barrier is like really kind of like, holding us back. And for me, that's like a big thing to try and solve. Now, let me stop. Let me let me stop.

So you're because you're talking about two, you're, you're talking about two different sort of onboarding problems here, you're talking about the onboarding problem of just getting a getting a listener into the micropayment lightning ecosystem. And then you're also talking about the problem of onboarding from the standpoint of a tech of a wallet that does support the key send that's required.

Yeah. And so like that, I think those are important, because you, you're, I think you're exactly right, where we there's a lot of things happening all at once, and they're not necessarily connected. But you have the key send issue is putting a barrier in front of people that makes it even more hard.

It's not the same as just onboarding somebody into a wallet to begin with, but it adds just an extra set of problems where you exclude a whole set of wallets that could have been used before then now they can't be. Exactly. Yeah. And I think one of the most important things to to kind of think about with this is that lightning adoption is happening region by region and country by country.

And actually, the best wallets for people in one particular country are often the local, you know, lightning wallets that, you know, they're set up in that country, the team are in that country, you know, all of the materials, the education is in that language.

And, you know, that just allowing someone to download their local country wallet and have a lightning address and then participate in all of the cool things that lightning enables podcasting 2 .0 being one of them is that's way easier than having to onboard to a lightning wallet and then essentially onboard again to a different wallet. Yes. And kind of like go through the whole thing again.

And also, you know, even if you are able to do those two things, it just creates this kind of like friction where you're like, hold on a minute. I thought lightning was supposed to be this interoperable thing. But actually, it's not because, you know, I thought I had a lightning address. I only need one email address. Why do I need another one for podcasting? Before we move beyond this, and I don't know what you're seeing, because you may be a bit closer to it.

But here in the United States, I'm seeing the adoption of the lightning network. And in this case, bolt 11 and maybe bolt 12. But just, you know, the the basic LN URL functionality of lightning payments. I'm seeing this being integrated into all kinds of financial services. Many banks have it already where you can deposit and withdraw money through lightning. I we've heard from PayPal, because we're no agenda uses PayPal.

And we're we're, you know, we're a customer, at least they pay attention to, they say that some Bitcoin slash lightning functionality is coming. Cash app has something that you can do with lightning. I'm not even sure. Do you see a general move towards financial services using the lightning network purely for their own benefit of instant settlements and low fees and not really having to deal with counterparty risk? You see this rolling out more and more? Yeah, 100% I do.

And what's cool about it is there's so many different like categories of businesses that are starting to adopt lightning, you know, you have the like, you know, I guess, pure play lightning wallets, then you have the, you know, neo banks adding support for lightning, then you have the local exchanges in each region adding lightning because it makes, you know, the purchasing of Bitcoin more valuable.

Then you have like the huge companies like light spark, which are kind of trying to onboard even, you know, bigger kind of entity. So I think it's definitely happening. Like the, the adoption of lightning is happening. It's just the adoption of lightning is the adoption of bolt 11 and lightning address. And that's what I think we kind of need to, you know, realign to so that we can just say to people, all you need to participate in podcasting 2.0 is a lightning address.

You want to be added to splits. Just give me your lightning address. You want to send a payment, you just need a lightning address. You want to receive a payment, you just need a lightning address. Yeah, my own experience. Earlier this week, a friend of mine who has a podcast and you know, he was able through rss.com to get his, his Albi wallet connected and all that stuff more than a year ago. But he literally had his wallet just filled with stuff.

And he's like, I don't really know what to do with it. Also, I really kind of want to buy Bitcoin. And you know, so I said, well, look at Swan, look at Coinbase. And his, you know, his eyes are rolling around the whole scanning. And the invoice is so counterintuitive. And so I said, well, let's let's set you up with the strike wallet. And the aha moment was almost immediate.

And then even could, even though it was still consisted of scanning a QR code, the connecting his strike to fountain with which he uses was Oh, okay. Well, okay. So now just everything goes through strike. And that's my connection to my bank. And yes, yeah. So that it was beautiful to see that because he had really been struggling on how do I get this stuff out? How do I get to spend this in dollars? You know, he never really, it didn't matter how many times I showed him.

He, you know, a month later be like, you know, could you help me with that wallet thing again? Because I really don't quite understand it. And now just like, Oh, exactly. As you said, Oh, I just I can use this email address, which is, you know, his first name, last name, name at strike .me says, Oh, okay. I get this. And, you know, just the light bulb went on. It was beautiful to watch. Yeah, exactly.

And we see this again and again and again, and, you know, yeah, you know, fountain and all the other podcasting 2.0 apps, like we want to build podcast apps with cool, you know, payment experiences and other new features that elevate podcasting. We don't want to be spending our time, like integrating with on-ramp providers and like, you know, integrating, you know, KYC providers and, you know, banking integrations, that kind of stuff.

You know, that's what the companies like strike are going to do really well. And by using OAuth and also by using Nosta Wallet Connect, which I think is another great option that maintains that non-custodial option. It allows the podcast app developers to just defer that work.

And there's so much work there, you know, both on the technical side, the education, the support, like everything, just defer that to the actual wallet companies, just like, just like we've been doing with, you know, Albi so far, and, you know, we'll continue to work with Albi. I think what they've done with the Albi Hub is amazing. And, you know, Fountain is going to add support for Nosta Wallet Connect. So you can actually log into Fountain with your Albi Hub.

So we very much see it as there being two options for people to get started. You can, you know, do an OAuth connection with someone like Strike, which is going to be the like easiest first step, the most kind of familiar for users. And then once you become a little bit more advanced, you could make the decision to, okay, I want to go and set up an Albi Hub and use my Albi Hub across all of the, you know, lightning apps that are available. And, you know, the apps support that too.

So I think just giving people those two options makes the onboarding way easier. So, yeah, let me, so you, from the 10,000 foot view, I think, I think the most, one of the most important things you said is that we have a lot of things changing at once that aren't necessarily connected, but sort of all need to be done. And one of the things that, so to just kind of further flesh that out a little bit, every, you said every, you know, wallet has, everybody's wallet is local.

So you might have something like Chive Wallet in El Salvador, Strike Wallet, you know, in the US and where it's supported, Cash App, these various wallets that are available to people. And that's the one you would want to connect with.

That also, it strikes me that that extends to podcast apps as well, because each podcast app, and I think this, the reason I'm bringing this up is because I think this addresses some of the things that Sam Sethi said this week with some of the stuff that he was talking about. Every podcast app also has its own purpose and its own inner, you know, and its own sort of goals in mind.

So like Sam has taken, what Sam has done is taken his true fans and wrapped it in an onboarding process that's as easy as he can make it using things like, you know, Apple Pay and that kind of thing to top up a sort of a wallet that's obscured in what it is. So you're not, you know, it's not lightning necessarily, you can put lightning in, but it's a true fan, sort of like genericized token type of deal.

And so, and then, but then, you know, in Fountain for Fountain, you know, for you guys, you have, you know, Zebedee on the back end. So you have some keys in, so you're doing a lot of things like saying, but the reason I'm bringing that is because Sam is like, well, I don't want people using true fans as a lightning wallet. You know, it's just not, I don't, I don't want that as an, as the owner of this product. I don't think that's a good experience from, for my product.

And that's completely fair and like legit. And so if you're in that, you know, if you're in that boat, like Sam is, then you have a different set of priorities on how you, on how you take care of these things versus a different app that's like, well, you know, I don't, I don't really care about that.

Something like Castamatic, you know, or the split kit, you know, or CurioCaster, where it's like, well, I just want to, I don't, I don't really have an infrastructure that's, you know, built for payments at all. Like true fans does. I just want to connect to this other thing and have them sort of do the whole thing for me. It, it just strikes me that that's another sort of twist that makes this a little complicated is because everybody's priorities for their own podcast app is different.

Yeah. Yeah. Yeah. That makes, that makes total sense. And I think that, you know, whatever the apps choose to do in terms of, you know, features or the way that they manage payments, I think that it's just, if you want to participate in the payments that work between the apps, we were not able to do that with the fiat rails because you essentially need like some permission layer in order to send a payment.

You know, I think you could do anything you wanted within your own app, but when you're talking about paying a podcaster that from an app where that podcaster is not of that app, they don't know what that app is, but the payments still work. That's where you need lightning as the payment rail between all of the players. Well, strike is a good example of that in and of itself, because in different countries, it's not the same strike.

I mean, like you have, you have payments going cross border through, through a crypt, you know, through either a stable coin or lightning, but then it, it always just comes out through the banking system when you off board. So like, even, even within strikes network itself, I'm sure all their transactions on the, you know, internally within their, you know, within borders is probably SQL based when it crosses borders, it has to go through some, you know, some stable coin or lightning.

So there's the, and what you're saying is like, well, within each app that can be completely independent, you can do whatever you want, but then as soon as it leaves your app and goes to a different app, it needs to be a common protocol. And so that would be, you know, hopefully bolt 11.

Yeah. Yeah. But I mean, the, the thing, you know, Keysend, so I've got, I don't want to get us, I don't want to get, get you off your train of thought, but one of the things that I was thinking about this morning is Keysend. I mean, can you pay a one set invoice with bolt 11? I mean, you can pay like, let's just take the worst case scenario, which would probably be the index.

Honestly, you know, we, we've always had a 1% split for any for, for things coming out of the API is completely voluntary, but a lot of people would send that to us. And a lot of times that ends up being like one sat. And so if you once, if you send a Keysend with one sat, a lot of times it works. If you're lucky enough to go through some routes that are zero base fee and that kind of thing, you'll end up with a one set transfer.

I don't know if, I don't know if you can generate an LNURLP bolt 11 invoice with one set. Let me give you my experience. So I put a, we did some running with scissors experiments. And so I put into the episode 201 of podcasting 2.0, I put a 2 % split and Eric PP did some, some coding and he, he basically created a, you know, a forked version of the, the boost button on, on, on podcast index.

And so he sent, he sent a hundred sats and in my strike wallet, which was the 2% split, I received two sats. So that's good. Yeah. So that worked and I couldn't believe it. Honestly, I'm like, what actually came through. So on a hundred sat transaction. And so I'm just going to presume that one sat would have come through, would have come through as well. Yeah. If you're getting two, you're getting one. I think so. Yeah. Cause you're probably zero base fee through the whole chain at that point.

Yeah. Well, and, and also a distinction for people who don't understand the difference, like the difference when Keysend and bolt 11 is Keysend is generating a pre-image on the sender side. So one of the benefits of having the recipient having the receipt, the receiver generate the pre-image is you actually get routing hints with that pre-image creation on the same. So the, if you say, okay, I want to pay you and your wallet generates a pre-image and sent, you know, and sends it back.

Then what you're getting is routing hints all the way. So you have a more, a fit, like you're more likely to get a payment to be good, to go through successfully with a bolt 11 generated invoice. Then you are with a Keysend where it's because Keysend is just has to depend on its own a current graph where it's not getting any help from the network. Um, so that that's another benefit of going with bolt 11.

Um, I, I just fit like we Keysend, you know, the historically Keysend, we, we chose that because I believe and correct me if I'm wrong, I don't think LNURLP even existed when we, in August of 2020, or if it did, it was very, it was very new and I don't think anybody supported it yet. I think Keysend was the only way. Yeah, no, I know for sure because you had, you could not just request an invoice that, that was, that was the, I remember it quite clearly.

Um, because, Oh, we, we can't have someone approving invoices or, you know, doing that the whole time. So it had to be an automatic process. And, uh, so I don't think it, if, if it existed, we didn't even know about it. Right. It was very young or brand new or something like that. And there was no support for it. So that it may, Keysend was really the only option at the time.

And, you know, but, but now that we have now, like you said, Oscar, now that we have a mature Bolt 11, uh, sort of LNURLP spec, even though I still don't like the receiver having to generate an invoice. I mean, it's just, it's just where we're at because lights like the way this is being done on the financial institution level is through a thing called RTP, which means real -time payments.

And what, what groups like LightSpark are doing is they're layering lightning on top of RTP so that, uh, RTP, so that traditional banking institutions can participate in lightning transactions, but underneath it's, it's the language they speak, which is RTP. So LightSpark puts sort of puts a layer on top of RTP to do that. Um, and so it, it sounds, it may sound stupid or, or like, um, not, I don't know. It may sound sketchy to say, oh, well, traditional banks are starting to support lightning.

But it's not that they're supporting lightning natively. They're supporting RTP and using a third party like LightSpark to make that transaction happen. And that's something that is, that is actually getting a lot of traction. And if the UM, if the LightSpark UMA stuff turned, turns out to be solid, I don't know how much you know about that, Oscar, but if that stuff turns out to be solid and reliable as it rolls out, I mean, that really will open up all the doors. Yeah, exactly.

That's like, I would say one example of how you could have, you know, with, with KeySend in a time period of let's say one to two years, I don't think you would have, you know, major banks around the world, you know, that people are already using for their main accounts, integrating KeySend.

But with things like what LightSpark are doing, you could see the major banks around the world adopting, you know, and maybe they'll call it the universal money address, but it will still be interoperable with Lightning. And then, you know, the homeboarding problem just disappears completely, because it's just your bank account that happens to be able to speak to the Lightning Network. So I think that's another example of how that's the direction everything's going in.

The I think one of the things that was confusing for people who just aren't that completely into the Lightning Network part was this additional LN address. And maybe you can just give us a little rundown. What exactly is the difference between LN URL pay, the LN address format? Is it the same thing?

You know, just so people can get an understanding, because the LN address came up half a year ago, as an abstraction layer that Fountain and Albi wanted, in order to have people keep the same payment information in their feeds, but the infrastructure providers, such as Albi and Fountain to be able to change their nodes or whatever they needed to do. Yeah. Yeah, that's a great point.

And this is kind of an example of, you know, another thing that's happening that is not necessarily linked to what we've just been talking about.

But yeah, historically, the reason that, you know, ourselves and Albi wanted to make this change is so that we don't have to put actual Lightning node pubkeys in the RSS feeds, because we've had situations where we've had to move the actual Lightning nodes, and we've had to go out and try and find all of the RSS feeds that still have the old node in it and contact the podcasters and ask them to change it. And it's just like, yeah, it's very difficult.

And the chances of you having to change the node pubkey in the future are quite high. So, to answer your question specifically, though, the difference between the LN URL pay spec, which is what every single Lightning address supports, and this newer LN address options spec. And really, it's just a different lookup URL. So, the regular LN URL pay lookup just works in a way where you give a Lightning address and you receive back an invoice, a Bolt11 invoice.

The options lookup was just a way for us to keep supporting keysend, but kind of give the option of paying a Bolt11 invoice as well. It is important to say that the options lookup spec, even though both Fountain and Albi support it, is not part of the official LN URL spec. It's just something that, you know, Fountain, Albi, and, you know, Roy from Breeze was in the GitHub discussion. It's just something that we came up with.

So, I also think it's important to say that, you know, that's like a separate piece. And you'll see if you look at the demo code that I've put together, there's some code in there that says, like, does this Lightning address support the options lookup? And currently, the Lightning address providers that support it are Fountain and Albi. So, you'll see in the code, if you look at it, if it's a Strike Lightning address, we're not actually using that options lookup.

We're just using regular LN URL pay lookup, because we know Strike don't support keysend anyway. And, you know, we're just going to look up the Bolt11 invoice. Now, my hope is that we can actually get the options lookup as part of the official spec, because I also think it's helpful for when Bolt12 comes along that you don't have to, like, change the way you do the lookup. But that may or may not happen.

And so, I think that for, you know, all the app developers listening, you will have to do this check where you say, okay, is it, you know, who's the Lightning address provider? And do they support the options lookup? But again, if you look at the demo code, it's really simple to do. And, you know, the lookups are only kind of like one path parameter difference. So, they're very similar.

Well, and you could also just sort of do it a different way where you try the URL for the options URL first and then fall back to the LN URLP URL second without even having to have a lookup table. Yeah. And the, I also think that the options lookup is a great idea.

And I think that's why Roy, I think Roy, I think Roy really pushed that concept because then you're, you're sort of future proofing the LN URLP lookup itself, because even beyond Bolt12, there could be something else that happens in the future. So, you don't want to tie anything to just one particular, you know, lookup.

Yeah. The, so the, the, the way, just, just to lay out the way this works is you, you do the, when you, when you have an LN address in the, in the value block split, you do the lookup and looking up that options URL that comes back with potentially three options, keysend, LN URLP, Bolt11, and Bolt12. You, you take whichever one that you support and you pay it, preference being Bolt11 at this point.

Then you attempt to pay that, you know, then you do the, you know, then you attempt to pay that invoice. Then, you know, you can fall back to keysend if you, you know, if you need to, then if that options lookup doesn't work, you fall back and just do a straight LN URLP lookup. So, that would be your sort of payment flow there. You know, this, it's just not, there's no way around this. Stuff's going to break over the, across the, you know, across the system.

Now, one of the things that Boomi got upset about was where, you know, he was saying that was FUD, was that we were saying that everything's going to, that, that all the listener, Albi listener wallets are going to stop working on January 26th. And the listener stuff, not, if you moved to Albi Hub, you're not going to see anything different. You're just going to keep on trucking. Let me make that clear.

But most, I mean, the overwhelming majority of people are not on Albi Hub as far as listeners go. Now, you know, listener wallets. Now, I would be shocked if 1% or more of Castamatic listeners, listeners, are on an Albi Hub. They're almost all going to be on a custodial wallet. And they're all just going to, it's just going to stop. It's just going to stop working. And that's just the reality of where we're at. So, in that, in that situation, a lot of stuff's going to break.

Now, the, the, the podcaster side is going to be less, the podcaster side is going to be less affected by that, but it is going to be a big, a big deal. And, you know, I don't even know if the index API, you know, I need to check that. I don't even know if the index API. We all, you know, we have a, we have, we have a lot of, we have a lot of podcast feeds that were shimmed. Right. The podcaster wallet.

Yeah. And the, and the partner API, which, which I think Oscar, you guys use that frequently for people claiming their, claiming their, their feed on Fountain. Yeah. Yeah, exactly. Yeah. We, we have a lot of podcasters who have, you know, set up value through that mechanism. Okay. No, I'm sorry. Chad F said this sunset date is January 4th, not the 25th. The 4th. I don't know. I thought it was the 25th. We just lost two weeks. Oh no. Oh, Eric PP says index API does return LN address.

Okay. All right. I thought it was generic enough to take it, but it's good to see that that's true. Thanks, Eric. So are you, are you pushing LN address value blocks into the API now? In the index? No. So, no. So, you know, this, because of how big a change this is, I wanted to make sure that like we didn't break anything in any other apps. That's why the only RSS feed that I'm aware of that actually has an LN address value block type is the Fountain Radio RSS feed.

So this is, you know, I think it was last time I was on, actually, we talked about Fountain Radio, but we've rebuilt it now using an HLS stream and it's on an RSS feed. So you can listen to Fountain Radio in any of the podcasting 2.0 apps. And it looks, it looks really cool, actually, especially the ones that support video because we support video on it. But, but yeah, so the Fountain Radio RSS feed has the LN address type value blocks.

So if you're listening to Fountain Radio live in Podverse or Podcast Guru, the support payments won't work. That's why we wanted to put that test feed out there to give developers a chance to add that payment option. And we don't support the LN address type in Fountain either. So we need to do this as well. And it was a, you know, a test case for us as well. But my hope is that, you know, that feed can be a test case. And if others can create test feeds as well, that would be great.

And then we can try and like get as many of the apps as possible to at least have the option of paying those types and, you know, work out all of the rest of it in terms of like the metadata, which is, you know, something that's important as well. And, and then, yeah, at least we have a test feed to go and play with that no one has listened to up until this point, because it didn't exist until, you know, last week. Well, the, so, yeah, I'm checking in the RPP is right.

The index does return the correct. It's ingesting LN address splits correctly. So that's good. I mean, what, what is your, what is your plan for what you're going to win, how you're going to transition this in Fountain? Yeah, so for the Fountain mobile app, I think what we'll do is just support both. So whenever somebody, you know, sends a payment, we check the value block. And if it's a keysend value block, we'll, you know, send the keysend payment.

And if it's the newer LN address type value block, we will, you know, pay via Bolt 11. And that should be relatively easy. And then as, you know, more people switch over on the hosting side, we can, you know, look to deprecate the keysend. Before we get deeper into the transition, we're transitioning. The important piece that is still on the agenda is the payment information. Um, cause you're right.

Uh, because even in our simple test with Eric PP boosting me, uh, I got almost, almost got all the Jason, but I didn't because if you look at the strike, uh, strike limits it to 200 characters. So there wasn't, you know, the, what the only message was test and it still cut off everything. So, um, that's been, I think the final piece is, and it's always, it's always been a huge benefit on one hand, I feel to have the payment information, uh, being shot along as in the TLV record.

On the other hand, uh, there were limitations to it. Um, it was kind of a kludge if I recall correctly. So now we, we are looking at doing something different there. I think we need to spend a few minutes on that. Yes, definitely. So, you know, from my perspective, I think that decoupling the payment from the metadata just has so many benefits.

Um, and again, it's kind of a separate thing to everything that we've talked about, uh, so far, like even if we were to carry on with key send, I still think it would be an amazing idea to separate the metadata from the payment because unlike if it just like take a step back and think about the different things that we've done over the past couple of years, you know, making the boost public in the fountain app, uh, and displaying them under the episodes and

putting them in the activity feed is something that both listeners and podcasters really, really enjoy. Um, you know, for listeners, it's great because you can see what podcasts the people you follow are finding valuable. And then for podcasters, it's great because when people send a boost, it provides them with discovery as well as value. Um, and so people have loved that.

And you know, I think we've always wanted to have this cross out, you know, commenting ability and fountain has always wanted to pull the boost in from the other apps. And we've actually tried doing this before, but the data in the TLVs is just too unreliable because we only see the one portion of the split.

So, you know, I also think that going forward, you know, just separating the payment from the metadata and kind of rethinking all of that, it opens up a world of possibilities in terms of what we can do with these payments and what we can do with the data, because, you know, we've never really had it happen, but the only thing that tells you that this payment was sent from an app is a string in the TLV, which anyone can fake.

So, you know, you could easily send, you know, a payment to one of the splits in the, in the feed saying that the value M sat total was a million sats. And then you'd have questions, you know, where's the rest of the money? Exactly. So, but like, I think it would be absolutely incredible for podcasting 2.0, if we could figure out a way to reliably share the payment metadata with between all of the apps. And I also think it paves a way for cross app comments.

And I think we should get to cross app comments because, you know, I think it's possible. I really do think it is. But anyway, on the payment metadata. So I'll just explain the idea that I have for this. And, you know, I've talked to a couple of the guys in, in the podcasting 2 .0 dot social. And like, we've spoken about this. So I've like been getting feedback on this. And I think it's a good idea. But I also want to say that, like, I'm open to other ideas as well.

And whatever people want to do, happy to go with it. So my idea is to use Nosta to transmit the payment data. And before you think, oh, no, not Nosta. This is not about the social aspect of Nosta. There's no profiles involved. There's none of that. You don't need a Nosta account to use this. It's just about using the signing capability of Nosta to allow apps to share the payments with each other. So as Fountain, we can sign a message with our private key, send that out to everybody else.

And people can kind of trust that based on the reputation of Fountain. You know, Fountain will trust the podverse pub key, the podcast guru pub key, the true fans pub key. So I think, you know, Nosta is just a public message bus. And we can put the metadata about these payments in Nosta events. We can broadcast them, anyone can query them, and we can trust them because we trust the apps based on the reputation.

And also, you know, Nosta is great for this scenario in that it is actually changeable, like we have the ability to, to, you know, create what we want, rather than having to like fudge our way into some existing system. So I've come up with a structure for this. And I've just called it the Nosta generic payment event.

And you can go and look at an example of this on the on the on the demo website, if you send a payment on a demo website, it will generate one of these and you can see all of the details that our relay is also accepting these events. So you can query our relay for them. And in this payment event, you have all of the metadata about the payment, you have all the podcast goods and the information about the podcast, so you can figure out, you know, what actually was getting paid.

So that's the idea for how to share the payment metadata. And then the second part of this is, if we're using bolt 11, and we only have 200 characters of space, you know, what do we do, because a lot of people want to send, you know, 500 character plus boost, you know, that's already a limitation of the key send TLV, because we can't go higher than that.

So, so the other part of this, and again, the reason why I think NOS is a great solution is because it just has these amazing primitives, these amazing like building blocks. So one of them is called NIT19 encoded values. And this actually uses the same TLV encoding as the key send TLVs. What it does is allow you to take essentially the key information about one of these payment events and encode it as a short string. So again, this is available on the demo site.

And you can see that when you send a payment, the encoded string is created, and it's put into the bolt 11 memo, and there's enough space for it. And inside that encoded string, you have all of the information you need to find that event. So you have the unique ID of the event. You also have the pub key who published it. So you can say straight away, okay, this is from fountain, I'm going to fetch the event because I trust the fountain pub key.

I've never seen this pub key before, I'm not even going to bother fetching it or showing it. And then you also have the relay where that event is located. So you just that one short string. Yeah, the relay. That's good. That's good. From helipads from whatever app you're on, all you need is that string, which fits in a bolt 11 invoice, and then you can pull back the entire payment metadata. So I think this is a really good solution.

And what you'd actually see, and we've got this hooked up to the strike wallet. So you know, if someone sends a payment now on the demo site, what I will see in my strike wallet is I'll just see the header podcasting 2.0 payment, and then there'll be a link to this pod bay.org slash p slash the n address one.

Now the really important thing to understand about this is anyone can create these links, it doesn't have to be like this domain that I've set up as a test, we could put this on podcast index, each app could have their own version of it like it because all that really matters is the n address. And that tells you like how to find the event. And that's a way that we can kind of highlight to Okay, I have a strike lightning address. And I see all these payments coming.

And I'm like, what are these payments, I'll just be able to click on the link from my strike wallet, it will take me out to the page where it will show me all the information about the payment. Obviously, at the moment on the demo site, it's just you know, the JSON just to highlight how it works. But you can imagine in the future, you know, that's a bit more styled, it's got the information about like which app it came from all of that information.

So yeah, that's, that's my view on how we should do this, we should share these signed payment events between the apps, we can trust each other based on reputation. And then for the memo field of the bolt 11 invoice, we can put these, you know, encoded links into the memo field, which can link out to the full payment details, philosophical issue, which came up over this.

Up until now, the only people who could receive and see the messages would be the people who are in the value block split, which I've always countered by saying, well, it seems like fountain is showing all of these that are coming from fountain, I personally have found I've talked about before, I found that nice, I liked it. And it can people can then comment and do other things with it. But in general, that's always been private. And so that always comes up as well. Hold on a second.

Now everybody, for some, although it was never really intended that way. The payment information, the the message that was sent along with the payment was semi private, because you know, only if you receive the payment, would you see it? So the philosophical question is, is there an issue in general amongst the community of this being now open?

I personally like it, because then people can start to build new applications, new thoughts, new ideas, based upon this of things we haven't thought up yet, some things we can already think up. Where do we stand with that just as a as a group? Yeah, so I think, again, what's great about Nosta is we have these building blocks. And, for example, there's another Nosta NIP that allows you to do this thing called gift wrap, which allows you to basically encrypt the event.

So, you know, I think, we don't want to overcomplicate this, this potential change if it does go in this direction. But there is definitely ways that you could create one of those like payment links that is only readable by the receiver, because you would encrypt it. And then only the receiver with the receiving kind of key could actually, you know, unwrap it and view the metadata.

So there's definitely ways that if people want to, they can, you know, create a different version of one of these encoded payment events, and have it only readable by the person that received that link, as opposed to it being, you know, publicly accessible by everyone. And that's actually, you know, better than what we currently have. Because again, you know, if the splits are, you know, open by the TLV, then you can always kind of read it if you're in the splits.

But I also want to back up a little bit to your description of the payment proof because, you know, you, so what, let me just kind of rephrase or reframe the process here. The payment happens, the splits get paid. And let's say that there's three splits, they each have a Bolt 11 invoice that gets paid. There's a payment proof, which is going to be a signed event that is created by the sending app and gets put on, in this case, on Nostra Relay as an event.

And then a link to that event, a public link to that event is included as a URL in the memo field of the Bolt 11 invoice when it gets paid. And then, like, as of right now, you can just click that invoice and just to display the JSON of that. So that all feels good, except the, not except, I mean, but in addition, I guess I would say that you, this is all up to the sending app. So the sending app can do whatever it wants with this payment proof.

So the payment proof, you are signing a Nostra event and then sticking it, like for fountains, for this example demo app, I'm assuming you're putting this on the fountain relay. Is that right? Yeah. Yeah. Okay. And so then, but if you're a different app that doesn't have like a Nostra infrastructure or whatever, you could send this in some other forum. I mean, you don't have to stick this on that.

You could put it out there as an activity pub event or whatever, as long as it's somewhere accessible to the end user and it follows this format. It's just JSON. So you could, you know, you could parse this no matter where it's at. You could just put these as, as HTML input. I mean, HTML outputs, like, no, I'm sorry. I'm losing my mind. Not HTML, like HTTP accessible events. They could just go on as just JSON documents on an object storage somewhere. Yeah, exactly.

The creation and signing of these payment receipts that the apps sign and the distribution of them are kind of separate. You don't have to broadcast them to the Nostra network. You could just, you know, have them, you know, be in one particular place or you could have them sent around privately if you wanted to. Yeah. So, I mean, I think, should that be in the spec though?

I mean, I guess what I'm asking is, should it be in the spec somewhere that, okay, the payment proof needs to be, if it's going to be a publicly accessible payment proof, it needs to be in the Bolt 11 memo field. I don't know that that's spelled out in the spec anywhere. You're doing it, but I don't know that it's actually in the spec as written. None of this is in the spec. So, yeah, I guess, like, this is just an idea.

And, you know, I've spoken to a few of the guys on this and got good feedback from it. So, this is very much me saying, like, here's how I think it could work. And people can play around with it. The code's open source. You know, the demo's there. People can play around with it, you know, and we can keep discussing it. And this doesn't have to be the final thing that we end on. It's just kind of an idea.

But I think, I mean, I think it kind of is the final thing that we end on because you, I don't think that there is any other way or any other place to put it. I mean, like, you're just putting the URL in there to the payment proof. And it could be that you put something else. It could be that you put some other type of link in there to the payment proof. But having the payment proof linked to in the payment itself. Yeah, that's the way. Yeah, I don't see any other way to do it.

Yeah. And the cool thing about this is, is it's not just a replacement for what we have, but we get more information because you're seeing, like, the one step above, like the, you know, you're not just seeing your split, you're seeing the whole thing. Yeah. Okay. Yeah. So you're, you, what you're just, what you just said was that when you see the payment proof being linked to is the payment proof for the sort of payment writ large, it's not for that particular split necessarily.

Yeah. And that preserves the sort of the integrity of the numerology and all of that. Yes, yes, exactly. Because this is exactly right. Because the problem that we were having before, and we had to remove this feature because this was happening was what we would receive a split. We would receive a payment to our boost bot at fountain.fm split, which was like a 1%. Because we said, okay, put us in the splits and we'll create the boost and display them from other apps as well.

And then we would have these, you know, big boosts come in from other apps, but one of the other splits would have failed. And so we would display, we would be displaying a 200,000 sat boost, but actually the main split failed. And so that podcaster didn't get any money. And then we would be like, that would be going into our chart system. And so it just wasn't reliable. But what's really cool about these events as well, exactly.

What's really cool about these events as well is they're replaceable events. So, you know, I won't get into how they work on Nosta, but they're really simple. Essentially you can publish new versions of the event and that address link that goes in the memo field that doesn't change. It's just the actual event that changes and the D tag, which is the unique ID for the payment that stays the same.

And so what this means is as soon as someone sends a boost in the app, you can generate one of these, you can send it out there. But then if, you know, a bit further down the line, you have a payment error on one of the splits, you can publish a new version of this event to say that actually, no, like the amount wasn't that much, it was a lower amount. So it also gives you that flexibility to be able to, you know, handle payment errors and, you know, like changes to the payment.

Let me rephrase again what you just said for, let me translate it into human. So what you're saying, what you're saying is that, let's say I have a split, a three-way, let's say I have a value block with three splits in it. And the share is, you know, 33, 33, 33. Then a hundred set boost goes out and each recipient is going to get 33 sets. And initially the event may go out now, whether it's going out to Nostra or just being published in some other way as a static file.

The initial payment proof is going to reflect a 99 set boost and, or, you know, whatever, however you calculate that is going to reflect 99. Then if one of the splits failed, you could go back and revise that to, okay, wait, no, the total was 66 instead. And that payment proof comes back. The payment proof gets changed after the fact to reflect reality instead of what we thought happened. Exactly. Okay. All right. Yeah. No, I mean, this, this all makes, this all makes sense.

I mean, this all just, this all makes a lot of sense. And of course, and then you have this idea, well, then you have the idea also that the, okay, well, let me, let me say one more thing. So the, if you can't, you know, we're describing a thing that I'm looking at on the screen right now, a JSON structure that is the payment proof. We're just, we're, I'm describing this thing that I'm looking at, but if you can't see it, it's a JSON structure that has a lot of the payment information in it.

But then there's also one section of this structure that is a metadata section.

And that is where the traditional, what we've been using before the TLV, what we've always said is, you know, we just refer to it as the quote TLV record, which has like the action equals boost, which the podcast index ID, the feed URL, episode ID, all these different episode, all these different pieces of metadata about the podcast being, being boosted, all that stuff goes into this, into this field in this event called metadata.

So all that stuff can go, all that stuff is preserved, but you're going to have to have access to the payment proof to see it.

And then if you don't have the payment proof, if it's not provided in the memo, well, then you just, you're not going to, you're just going to assume that you're going to assume that the sender can't, has no way of proving that you can, you still, you still don't know how many stats you got, but you can't include that payment in some sort of like a public thing, or you, you can't, it's not, that payment has told you by the absence of its payment proof record that it has either, that it's

either fake or that it just does simply doesn't have a way to prove itself. Like it doesn't have a publicly accessible system that it's hooked into to provide the payment proof. So, I mean, this all just makes sense to me. Yeah. And the cool thing is as well, is there's two additional things about the way that this is structured. The first is because the way NOSTA works, you can query on the single letter tags.

And so the GUIDs are actually not in the metadata, they're in their own tags in the I tag. And that way you can query all the payments for a specific feed, a specific item, which applies to episodes and tracks or a publisher as well. So that means that, you know, for one app to say, give me all the payments for this episode in the last 30 days, it's literally one WebSocket query, and it's really easy. And then the metadata is because it's just like a JSON encoded thing is extensible.

So, you know, if in two years, something, you know, there's some additional metadata that we want to put in there that would make this all much more useful, all of this data, then we can just update that metadata. We should probably put a link to this payment proof in. Yeah, it's in the show notes. In the show notes. Yeah, I got it in already. Okay, cool. So how do we transition? What is the best way?

I mean, I heard Oscar say that, you know, they'll, they'll look at Ellen, because, you know, I currently don't really have an easy way to create an Ellen address. But I do have a strike wallet. You know, so is it do we just rip the bandaid off and go full bore? Or I mean, I'm the transition part is a little fuzzy to me still.

I think that I think we shouldn't rip the bandaid off immediately, because I think that there's still like, we can use some test feeds, like the fountain radio feed, you know, if anyone else wants to create a test feed with the new Ellen address, and just give everyone, you know, a week or so to just get their head around this, play around with it, send some test payments, have different combinations of splits, and just kind of make sure that's all working.

And then maybe we can try and like, you know, because well, I'll give you a great example, like all of the podcasters that use fountain to receive, you know, we'll have a decision to make on when to update all of those value blocks.

And I definitely wouldn't want to do that until, you know, I've at least heard back from, you know, everyone, all the app developers on, you know, what they think of this, and whether they're playing around with it, or I think we should give it at least a few weeks of people just having time to look through the code that I've produced, look through the page with all of the demo data.

And like, basically what we've talked about today, but in text form, and we can kind of just continue the conversation on podcast index dot social to make sure we haven't missed anything. And, and the, the somebody, you know, somebody really could create a key sent to bolt 11 gateway. You know what I mean? I mean, that would be like the, you know, that would be something that Brian of London would probably attempt to do since it's very Rube Goldberg, but it could, it could be done.

It could be done. That's funny. Yeah. Wow. Okay. I feel like for the first time in two years, I need a cigarette. That's a, that's a lot. Yeah. There's a lot there, but, but I feel like, well, you said, you know, when do we rip the bandaid off? I mean, on January 5th, there is no, there is no, there is no more bandaid. Yeah. The bandaid is gone. Right. Exactly. What if I told you there was no bandaid? I mean, that's really what kind of where we're at.

So this is where here, my feeling is we're at the perfect time to break stuff because the things, the people who, the people who are in a position where, and that would be like you, Oscar, Sam, the people who are in a position to be affected the most, I'll be as well to people who are in a position to be the affected the most financially by a bandaid, a bandaid rip are the people who also happen to be the most equipped to handle these changes.

True. So, you know, I mean, found on, on fountain, you control, you control the, the listener side and the, and most of the podcaster side saying, you know, Sam is, has sort of like wrapped his infrastructure with, with the, with his own sort of payment paradigm. I'll be also controls so much of their own infrastructure.

So I think the bandaid rip is really going to be, it's, it's less of a bandaid rip and more of like a, you know, the bandaid is just going to get old one day and shrivel up and fall off. The analogies are awesome, Dave. Really good. Yeah. I mean, do you agree with that Oscar? Yeah, definitely.

And I think the other thing is like, if, you know, I, I know with Albie making this change, you know, this kind of like, you have to think about what you're going to do, you know, from having one, um, set of APIs with Albie, you might now have to have two, like one with strike off and the other with Albie for the people that want to continue using Albie hub. But like the cool thing about this is Albie, all of their APIs, as Boomi said, still work for people that have Albie hubs.

So you don't really need to remove the Albie, um, piece of this. You just can pay these bolt 11 invoices with the Albie API. So, you know, you can almost like start testing this without implementing strike. Oh, so you can just use the Albie APIs to try paying one of these LN address types value blocks, which we have one example in the fountain radio feed.

So I think that's really important as well to like, and, you know, I've been speaking to the Albie guys, you know, I think they, they understand where I'm coming from with this and hopefully we can get them, um, you know, on board with pushing this change. Cause also it gives people the opportunity to revisit the payments in their app and also look at things like NOS, the wallet connect as well, which I know, you know, Albie would like more people to, to integrate.

So I think getting Albie on board and just framing this as, you know, this is a great solution for the future for, for Albie, for bouncing, for all of the apps and, and it shouldn't be that difficult if, if we can get everyone on board, then we can think about at some point, you know, maybe like early next year, making the switch.

Yeah. Because that's important that yet again, another sort of disconnected yet timing wise simultaneous thing that is happening is, you know, it's not like, it's not like what we're saying is, Hey, Albie listener, Albie custodial listener wallets are going to be sunset on January the 5th. Um, everybody switched to strike.

That's not, nobody's saying that it's just that strike is strike ended up being, uh, a good example of a way that a independent podcast app could connect to an existing wallet and begin to use that infrastructure. Like, like Franco with Castamatic, I mean, a strike's not available in Italy. He can't use it.

So like, he can't even test, I mean, he could put, he could put in place, he could put in place the, the connectors for people outside of Italy that could, so that they could use it, but like, he can't even test it in his own country. So we're not, that's not really the purpose of what we're talking about is, Hey, everybody start using strike.

The point is, um, not everybody start using strike, but everybody starts supporting bolt 11 so that you can then have access to a wider array of payment of a wallet providers as they come online. Exactly. As they come in your area existing. Um, just so I get this straight existing Albie users who, um, and I'm talking on the podcast listening side who have, uh, who have a custodial wallet that's going to go away.

Now, can Albie just switch that for them and say, Oh, um, your same Albie credentials work. Uh, but now you have to use our Nostra wallet connects and you bring your own wallet. Does that work? I don't know. I mean, it should. Yeah. Because they support Nostra wallet connect. I mean, it should. Well, okay.

Yeah. So that's a, that's an example where like, you know, if that, if Albie could do that, then that would be, that would also really help with the transition because, you know, for, for examples like Italy, the other example is Zebedee as well. I know they've been talking about, you know, opening up the OAuth capability as well. So that would be a great, another option.

And then, yeah, if Albie could allow you to sign up with a wallet, connect it to Albie via Nostra wallet connect, and then use the Albie APIs kind of like, so there's like three hops for the user through Albie to the other wallet. Like that doesn't, obviously that doesn't solve the onboarding thing that we've talked about, but that may solve it for existing Albie users that just want to kind of like. Just continue using it. Yes. So that could be a solution for Franco.

I mean, he would still have to have his users select a different wallet, a wallet provider, but they, they wouldn't even necessarily have to change anything in their, in their app. They could use the existing Albie, Albie API. Yeah. And Eric PP said, I think you can connect Koinos to an Albie account. So that would be another option. Yeah. I don't, I just, I don't want, I hate that the Albie guys thought we were fudding them and throwing them under the bus. That's just not the case.

We're just trying to be realistic and, you know, never let a good crisis go to waste. And this is the, this is the way that you, this is the right time to do uncomfortable kind of things that break stuff and get messy. So let's, let's just like, like, let's just go through this and, and get it done. And we'll come out on the other side with something that's better for them and everybody else too. I love it. Yeah. I love it. Where, where are we at? Oh, we're an hour and a half.

Do you want to leave it here? Have we, have we discussed everything we need to? I mean, there's plenty more stuff we could talk about, but that can be for the next board meeting. Yeah. I think this is probably as much as we can digest at the moment. And yeah, I mean, Oscar, man, I, I, I so much appreciate you doing this pod pay example thing. This is so helpful, man. This is so helpful.

I can't thank you enough for doing this because this gives all the developers instantly an ability to just look and see what this code looks like. I mean, like, thank you. Yeah. It's really, I mean, yeah, sorry. It took so long, but like, yeah, I mean, happy to help because I really do believe that all of this, you know, it just doesn't work if it only happens in one app, because you might as well just go and use Spotify and have like Spotify's internal payment system.

It works because it creates payments. It creates cool social features, but you can still choose to use any podcast app, depending on, you know, the design or the feature set or, you know, whatever. So I think it's really important that the payments work in an open way going forward. And I hope that yeah, we can just, I mean, I still would love it at some point.

I think it, it would just be so cool if someone could send a boost on like Dave, if you could send a boost on Castamatic and I could see that on the episode page and fountain and reply to you saying, Oh, cool. I'll check this episode out. Add to my queue. Like that one day, maybe one day would be an incredible, incredible thing. And Spotify and Apple are just never going to be able to do that. So I just hope they never want, they don't want to, they don't know. It's not in their best interest.

Yeah. So I hope we can get there one day and hopefully this like sharing of the metadata is like the first step and yeah, it's going to be, it is a change, but yeah, if any, like just please reach out to me, take a look at the demo code and we don't have to do it exactly in this way. Like this can hopefully be the start of the conversation and we can arrive at something that works for everyone. And if anyone wants to test it's a fountain radio, what's the URL for that?

Yeah. So it's fountain.fm slash radio, and you can also listen in the mobile app. So yeah, check out, Ainsley is actually doing a live takeover now. Oh nice. We have the ability for artists to take over. So yeah, jump over to fountain radio and also, yeah, like app developers use the fountain radio feed because yeah, it's just a live item. It works in the same way as a regular live item. But obviously the value block is in this new format.

So yeah, use fountain radio as your test feed and hopefully you'll discover some good tunes whilst you're working away. Excellent. And I'm going to leave my strike split in the podcasting 2.0 feed if anyone wants to hit that and I can provide instant feedback as well. Okay. I suggest we forego the value for value thanks here and move that towards the next show, if that's okay with you, Dave? Oh yeah, sure. That's fine. Well, you had an hour and a half. You've got your family.

I don't want you rushing. I'm falling down. I haven't had breakfast. And the donuts suck today in the boardroom. I'm really sorry. I'll get a different provider. Is there a cake type? It's not my favorite. Yeah, not my favorite. And the scones that Oscar brought, you know, I ate all of those in a minute. You know, it's done. Oscar brother, thank you so much. Thank you for jumping on this. We really appreciate it.

And I'm so grateful that you see that we need the whole, you know, the whole grouping on this. We need to build, you know, a whole force and an army and it's not just fountain. That really says a lot about you, my brother. It really does. Well, yeah. Thanks, guys. Appreciate everything you do. And yeah, looking forward to working through all of this. So yeah, thanks so much for having me on again. All right. Boardroom, thank you for those of you who showed up so early.

Dave, brother, have a great Thanksgiving gathering with the family. And I'm sure they're looking forward to hearing all about the board meeting. They want to know every detail. Yeah, we're going to get pretty deep into payment peruse around the table today. Thank you all very much for being here in the boardroom. We'll see you next Friday for Podcasting 2 .0. You have been listening to Podcasting 2.0. Visit podcastindex.org for more information. Your dog caught on fire.

Transcript source: Provided by creator in RSS feed: download file