Natanael

I’m not sure you know what content addressing is.

There’s no definition of “inherently valuable” which doesn’t rely on arbitrary axioms. Especially because no amount of inherentness can guarantee a minimum price.

Bluesky is federated in terms of that you can swap out arbitrary components and let anything talk to anything. Any app can talk to any appview, that appview can talk to any feed generator and moderation labeler for you, all three of these can talk to any (and multiple!) relays, etc.

This isn’t 1:1 federation, there’s no reason for one feed generator to talk to another, no reason for an appview to talk to another, no reason for two PDS account hosts to talk. Users on different appviews rely on their respective appviews having at least one shared relay to be able to see each other, and that relay can be swapped out. Every other component look at trusted moderation labelers for flagging content and takedowns - and they all choose independently who they trust. Every PDS just wants to talk to one or more relays to make their users’ posts visible.

So you can have a pair of users on the exact same set of infrastructure (most regular bluesky users), but you could also have 2 users sharing nothing but the bluesky relay (or another relay) and still talking to each other.

Since it very heavily relies on domains for readable addresses (using a DID directly is possible but annoying) it’s kinda hard to use in isolated physical networks. Technically you could make an app host its user’s repository and hold a copy of the signing key and publish it locally, but you’d lose a lot of thread visibility unless the app archives everything to republish. Or else you can have a separate offline only lexicon for posting locally, I guess, imitating scuttlebutt.

Go away.

Even I2P uses supernodes, that doesn’t make it centralized because you don’t depend on them.

You don’t need ultra purist single-type-node mesh like scuttlebutt to be decentralized.

Bluesky is federated, where the federation has multiple layers and EVERY layer can be run independently and interconnected to other nodes.

You can even connect to MULTIPLE! An appview can talk to many relays, a PDS account host can talk to many relays, anybody can subscribe to multiple separate feeds generators and moderation labelers hosted wherever, using any app, etc.

Beyond that, you still have not addressed that you said a blatantly self contradicting statement; that people self host relays, but also they don’t self host relays because that is costly and the self hosted relay code available to the public is experimental and mainly used for reasons tangential to the core function of a production ready relay.

Your inability to read remains YOUR problem, not mine.

My point is exactly this - it’s feasible to maintain your own private relay by mirroring the content you want, imitating both Mastodon and scuttlebutt.

You can choose to share a community relay - or not.

Running it for an audience of yourself is reasonably cheap. Running it for a worldwide audience is where bandwidth gets expensive. That’s why people run private ones.

Not capable of synchronizing with the original? Lmao. It’s literally content addressed, you can synchronize with every relay separately, swap arbitrarily between public appviews, regardless of who runs what and where it gets data from. It’s maximally capable of synchronization. It even beats nostr and scuttlebutt because you can VERIFY you have fresh and complete data (Merkle trees yay).

Pretty sure Whitewind pulls in data themselves directly when users use self hosted atproto accounts, maintaining its own relay index. Don’t think they make it publicly accessible though

Not having gatekeepers is what matters the most. You can run all infrastructure yourself and still interact with bluesky users (need to use DID:Web, but that’s a minor point)

Sorry what, an example of a 3rd party service proving 3rd party mirrors exists proves it’s vulnerable to what? It’s content addressed and as open as it gets, it’s literally designed to survive if the company goes down

Those are factors that create an expectation of value.

Generation why is the world like this

Not knowing what a relay does and going on the attack over it makes you the fanatic.

It’s an archive node, which can (but doesn’t have to) forward ingested data

Choosing to not understand the architecture is your failure, not mine

But that IS the point. The possibility of running independently PLUS the ability of bluesky users to migrate their account wholesale away from bluesky servers to 3rd party servers means you’re not dependent on them.

They’re literally designing for the principle of “the company is a future adversary” (see: Twitter, et al).

Currently, you have stuff like Clearsky (it’s basically an archive.org for bluesky)

Yup

It’s always been possible with the use of content addressing, it’s just that they’ve been spending most time building out core services and are now focusing on making it cheaper to run.

That post is very misguided.

First of all, he’s saying “you SHOULD make your PDS invisible to the bluesky servers because otherwise what’s the point”, but that’s exactly equivalent to saying “our community want it’s own Mastodon server - that means we MUST defederate Mastodon.social or what’s the point?”

That’s nonsense. Don’t enforce silos on people.

Also, which relays to support are not chosen by users, it’s chosen by the services the users choose. The PDS choose which relays to sync to, the appview does too, just like feed generators and moderation labelers does. They can trivially sync to multiple.

What people will choose is what app to use. This app will choose default appviews, and that appview chooses a relay, etc. Then they register an account, and the app suggests a default PDS server, or they host their own.

Also moderation labelers can be shared. Communities can run their own, and different communities who trust each other can import labels generated by the others.

Hosting a PDS is very cheap, it’s just storage and bandwidth for the posts multiplied by the number of relays you directly sync to. With a few users on each that’s nothing. It’s in the range of free tier VPS hosting, RPi grade.

Deduplicating is probably the most trivial part. There’s already code for handling duplicate events in streams. But more practically speaking, there’s algorithms like set reconciliation which can make it significantly more bandwidth efficient to subscribe to multiple relays even when they have overlapping content.

Tldr no there won’t be bubbles, unless that’s what the users want. They surely CAN choose services which filter out the bluesky servers and which don’t make them visible to bluesky, but why?

As for the DID part, the alternative is DID:Web, which requires permanent control over your domain name. With DID:PLC you can control your data by registering your own keys, although there’s possibility for censorship. Their goal is to separate out running the DID:PLC service to an independent foundation.

As for the followup comments, just a few months ago bluesky made it significantly cheaper to authenticate jetstream events via Merkle tree diffs (jetstream is the lower bandwidth version of the relay firehose service). This means you can verify correctness quickly just by having a copy of the Merkle root hash & pubkey for the accounts you’re interested in, you don’t need to store the whole user repositories (excellent for feed generators and moderation labelers and anybody else doing partial sync)

Calling it not federated is silly. It’s not like-for-like federated like Mastodon where you have a single server doing all roles, federating to other servers of the same role.

Instead it’s cross-layer federation. You can use any app, talk to any appview, use feeds hosted by anybody, use moderation services hosted by anybody, host your account on any PDS service including self hosting, and any appview can talk to any relay. It’s fully mix-and-match.

Two people on entirely disparate sets of servers & services using atproto can talk to each other as long as their appviews/relays mutually retrieve content from the other.

That’s federation.

That’s just if you want a complete copy. You can choose to store only parts of it, and retrieve what’s missing from other relay servers when you need it.

They’re planning on migrating to the new MLS group messaging encryption standard, which is built to support federated messaging encryption (more efficient than the current Matrix protocol)

(also, Matrix are also planning on adopting it, and the RCS spec is getting it too)

It’s long to take a while though. The standard is very recent and nobody has a complete implementation yet.

Those specs can be handled by a medium range laptop

Content addressing

The whole architecture is built around content addressing and allowing every account hosting server (PDS) talk to multiple relays and to allowing mirroring.

The whole point is to NOT create bubbles.

People already run their own PDS servers and participate with the official bluesky network, and can talk to users there, because their self hosted PDS syncs to the bluesky relay.

If you run your own relay and appview it STILL works, and you can talk without bubbles, if you still link your PDS to the bluesky relay to make yourself visible to their users, and if you set your appview / relay to retrieve content from the bluesky relay then you see content from bluesky users too.

Self hosted relays do exist, they’re just not open to the public (mostly used for archival / development currently)