@dave @adam I see the podcast-namespace docs recommend bundling streaming sats payments every 15 minutes to reduce network load.

Are boosts supposed to be sent immediately? If a user manages to press boost 10 times in a second, should we bundle those into one transaction? Or should we rate limit them on the front-end? Any best practice recommendations?

Also @satoshisstream are these bundled transactions (at least for streaming sats) covered in the SatoshiStream spec?

@mitch Where is bundling defined @dave ?

Bundling will remove some context (timestamps)... Something we should really think about :)

@satoshisstream for now I'm thinking I will send 15 minutes worth of the streamed transactions to an address in 1 transaction, and will use the time/ts values that correspond with the point within the episode when the bundled transaction was sent.

It looks like none of the other SatoshiStream metadata should have a problem with bundling transactions.


@satoshisstream also fyi "itemID" for episodes is unavailable for any podcast service that parses RSS feeds themselves (any project that doesn't rely on Podcast Index for parsing all of their RSS feeds, like Podverse).

Lack of universal ids in RSS feeds is one of the biggest dev limitations for podcast apps though. Just noting that SatoshiStream events are another use case we could use them for.

@mitch Yeah they could give the GUID + RSS url as identifiers right?

@satoshisstream @mitch I've proposed a sha256 hash of feed url and episode guid.

I'm using that internally.

@brianoflondon @mitch That would work... Concat them? Concat the json string? Or with something in between?


@satoshisstream @brianoflondon @mitch
I'd really like the universal episode id to be something that can also be unpacked to it's original parts. Like base64 instead of hash. That way you don't need to do any lookups to get from id to rss url + guid.

· · Web · 2 · 1 · 2

@satoshisstream @ville @mitch the reason I hash is to avoid nasty characters like : / which are in urls and guid often.

@ville @brianoflondon @mitch Or we can go for good old JSON.

{ 'feedurl' : 'domain.com/podcast.rss', 'episode_guid': 'XYZ', 'ts': 1337 }

Possibly base64 the whole json string. Players can pick the part they like. Not all will use ts.

@satoshisstream @brianoflondon @mitch
This would be ok otherwise but if you happen to put the keys in wrong order it would end up in different id 😅. Or even different indentation. A bit brittle perhaps.
And we should ditch the ts from id. It's part of the sharing but not identifying 🙂

@satoshisstream @brianoflondon @mitch
We'd need to change the base64 to something else if we want to avoid / in the result id.

@satoshisstream @brianoflondon @mitch
Or we could replace the /s in the result base64 with some other character like pipe as @satoshisstream suggested 😄. It works add an extra step which would likely cause confusion in some situations.

@satoshisstream @brianoflondon @mitch
Somehow I'd prefer / as the separator, like a path in url. And maybe add optional int/float at the and to enable pointing to a specific point in the episode.
Actually the whole thing as I have been thinking would be like this:
(The last part might as well not be base64'd cause it's just a number 😄).

@satoshisstream @brianoflondon @mitch
I was gonna propose a way to cross share episodes with timestamp and this would suit it well. The idea would be that each conforming app would support a url like domain.com/podcast/base64rrsurl/base64guid/time.
Then you could share that link from app a to app b and the app b would just ignore the domain and parse the episode and rock on 📈

@ville @brianoflondon @mitch I like base encoding all parts for sharability / being really able to split parts.

@brianoflondon @ville @satoshisstream @mitch If I’m understanding the goal here, it’s to be able to (after the fact) reference a single podcast episode in a way that is immutable, and source agnostic (meaning doesn’t depend on any api or index)?

@dave @ville @satoshisstream @mitch for me yes, I arrived at this need when Adam messed up something on the Podcasting 2.0 feed that meant a show with an unchanged GUID got a new Podcast Index Episode ID.

That caused my Hive script to double post something.

That's when I started working on a hash of GUID and podcast URL.

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system