Natanael

It doesn’t get served to all, but it has to be served to a relay which in turn is reachable by all.

While there is a firehose service which publishes all events as they happen, only services built on watching those needs to receive all (moderation services, etc). Everybody else gets a view already filtered and composed by services earlier in line. See jetstream as an existing optimization already delivered by bluesky themselves which reduces traffic.

A limited scope appview and relay is possible too, you can choose to only serve one community, and then fetch external content on-demand (but this will have the same impacts on latency as Mastodon and lemmy has when opening previously unseen threads)

In fact, it is worse than the storage requirements, because the message delivery requirements become quadratic at the scale of full decentralization: to send a message to one user is to send a message to all. Rather than writing one letter, a copy of that letter must be made and delivered to every person on earth

That’s written assuming the edge case of EVERYBODY running a full relay and appview, and that’s not per-node scaling cost but global scaling cost.

Because they don’t scale like that, global cost is geometric instead (for every full relay and appview, there’s one full copy with linear scaling to network activity), and each server only handles the cost for serving their own users’ activity (plus firehose/jetstream subscription & filtering for those who need it)

For Mastodon instance costs, try ask the former maintainers of https://botsin.space/

There’s literally no restrictions other than simple rate limiting, which you can ask for exceptions for.

I don’t know a Mastodon/lemmy server which wouldn’t rate limit new peers

Partially - something running independent infrastructure like Whitewind (blogging on atproto) will still work just like before (it’s easier for them to run it independently because you don’t need a full network view, just pull in the posts from the user’s PDS for standalone display)

When the work to make appviews easier to run makes it more practiced this will be less of a risk.

No, it doesn’t scale “quadratically”. That’s what going viral on Mastodon does to a small instance, not on bluesky. Pretty much everything scales linearly. The difference is certain components handle a larger fraction of the work (appview and relay).

Both a bluesky appview and a Mastodon instance scales by the size of the userbase which it interacts with. Mastodon likes to imagine that the userbase will always be consistent, but it isn’t. Anything viewed by a large part of the whole Mastodon network forces the host to serve the entirety of the network and all its interactions. So does a bluesky appview, in just the same way, but they acknowledge this upfront.

Meanwhile, you CAN host a bluesky PDS account host and have your traffic scale only by the rate of your users’ activity + number of relays you push these updates to. Going viral doesn’t kill your bandwidth.

No, PDS federation is fully open now.

They’re also actively supporting development of 3rd party appviews and relays.

Maybe you remember PDS federation not being open for a while, but it’s open now.

Running a public appview can be very expensive, but they’re working on making it cheaper to run one with a limited scope.

They never said they’d do so natively with other protocols - but they support Bridgy, so you already can do that.

Domains only help you verify organizations and individuals you recognize directly.

This verification system also allows 3rd parties (it’s NOT just bluesky themselves!) to issue attestations that s given account belongs to who they say they are, which would help people like independent journalists, etc.

One shelter is very valuable, a second shelter has extremely questionable value to me.

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.

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)