What, an "optimization"? Are you suggesting that Bluesky would work today without the optimization, just slightly slower? Or what do you mean by that?
If your information isn't out of the date you probably know that nothing of Bluesky works without the "relay". And sure, you can argue, as you have elsewhere, that Bluesky can change to actually connect directly to PDSes, but then you will need to trash all the labelers, feed generators and app views and the client app codebases, as they all assume the existence of the "relay", and then you'll have to create a query language for the PDSes and proceed to recreate all of these things on the clients directly -- and then obviously you would have just created Nostr again (and then you have to start working on the same problems Nostr has been working on for the past years).
If that ever happens then great, we don't need Nostr anymore -- but if you are indeed following Bluesky you have probably read directly from the Bluesky creators that they do not intend to do any of this decentralized data-fetching stuff ever because they think it is a bad idea to not have a canonical centralized source of data, it's an irreconciliable divide and no "progress towards decentralization" can be expected from them, at least not decentralization in the way we understand it.
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.
Making the assumption that every relay is going to see ~every post is very much not the same as assuming there will only be one relay. You’re just putting words in peoples’ mouths, then.
And you are reading only parts of my posts and responding to those parts as if I hadn't said anything else.
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!
Censorship resonates with a large number of people! Great! We are building for everyone else.
I think having an algorithmic feed resonates with people a hell of a lot more, certainly drove early adopters.
But, yea, people love filter bubbles (censorship being just one way to get that), that’s why most people are on nostr, too! :p
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?
AFAIU you can have an App View that uses a relay, but could also be one software package. conceptually for the purposes of this discussion it’s really one thing.
Oddbean new post about login | logout