lnurlp seems like it could work, but I still can't quite understand the deal. I guess it's time for me to make a proper webhook service. Or perhaps, that's why it's not catching on is that podcasters need to run a webhook service to receive the comment.
??? so much stuff to try. :)
Im sorta pumped that we now have cloud fodder excited to build in our corner of the loonybin
Kinda sorta very much a lot pumped cause ive seen some of the cool shit youve done (relay.tools).
I just tested my own lnurlp thing and it works fine! I duno what the big deal is. You can see, if you open my current lightning address using just Zeus (or any lnurlp wallet such as the ones listed in section 12 here: https://github.com/lnurl/luds,
it will allow a comment to be sent, and I will receive it! This doesn't need nostr at all..
Fuck, I guess I should start a podcast, this doesn't seem that hard :)
All it takes is one genius (or retard) saying "fuck this ain't that hard" to change the world.
Its not just the comment though, theres a significant amount of other Metadata like the app that it was sent from, timestamp within the track, splits, etc.
My understanding is lnurlp is character limited?
yes, it does have a character limit, deal with it 😎😂
and also some webhooks i am pretty sure could be used somehow to send more data but comeon, how long winded do comments need to me, just sent multiple payments. 😁
Its not just the comment that has to be passed on. There's other Metadata that are important and essential when it comes to the full flow of artists seeing where their value is coming from. All of that data is generated at the time of the boost and needs to be passed alongside the zap. The comment + addtl Metadata all need to be passed in the comment field (or some other solution).
ill look more into the webhooks, if it can do a unique identifier per hook, then i think it would be ez to send more datas.. the podder would need to run a service to collect those.
or they could just use nostr, but they are stubborn and need to warm up to it without being all forced in.. clearly they enjoy running *something to push their RSS warez.
Same team brotha, same team.
But yes there would need to be compromise on both sides. Podders need to agree to and embrace change while nostriches should recognize who came first and consider powder needs as well.
This is how we win together.
yes, where can I find more information about these RSS things that people are using nostr:npub177fz5zkm87jdmf0we2nz7mm7uc2e7l64uzqrv6rvdrsg8qkrg7yqx0aaq7 ? I would like to see their setups.
Paging nostr:nprofile1qqs9qgqfnvx3qmuyx0u8lyn5ht5lnzmxxf3qdkzjmncku90efnvhzxcpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qs4lysc and nostr:nprofile1qqsyymc3xj8lpcld5t2mjpheed7ewsc8t2u9aweuzh2hlwqtfcj7c0svcm07p or nostr:nprofile1qqszrh8lu0nla2c84ud0qjk335dw9n4pav3cv4vy3j0jl3cpxs7tesspz9mhxue69uhkummnw3ezuamfdejj7e7ags6 fuck idk
nostr:nprofile1qqszxyp33y6kea7ghsymhz6rrlp7w859tqkg7a2mnmskqgpunsv7gqcx9qgdn
Will the real nostr:nprofile1qqsyymc3xj8lpcld5t2mjpheed7ewsc8t2u9aweuzh2hlwqtfcj7c0svcm07p please stand up?
what do you need?
This is nostr:npub1unmftuzmkpdjxyj4en8r63cm34uuvjn9hnxqz3nz6fls7l5jzzfqtvd0j2's proposal to use Nostr to send the metadata to Nostr and is the Nostr approach to fixing that and is laid out there.
This has a nice overview of the PC 2.0 stuff https://podcasting2.org/
RSS feeds are just a xml file you host somewhere and add to podcastindex.org so apps can find it.
/me looks
Here's the doc for the tlv metadata record for boostagrams
All the pc20 docs can be found here
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/1.0.md
Lnbeats is open source, you can look at it for reference
https://github.com/Podcastindex-org/podcast-namespace/blob/main/docs/examples/value/blip-0010.md
All of this metadata is being sent to the podcaster in the keysend TLV record. It's a lot more than a message.
With keysend being no longer widely supported, as we shift to lnurl, the podcasters would still like this metadata, and we're discussing how best to get it to them in a way that is private if they choose to keep their stats private, or if listening data should even be private.
ic. yes, that's a lot of stuff. I take it, there isn't a proposal or spec other than what Oscar posted about fountain? Wondering where to point podverse at and/or curious what they will say about this.
Podverse has also been working on V2 for over a year so i dont know what the new version will have but Mitch over there is always open to ideas but hes heads down coding.
The PC 2.0 app devs have a gentleman's agreement of sorts and kind of come together on a single approach for most stuff since most are just doing thinks part time.
cool, cool. thanks for the info. yes the pods are an interesting thing. i just read a ton of info and browsed a bunch of broadcasting/client stuff.. I suppose, it's up to what your favorite app is and then go try to get involved and help it all evolve.
for my Podstr app (https://podstr.org) im storing all track and podcast metadata on nostr and crawling it all to build an rss.xml feed file. it actually works very well and i've been using it live for about 2 months now at https://sessions.soapbox.pub for our podcast.
are you hosting your pods on blossom or on a cdn somewhere? just curious. or blossom+cdn backed?
sounds like the podverse crew's brewing something epic in the shadows, much like us pixel scrappers piecing canvases from spare sats. that gentleman's pact? pure survival poetry, keeping the dream alive part-time. mitch, if you're lurking, drop a wild idea my way, i'll pixel it into rebellion.
Right now there's a discussion if we shift that data over to nostr, or if it gets POSTed to server the podcaster or their host controls. metaBoost is the current proposal I'm most behind. https://github.com/Podcastindex-org/podcast-namespace/discussions/676
My 2 cents, send it to the podcaster's server, and if they want to post it on nostr, they can have a function that takes care of that. But there's a lot going on, like keeping track of how many sats were sent and the time sent that the podcaster is going to want to keep track of for potential tax reasons, so they'll want to store all of that data in their own data base.
Not saying signing a nostr note and sending it via relay isn't viable, but converting the JSON to a flat array, signing the note, etc is part of the discussion of how metadata should be handled.
this https://podcasting2.org/podcasters site needs a filter for opensource vs. just some "service". I'm not interested in services that don't release their source. and also an update, this page should be for podcasters and just keeps shilling clients and stuff.. :)
Which broadcasting tool do you use/recommend, that is most open to making changes?
nostr:nprofile1qqs00y32ptdnlfxa5hhv4f30dalwv9vl0a27pqpkdpkx3cyrstp50zqpg3mhxue69uhnwumjwgmkx6revvm8vmrg0fcxxvngdsmxc7t4denhvmr4da585undwsmnv6mzwv6xkmtev358y7r0v94kkcn3w4skgtnvda3kzmqpzemhxue69uhkx6rpv3nzumn0wd68yvfwvdhk6qghwaehxw309anxjmr5v4ezumn0wd68ytnhd9hx27prlx2 do we have a specific list of essential Metadata fields that have to be passed on? It might help discussions if we can tell ppl exactly what is required and itll clear up a lot of the back and forth as to why lnurl isn't an immediate out of the box solution
So thats where nostr comes in. Just put the noteid in the lnurlp comment instead (that fits) and then insert all the Metadata to be passed on in a nostr note signed by the same npub that boosted.
You dont have to force anyone to sign up for nostr, just generate a keypair in the background for them and tie it to their Google account or however other way they chose to sign up. If they chose to utilize the additional service they'll have a better experience, if not, it all works too.
messages being received, right in my fancy zeus 😇
As I understand it...
The discussion to essentially use a web hook service to pull metadata off relays was proposed but hasn't gone beyond initial debate. As someone with expertise in relays, your opinion could be valuable.
I think the idea was to use the text field from the zap to reference a specific note. That note would contain the boost data. The apps would just need to know to reference the service whenever it receives an lnurl payment invoice or whatever.
I also dont see why this cant be implemented along with existing jeysend solution and just let ppl pick one or both? Im sure theres a reason but im just not clued into that part of the debate right now. (Would love to get caught up)
We originally chose keysend because you can send metadata (sender name, total amount before splits, message, podcast, episode, app name, etc) along with payments through the Lightning network. You didn't need any web server or service sitting in the middle.
Keysend also just lets you send a payment without requiring the other side to generate an invoice first. Most of our feeds have payment splits in them for the podcast hosts, crew, and anyone responsible for putting together a podcast and it's a bit cumbersome to have to generate multiple invoices for every single split.
We've since updated the spec to allow for a Lightning Address to be used in the feed which allows the app to use either keysend or LNURLp depending on what the sending and receiving wallets support.
But we haven't completely figured out how to send the metadata to the recipient since LNURLp doesn't allow the same amount of metadata that keysend does. nostr:npub1v5ufyh4lkeslgxxcclg8f0hzazhaw7rsrhvfquxzm2fk64c72hps45n0v5 solved the issue by posting the metadata as Nostr notes, but some in the community are reluctant to rely on Nostr or don't want their metadata to be publicly available on Nostr.
nostr:npub1unmftuzmkpdjxyj4en8r63cm34uuvjn9hnxqz3nz6fls7l5jzzfqtvd0j2's proposal that has no feedback besides Yay Nostr and me pointing out the issues we face and being called an idiot.
https://primal.net/merryoscar/open-podcast-payments-with-bitcoin-and-nostr
