It's not so bad. I managed to create a minimal implementation of a PDS for a Bluesky bot that can make simple text-based posts, and it only took a couple of days. Kind of lost interest in it after that but it was reasonably straightforward to iterate on. The trickiest bit was getting the subscribeRepos websocket to work, mostly because the documentation was unclear.

Maybe so but I bet you 90% of the code you were running was already written because it was in a library right? So you didn't really have to understand it. You were just running someone elses code.

With Nostr, for example (or even RSS), you can fully understand it from end to end, in minutes. As a former IPFS deloper myself I can assure you in just 2 days you didn't even understand the CAR format of a repo, unless you had prior experience.

I don’t know, as an IPFS developer you might be discounting what prerequisite knowledge you possessed while hammering out a nostr implementation.

I looked at nostr but lost interest when I noticed there was no provision for key rollover. I guess that’s fine but ephemeral identities. Is there a concept of using a domain name as a handle like bluesky? It’s been a few years so maybe it’s worth a second look.

I always considered the permanent keys/identities of Nostr to be a desirable thing. I had basically invented Nostr before fiatjaf did. It's a trivially simple "concept".

Key rotation is an unnecessary complexity, imo. I never heard of anyone wanting to use a domain name as identity in Nostr, but there's probably a NIP for that where a domain can prove it owns the private key, and be used as an identity.

I mainly quit Nostr development because it was all essentially controlled by 'fiatjaf', and he was making bad decisions, and a childish intolerable arrogant person in general whenever people asked him to justify those decisions.

> I never heard of anyone wanting to use a domain name as identity in Nostr

https://en.wikipedia.org/wiki/File:Survivorship-bias.svg

The one thing that completely turned me off nostr is the idea that my identity is tied to my private key and that it can not be recovered. I'd guess that the reason you don't hear from people like me is that we simply don't bother to work with such a boneheaded design.

I always felt like in the age of cryptocurrencies, people can be expected to protect their private key, and yeah pretty much if they lose it, they lose their data. I mean that's how encryption works also. No key, no data. I don't call that boneheaded. I think it's a feature not a bug.

Came here to say this.

Nostr is so far ahead it's not funny, in part because of this, in part because it's actually decentralised, in part because of already existing features built in to almost every client, like zaps.

I don't understand why anyone would invest their time in ATProto over Nostr, and don't know anyone who has studied both and has.

Can nostr be used for the same form of social network as bluesky (ie, a twitter clone)? It seems that it would only show messages from people the user explicitly follows, for example, and not replies by a third user.

Also it's distasteful to do any sort of content addressing on json data. One would think they'd learn and use CBOR after seeing secure scuttlebutt, but no? Now you have to worry about only sending text payloads, escaping some characters, avoiding whitespace when printing the json... Guaranteed to be a source of bugs...

1) It's up to the relay and the software how much of the firehose of posts to present to users. Your client is in control if whether you see posts from your follows (who you follow), or the entire world.

2) One of the things Nostr did get [slightly] wrong was the hashing of the JSON. It's pretty straight-forward to sort properties, and remove spaces, to create canonical JSON that can easily be hashed, but (and I forgot the specific reason) Nostr made it where you can't directly store Nostr in IPFS (for example) and have the post hash/ID be identical to the IPFS CID of the canonical JSON. They missed that opportunity because fiatjaf was not well enough versed in IPFS, so he got that a bit wrong.

All that being said I am still a fan of Nostr. It is far better than other Social Media protocols imo.

I think they should have not reinvented the wheel ;-) and use dCBOR42, which has an actual canonical form. But somehow people like to use json in places where it's shown again and again it's a terrible choice.

The problem with CBOR is that once people relate it to IPFS their will be massive push-back, because IPFS is seen as too complex. I know this is true because I saw it happen. To these kids even XML is deemed "too complex", thus their love affair with JSON instead.

The reason Social Media protocols need to be kept simple is precisely for this reason. Getting developers to all agree on things is next to impossible. So the way to combat that is by removing all those "things", and go with the simplest design that's workable. It's almost like politics in that it's "The Art of the Possible". And to be "possible" in this context means universal acceptance.

Maybe you're right, that's quite sad. I found dasl.ing to be quite nice and simple as a foundation for dCBOR42, without needing the full ipfs craziness. Oh well.

ok. And you're right too that CBOR is the "correct" thing to use (despite what I said about acceptance), if we wanted to do it right. CBOR could be the only "complex" piece. Everything else could be Nostr-like (i.e. simple, and using relays).