Sir Alecks Gates

https://podcastindex.social/@alecksgates

Podcasting 2.0 consultant
Master of the protocols
Knight of Podcasting 2.0
Inventor

INTJ-A

#Wisconsin -> #Tennessee

Essays: https://write.agates.io
GitHub: https://github.com/agates
GitLab: https://gitlab.com/agates
XMPP: xmpp:[email protected]

Public Key

npub1j0hf3w389k69mc6s0etpasn5658e5pd2zl03sj5fs3s55geem3dq94u952

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsf8m5chgnjmdzaudg8u4s7cf6d2ru6qk4p0hccf2ycgc22yvuackspzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc985lwe

Publishing to

nostr.wine

relay.damus.io

nos.lol

Author Public Key

npub1j0hf3w389k69mc6s0etpasn5658e5pd2zl03sj5fs3s55geem3dq94u952

Show more details

Last Notes

2026-03-23 18:59:49 CET

- reply

I can't speak for Dave, but I think this experiment exists in this state in the event of an immediate Hive disaster.

2026-03-23 18:59:02 CET

- reply

As far as I'm concerned, it's Podping just on an additional messaging layer.
I have yet to get my hands on any of it due to more important obligations, although Dave and I talked through the implementation quite a bit.
Personally, when I can get some time to work on it, I am going to try to add both gossip listener and writer to podpingd which will watch both Hive (which it already does) and gossip.

2026-02-20 16:49:38 CET

- reply

How are you submitting to Hive?

2026-02-14 05:12:34 CET

Wallet-hosted value metadata URLs makes anything other than lightning impossible. I will never support it for that reason.

2026-01-11 23:05:45 CET

- reply

I honestly think we can gamify it

2026-01-10 17:59:40 CET

- reply

I'm using Gemini CLI. It's been great. Gemini 3 especially.

2026-01-01 00:23:28 CET

PSA: IronFox on Android supports UnifiedPush.
A great feature if you use any sites/PWAs with browser notifications and want to avoid metadata leakage through Google's push notification servers.
If you're on GrapheneOS, it's available in Accrescent. You have to manually enable UP in the browser settings

2025-12-31 23:48:19 CET

- reply

I made a proposal for this.
https://github.com/Podcastindex-org/podcast-namespace/discussions/620

2025-12-17 07:11:37 CET

- reply

Add to that people don't even agree on the definitions of a lot of genres. So expecting anyone to agree is basically pointless.
The owner can tag it what they want, but should also expect to follow some basic guidelines if they want it to be useful for discovery.

2025-12-17 06:51:33 CET

- reply

I think it would be rather straightforward for the community to maintain a slug list like with anything else.
That slug list could be internationalized

2025-12-17 06:50:07 CET

- reply

Just need some music feeds to implement it.

2025-11-07 18:52:27 CET

- reply

You just said we should continue to host metadata on wallets and now you're coming back with this, which appears to be an entirely different thing.
This is going in circles. One seems to be a specification and the other is an implementation detail.
I don't really care how you implement it. As long as the standard to host metadata is payment agnostic and determined by the podcast/host in the feed. A link to that metadata in the payment is fine.

2025-11-07 18:43:13 CET

- reply

What about other payment methods?

2025-11-07 18:33:30 CET

- reply

This doesn't make any sense. They could just host their own metadata.

2025-11-07 18:19:12 CET

- reply

I think I'm missing something. What does the wallet have to do with it? Why does it need to be aware of the metadata outside of a link to it?
I'm replying during my day job (ask Adam/Dave how hectic it is) from a mentioned notification, so maybe I overlooked something obvious.

2025-11-07 17:42:19 CET

- reply

Sorry what exactly is the problem with an API in the feed managed by the podcast host? I haven't seen a legitimate criticism.

2025-11-07 17:41:08 CET

- reply

The solution needs to be payment provided agnostic regardless. Bitcoin or not.
Everything else in the feed is from the "host" -- the source of truth. Why would we change that now?

2025-11-07 17:35:29 CET

- reply

we should deleted all of the noagendatube feeds from the index :)
I guess I can do that from the admin page right?

2025-10-19 03:18:05 CEST

- reply

I think a growth mindset is important to have, but it's a lot more specialized than we're led to believe.
It's not healthy to outright reject such specialization, either. Some things *do* need to scale, even if one can't comprehend why. We all have our own problem domains.
Desire for profit is another matter. People will do anything to retain their social status and power, and I don't see that stopping any time soon.
Maybe the cycle of empires is inevitable?

2025-10-14 03:02:10 CEST

- reply

And now we live in a world where our most valuable asset is our attention and the average person's spending power is almost irrelevant to the economy.
Technofeudalism, perhaps, for lack of a better word.

2025-10-06 13:39:27 CEST

- reply

updated with what?

2025-08-08 16:55:40 CEST

- reply

Yes, the reason it wasn't usable in antenna pod until recently is there was an issue with the video format for playback. So I had it default to HLS.
(I still don't know why they never added support for HLS streaming, seems like an obvious win, but hey it's not my project)

2025-07-20 22:13:58 CEST

- reply

that's Steven Crader's service. I maintain the python one. But also have a rust version I'm working on (podpingd).
The python/JavaScript ones shouldn't be directly affected, but anything not expecting the new mediums or reason codes will need to be updated.

2025-07-20 17:28:09 CEST

- reply

If I don't get any feedback on this, I'm probably just going to do it :).
Need to get radio mediums added to Podping as well for @npub1thg…zq23

2025-07-10 05:29:35 CEST

Hi.
I'm thinking about adding a new reason code to Podping to indicate that an RSS feed has added a new item.
This would primarily serve as a means to allow consumers to prioritize parsing of new episodes vs regular updates -- similar to "live" and "liveEnd" but for standard items.
It would particularly be useful for notification systems on the client side. But we also use different reasons to prioritize Podpings in podping-hivewriter to (so "live" is sent before "update").
Pros/cons?