4 ms·

The problem with atproto is that it's rediculously complicated. Every detail in the spec done in the most difficult and stilted way possible. They could've mad

The problem with atproto is that it's rediculously complicated. Every detail in the spec done in the most difficult and stilted way possible. They could've made something much more like Nostr be at the core of it all, so that the barrier to entry is small for people wanting to write their own implementations, but the developers/designers of atproto put very little value in simplicity. They wanted everything to be as powerful as possible at every single layer, which means far too many levels of abstraction, super heavy-weight implementations, and stacks upon stacks of specs that are hard to unravel, etc. Anyone can learn Nostr in minutes. To learn atproto you need weeks.

aintly 2y ago
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.
- quantadev 2y ago
  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.
  - jazzyjackson 2y ago
    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.
    - quantadev 2y ago
      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.
      - rglullis 2y ago
        > I never heard of anyone wanting to use a domain name as identity in Nostr https://en.wikipedia.org/wiki/File:Survivorship-bias.svg 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.
        quantadev 2y ago
        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.
        rglullis 2y ago
        [dead]
shark_laser 2y ago
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.
c-cube 2y ago
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...
- quantadev 2y ago
  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.
  - c-cube 2y ago
    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.
    - quantadev 2y ago
      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.

aintly 2y ago

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.

quantadev 2y ago
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.
- jazzyjackson 2y ago
  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.
  - quantadev 2y ago
    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.
    - rglullis 2y ago
      > I never heard of anyone wanting to use a domain name as identity in Nostr https://en.wikipedia.org/wiki/File:Survivorship-bias.svg 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.
      - quantadev 2y ago
        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.
        rglullis 2y ago
        [dead]

shark_laser 2y ago

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.

c-cube 2y ago

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...

quantadev 2y ago
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.
- c-cube 2y ago
  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.
  - quantadev 2y ago
    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.