@lyse@lyse.isobeef.org and @movq@www.uninformativ.de and possibly @aelaraji@aelaraji.com and even @cuaxolotl – I’m very curious to understand and hear thoughts, pros and cons or other feelings about introducing the notation of a feed’s identify using cryptography? If we were to keep things simple, and use what’s commonly available, for example SSH ED25519 keys? using the ssh-keygen -Y sign or ssh-keygen -Y verify tools already available? Maybe in combination with @xuu@txt.sour.is ’s idea of generating a random unique ID for your feed, say # id = and signing it with your ED25519 key? 🔑
@prologic@twtxt.net I’m very torn on this.
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
@movq@www.uninformativ.de No that’s okay. I happen to agree with you really, I just wanted to get a bit of a vibe on using cryptography in general and the idea of signing feeds. It’s not particularly about a problem being solved, just gauging your opinions/thoughts on this 👌
@prologic@twtxt.net I’m basically with @movq@www.uninformativ.de, but in contrast to him, I’m not looking forward to implement something like that. :-)
A feed URL is plenty good enough for me. Since I only fetch feeds that I explicity follow, there is some basic trust in those feeds already. Spoofing, impersonation and what not are no issues for me. If I were to find out otherwise, I just unsubscribe from the evil feed. Done.
To retrieve public feeds, I just rely on TLS. Most are served via HTTPS. If a feed is down, I’m not trying to fetch it from some other source, I just wait and try again later. So signed messages/feeds are not a use case I’m particularly benefitting from.
To me, it’s just not worth at all adding this crypto complexity on top.