• 0 Posts
  • 18 Comments
Joined 8 months ago
cake
Cake day: November 5th, 2024

help-circle
  • That’s just life on the Internet/fediverse in general, there’s a constant churn of the small websites/instances as people inevitably burn out. You gotta be mentally prepared for it. I’m really sad since .ee was one of the few good instances that federated with the unpopular ones too

    The only solution is improvements to the protocol so migrating instances is less painful. A different form of identity (key-based rather than domain based) would be cool to let us keep handles across instances





  • 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 controlled by bluesky like PLC).

    Unless you mean that you still have to register your pds it to get indexed by the relay, so people can read your posts without querying your server directly (which is possible but discouraged). This is actually an advantage over mastodon/activitypub however, your personal pds will not crash if a post goes viral (unlike a personal mastodon instance).










  • Yes, and I’ve been yelling at them about the problem of scaling down for a while, since the same “relay” service needs to be both a firehose and a full mirror. This requirement (and thus scalability) of running a relay is becoming a big problem even for the main devs. According to them however you can mitigate this to a reasonable amount for a home lab (~8 cores, 16gb ram, ~2Tb ssdl) if you simply don’t store any backlog and just retransmit posts https://bsky.app/profile/why.bsky.team/post/3lbjdux6ubc2f

    This is what they’re doing internally to manage the load and are also working on implementing relay sharding/scoping to let you just index a small slice of the network, which should eliminate the problem. https://github.com/bluesky-social/atproto/discussions/3036 and here’s someone implementing a proof of concept third party version https://bsky.app/profile/pet.bun.how/post/3lbwnx2rxxs2o

    It’s true that the main devs’ priorities are building the large scale parts first and then worrying about downscaling, the whole point was always to replace twitter and work at a similar scale, which requires hard tradeoffs. I do worry that they’ll run out of money before they can do the work to let the ecosystem become sustainable by itself.

    But I have faith (for now) because they have people I know from when they worked on secure-ssb and dat protcols, which are truly decentralized but never took off for other reasons.



  • The entire point is that your pds can interact with multiple “instances” of bluesky or whatever other apps people build on the protocol.

    For example there is a reddit/hn clone that people can post on (keeping their same identity) when the official bluesky service goes down. The reddit clone is fully independent from the twitter clone, but they use the same protocol and (unlike AP) the same hosting and authentication infrastructure.

    Whereas on Lemmy and mastodon, my accounts are totally separate. And unlike AP, your data lives on your own pds and is never hostage to the owner of the instance that actually runs the load bearing interactivity. If they become compromised or shut down you can switch to another. No cooperation from the old owner required (unlike activitypub).



  • I asked the devs about this and they said that bluesky is designed to be a) modular b) trustless as much as possible. federation is supposed to happen on the trustless hosting and relay layers - you can ask your posts to be crawled by any indexer/appview.

    But once you get to the indexing/querying layer, there are no more merkle proofs to keep everyone honest, so there is no point in federating because any indexer can modify/censor the content they send to another indexer instance. So you could still build an api to interact laterally between servers, but it wouldn’t be atproto anymore.