Oddbean

The comment about relay being an optimization was somewhat nitpicky, you’re just using the wrong term (technically the relay is a proxy between all the PDs’ and the app view, the app view stores all the posts too and you could drop the relay and replace it with the app view(s) connecting to all the PDSs directly). The “App View” is a server that returns the posts to display in the feed to clients (eg the mobile app). In practice the App View is what *has* to have a full copy of all the tweets, much like a nostr relay works in practice today. Clients simply making the same request to multiple App Views wouldn’t result in having to rewrite or throw anything away, I have no idea why you’re suggesting that - in general you’ll get the same response from each, just have to merge them on the client side.

But really I do not at all understand your comment here - literally the Bluesky devs encourage other relays to exist, and other people *do* run relays, just not very many because of the overhead. Suggesting that they view multiple relays as a bad thing is…. strange to me 🤷‍♂️

They have said over and over (maybe not in these words) that they think it's essential for apps to have a "guarantee" that they have seen all -- i.e. that users have read all that was written to them, or by someone, or with some tag etc -- that implies that the entire ecosystem of apps should rely on a single "relay". Their architecture diagrams also depict all the pieces talking to a single relay, their codebases all point to a single relay. There is no provision anywhere for an app that uses two or more relays. Of course they will say it is possible for others to run alternative relays, and they want that only insofar as it will validate their idea of decentralization, but the truth is that if someone is running an alternative relay they will not be able to use any of existing online infrastructure -- they will have to run alternative versions of everything configured to point to the new relay URL. If someone is running a relay today it's probably for hobby purposes, maybe not indexing the full network, someone trying to make their closed little sandbox of atproto, I don't know, a serious relay is already hard to run today, should get increasingly harder and virtually impossibly hard if Bluesky achieves its world domination plans.

Not sure there’s much else in that post? Only other point you made is that the only other relays are mostly for hobbyists stuff, which I think is mostly true. Don’t disagree so why respond to it :).

To be honest I have no idea of what this discussion is about anymore. If you stated the parts on which you agreed with me it would ease my confusion -- but I'll try to clarify now: I guess I can say that (1) we both agree Bluesky is not decentralized today; (2) you think it can be decentralized if and when more people start running more BGS and AppViews, I don't think that will happen and even if it does it will be inconsequential; (3) you think Bluesky has some cool features like custom feeds and I agree; (4) you think Bluesky is getting really big because of these cool features and I think they play a very minor role in their growth. Good summary? You also seem to think Nostr is broken in many ways and not innovating enough, but these points are vague to me. I would like to know what cool features could or should be added to Nostr and what is more broken so we can try to fix.

I don’t *think* it will necessarily become properly decentralized, but rather that it totally *could* and they are working toward it (whether they run out of resources before they get there I dunno), thus I think dismissing Bluesky as “not decentralized, next” is naive. But I can tell you for sure there the “custom feeds” feature, at a minimum, led to substantial early adopter/evangelist momentum. To a much lesser extent the decentralized labeling/moderation/censorship feature as well. Even if they didn’t drive material user adoption, they’re cool features we should be learning from, not dismissing the whole thing “because it’s not decentralized”.

IOW there seems to be a string desire on here to dismiss Bluesky for trivial reasons (“not decentralized”/“they got MSM coverage so the user growth doesn’t mean anything”/etc) rather than admit they’ve built a product that resonates with a large number of people and that has cool features we should learn from!

isn’t it just true to say that it’s not decentralized? There is a board, a legal entity etc. it *can* change, but as it is today, it is centralized. Not some “string desire”, seems to be just objectively the case?

> that post You too see the quoted posts? It seems like a "feature" of the client he is using. nostr:nevent1qvzqqqqqqypzprhy9yxf3vst9xv38zej9arxagsvw4sg7452k570z9yjh7djapyuqqsx56hsq8axc3phutmxa0fztjhfw27wrr20y2zglzg2pqn5cnzqvlqsuaks9

I don't know about your claims that the App View is the server that has to store everything. It's not clear what they do exactly, looks like they are just another soft-centralizing layer like a web2 backend that talks to the BGS (I'll start calling "relay" BGS because that's a much better name) and caches data for user consumption and also talks to users's PDSes on behalf of clients? In any case given that to run a BGS today you need many terabytes of disk https://whtwnd.com/bnewbold.net/entries/Notes%20on%20Running%20a%20Full-Network%20atproto%20Relay%20(July%202024) that must mean it is storing all the data. So we have both BGS and AppViews requiring storing all the data?