Comment on Great ATProto blog post on the reasoning behind their design architecture

• Sl00k@programming.dev ⁨1⁩ ⁨week⁩ ago

  This is just wrong. Another platform similar to tiktok(spark) is in beta with their own infrastructure outside of all Bluesky servers and they have to deal with their own moderation. They can choose to read in any Bluesky data they please and bluesky can do the same with theirs.

  If Bluesky shuts down all servers tomorrow they still exist. The federation is simply adopting their Lexicon into your relay and appview.

  If you want a microblogging platform specifically you can easily run your own infrastructure similar to running an instance, intake all BlueSky posts and if Bluesky shuts down your app will continue operating using BlueSkys lexicon, however you’ll have to manage your own moderation.

  source

  • Ulrich@feddit.org ⁨1⁩ ⁨week⁩ ago

    Its not wrong. The COO of BSky herself told me this.

    source
• Little8Lost@lemmy.world ⁨1⁩ ⁨week⁩ ago

  After reading the article i think you might be wrong with this one.

  From what i got now is that there are 3 layers

  First is storage which can be completly or is decentralised

  Then backend/server/application layer which can be bsky or whatever ticktok alternative gets made which is not decentralised

  and then user layer/view which depends on the application

  What i want to say is that the relay can be exchanged through something else

  So pro atProto is:

  • data seems to be actually decentralised
  • applications sharing the data
  • everyone gets the data

  And pro ActivityPub is:

  • more alternatives of the same application/server
  • way better control over data (federation & defederation)
  • servers interact with each other nativly (atPr seems to let the servers only interact with data)
  • more efficient (servers can update clients, in case of at least bsky clients have to ask servers)

  pro ActivityPub? (unsure about the technical details)

  • moderation? As in shared lists
  • able to host by individuals? As in i dont need an compute intensive relay

  source

  • flamingos@feddit.uk ⁨1⁩ ⁨week⁩ ago

    But what about the DIDs, the things used to actually identify accounts within the ATproto ecosystem:

    But Bluesky has developed its own DID method, did:plc. Today, did:plc stands for “Public Ledger of Credentials”, however it originally stood for “Placeholder DIDs”, with the hope of replacing them with something else later. The way that did:plc works is that Bluesky hosts a web service from which one can register, retrieve, and rotate keys (and other associated DID document information). However, this ledger is centrally controlled by Bluesky.

    source

    • aeshna_cyanea@lemm.ee ⁨1⁩ ⁨week⁩ ago

      This is false, they support did:web which ties your identity to ownership of a DNS name (which is its own can of worms, but not PLC).

      The other part is that you still have to register it to get indexed by the relay, so people can read your posts without querying your server directly (which is possible but discouraged).

      source

      • flamingos@feddit.uk ⁨1⁩ ⁨week⁩ ago

        I spent a couple hours trying to create an account on pds.flamingos-cant.xyz that uses a did:web following the instructions here and the account at the end ended up with a did:plc, so IDK how you create a PDS with a did:web but it’s clearly not something they put a lot of effort into supporting.

        source
    • Little8Lost@lemmy.world ⁨1⁩ ⁨week⁩ ago

      i forgot the DIDs
      Oh no

      source

      • aeshna_cyanea@lemm.ee ⁨1⁩ ⁨week⁩ ago

        They support did:web too if you don’t like did:plc

        source