Oddbean new post about login | logout Woopdi doo they made a protocol that technically can be decentralized later on. Doesn't mean it is and they continue to significantly reduce the chances of it ever becoming freedom tech. It's still a twitter with no evidence that will change yet. I HOPE IM WRONG. Idc if it's nostr or bluebird I want to see government/elite resistant freedom tech and that shit is hard to build. How many Blockchains can be decentralized but aren't.
I don't even see how decentralization is possible at this point just by looking at their architecture. it's completely controlled centrally. I don't see how they are going to magically decentralize it to any useful degree.
matts post is pure hopium
Basically their architecture is “the thing that stores your posts” separated from “the thing that an app contacts to ask for which posts to show in the UI”. The first is trivially run today and federates no problem (ofc that’s easy). The second is runnable but hard just because of size. I don’t see why no one would run that, though, at least if you think nostr relays are sustainable.
the second thing being so large gives users the expectation that they can and should be able to see everything. and if/when bsky "decentralizes", some users will say it's not worth it trying to keep track of the people they're following and give up, or they'll stay on the largest chunks of the network, the most centralized core.
Bluesky contemplates federated backends sync all data, so that concern only applies to nostr (relays), not Bluesky.
sync all data? from where? sorry, i guess i'm learning still.
Bluesky separates the concept of the server that hosts your posts from the server(s) that clients connect to to fetch posts to display. The second group of servers intends to connect to every possible first group and download everything. It’s not like nostr where relays don’t sync.
I did a deep-dive on the code and the only part of the architecture that is not currently decentralized is the plc-service, which resolves the DIDs with a custom method. You can literally run any other component yourself. Arguably this is the most important piece, so criticism is valid. But it's not clear how to decentralize governance of such a system while preserving the UX. Bitcoin 'gave up' on trying by just piggybacking off physics with PoW for consensus, which was not obviously going to work when it was created. I think perhaps the ultimate solution is just to use Bitcoin for the ID consensus with something like the did:btc or did:ion methods. The incentives to host decentralized infra without a token are not strong. Even nostr struggles with this currently. https://app.ilograph.com/@mikestaub/atprotocol%2520overview/Protocol%2520Overview/_walkthrough/1
that architecture diagram looks insane. who is going to run all that?
Much of it doesn’t actually need to be run to decentralize. “Labeling services” are basically just entities publishing messages to add tags to users (for blocking/adult content/etc), so you can just skip that and not block, or someone can just run that part and you can “subscribe” to that with your own server for the rest… Also the UIs are on there and obv that’s just an app. Finally….. currently much of it is one “docker run” soooooo
That too, but even with the other parts. They have all the power and that's the important part. Member twitters "decentralized" beginning? How about hangouts?
All it takes is one person to stand up and build a new app with a different server and that goes away. It’s very centralized in practice today yea, but that can change fast…..or not. Depends on whether someone pushes it.
Hope they do but many may fear they'll start from nothing more than a server and no connections if Bluesky deems them dangerous for whatever reason. Take the risk and self censor with Bluesky for access to more content, or build on nostr and allow total freedom knowing you'll be able to connect to at leased %90 of the more limited user base.
Bluesky’s separation of moderation from hosting does reduce the chance of that pretty substantially. Unlike mastodon, where everyone is constantly screaming for servers to block each other, users can opt to do so without the operator taking that decision. Sure, the operator could as well, but the fact that they don’t have to (even if they think the content is objectionable) is pretty important imo. But the only thing that sets nostr apart here is that clients connect to multiple servers. That’s….a very simple feature to add to any social protocol? They could just add that and be done with it and then we’d have nothing. Not sure they will, but…
Hmm, the did resolution part isn’t all that critical to the overall system, DID creation is basically just adding a DNS/HTTP record. I guess I don’t really understand your concern here, tbh.
Wrong. DID creation is generating a key and storing it on their central registry. The DNS part is just an alias like NIP-05 and has no significance.
Mike and Fiatjaf are correct on DID. Matt’s perspective needs some nuance. One of DID’s challenges is decentralizing the resolution layer so maybe pegging to sidechain might do the trick but I don't fancy tokens so not something I have a clear assessment of. DID can exist independently as long as it is retrieved together, both metadata and verification keys. But all of you big boys need to zoom out. ** Firstly, Bluesky and Twitter today have become a reflection of the extreme polarization that plagues America - and that is incredibly sad. Nostr must remain non-partisan, enabling clients with footprints of Bluesky and Twitter, among many others in it - and it's up to people to pick relays and peek into different worlds within Nostr. . Until and unless Bluesky opens up a client for the right wing folks and anyone else, it remains centralized. There is no need to talk about “what if”. ** Secondly, user adoption is key. Only thing to understand about Bluesky is that they knew who their target early adopters were and went for it. That's all we need to learn from them. Who are Nostr’s early adopters? Tech folks (and it's not the 3 to 4 of you here but millions out there), bitcoin folks, people who need censorship resistance (investigative journalists, people from challenging places), people who are curious and those who just want to see all the client devs here succeed. ** Thirdly, listen to the users. Brazilian users were all here first but did not know how to find people who matched their interest. Then they left. I always see devs pissing on users for voicing out their problems instead of trying to understand the concerns. Privacy is needed for some people - and while Nostr can’t provide it atm, don’t forget about it - open it up to any devs who want to focus on it. **Fourthly - let your imagination run wild with Nostr use cases. Web5 was an incredibly simple and powerful decentralized platform but nobody understood the application side or impact of it globally. Man it breaks my heart to see it go but if there is anything you want to take away from it - start focusing on applications and use cases ** And lastly, one cannot just keep building stuff and then whining when nobody shows up. Builders have to go out there and start hustling for early adopters (i.e. figure out the persona of the target audience and creatively reach out). And then listen to them. Improve your product. And keep repeating the process - again and again until you hit your mainstream users.
Your deep dive missed the fact that they have a big central data hub that is ran by a single company that all apps hardcode and has all the network effect such that it is de facto impossible for anyone else to run another (and if someone did it would be inconsequential and useless since there would be no incentive for anyone to move).
Is this BS? https://alice.bsky.sh/post/3laega7icmi2q
Sure, but the only difference between that and nostr is clients defaulting to connecting to more than one data hub. It’s big in practice, but to suggest we should dismiss Bluesky out of hand and not bother to learn from the cool other stuff they’ve built because of that one difference is…. Weird?
Fair point, but that is tech debt not architecture debt. Apps don't have to hard code this, its just convenient for now. The source of truth is the PDS and you can self host that with did:web credentials. Eventually if the network gets to a certain scale, there will be SaaS companies like Supabase or Vercel offering 'ATproto relay as a service' so devs don't have to depend on them to build their apps.
Fair response, but I think you're not realizing how big this "relay" stuff can get. It's purpose is to download, store and serve ALL of the posts from a network that aims to be global, so we are talking about a lot of data (and a lot of connections to PDSes everywhere, one PDS for each human), so I think the only thing you can claim is that there will be 2 or 3 other companies running alternative "relays", like Cloudflare, Google and Amazon. Even then it's hard to believe this will happen or that it would have a big impact because it would be mostly inconsequential -- 99% of the people will just use the default Bluesky (the company) relay, and if the Hunter Biden laptop is censored by the Bluesky relay, then the Cloudflare and the Google relay are also likely to censor it, right? Even if they don't, who is going to manually switch? Or if some big influencer is banned from Bluesky then actually starts running their own "relay" for a huge cost, how many of the people who would otherwise be hearing from them would switch? How many people who followed Trump on Twitter joined TruthSocial in order to keep following him?
Yes, there will probably be only a few big world relays, just like there are only a few search engines. The difference is you can verify when relays are censoring which will incentivize them to be as neutral as possible, as long as there is one relay that is a good actor. It's actually very analogous to Bitcoin mining pools. Economics forces only a handful to exist, but as long as there is one transparent and fair option ( Ocean ), then the others can't collude as the switching cost is low due to the open nature of the protocol. It's the same with AppViews. This is all theoretical of course, time will tell.
How is this materially different for nostr relays? Sure, nostr clients connect to a few relays, improving censorship resistance greatly, but generally nostr relays are expected to have a large majority of all notes in the social context.
No, they are not. The entire idea of Nostr as a censorship-resistant thing was always that clients would connect directly to the original source of events as decided by the publisher, so if I follow you and you decide to publish only to relay.bitcoin.ninja then my client should connect to that server directly and fetch your notes.
Yea but in practice (a) clients mostly don’t, and for very good reason - probably you don’t want to leak your IP to everyone you follow and (b) the number of people with their own relay is very small, instead most users rely on some relay existing that will host everyone’s crap for free.
I guess if you ignore relative usage most clients in fact _do_ implement it (Coracle, Snort, Gossip, Highlighter, Habla, Yakihonne, Yana, Voyage). The ones that don't are in process of implementing it (Damus, Amethyst, Nostur, Nostrudel). I'm pretty sure the reason why they didn't implement it in the first place wasn't because of any of these reasons, it was because of a misunderstanding of how Nostr was supposed to work, and also because they followed the example of my first client, which was badly designed and I left that relay part to sort out later because it wasn't clear to me how I was going to do it. Then later some people may have come up with reasons like IP leakage and whatnot to justify their poor initial choices (again, I take the blame for it). In any case if we are talking about a Nostr in which clients _do not_ do the outbox model and just connect to a fixed set of big relays then I'll probably agree with you that Bluesky is better than Nostr.
On IP Leakage. Fiatjaf’s actions speak for themselves. He quietely included analytics that share IP addresses with third parties, without consent, then promoted it prominently on the front page of the protocol area. You can verify this yourself at https://nijump.me (warning: it includes spyware not found in the source). It’s concerning that other developers either ignored this or made light of it, instead of addressing the clear violation of trust. This behavior undermines claims of caring about IP Leakage. https://image.nostr.build/9fe474ffeb8f500c444f453f3aaf26c04e3c9794105d1014e1d1c3a8d4298c52.jpg
So, @fiatjaf, the founder of Nostr, now uses a client which randomly adds meaningless "e" tags of type "mention" when he replies to a thread, pointing to some previous item on the thread. The standard thing for a client to do when displaying such posts would be that of showing the referenced note as a quoted note. I don't think this is the intention. Why do client include tags that make no sense? See this posts for instance: nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqsyrugq33u5gmnzlm74k3ke974txvg2xkgfdsdz8gufxfkh4x37xvcg8764u nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqs25gcgd4c8356tlhl2wgrefhh6s0hnzedmhcsjgz6xhp4h2mvc2ng0urenl nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqsg3szzyxr2ckav425thg2ygelf0xhspwrcx5chwrc6yjw2wgkjfqcuu4ck2 nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqsqsk3wnha6cl0x2p6x70p09pyze483509el9rup6ytjaj26kydjvqv9zfrf
nostr:nprofile1qyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhkxmpwwp6hyurvv4ex2mrp0yhxxmmd9uq3kamnwvaz7tmxv4jkguewdehhxarj9e3xzmny9acxjcmnqqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgs4ep8kn someone is complaining about your client here.
in bluesky they use a "root" and "reply" pair for structuring thread trees, i think in nostr there is exactly this as the third parameter of `e` tags this thing about mentions is stupid, who proposed that in the first place? at best, IMO the reply's parent (to which the "reply" marked `e` tag points should implicitly be notified and there should be no explicit need for the use of mention tags that are implicitly generated like this
It's there to allow notes to get all descendants, even if they're not roots. I'm not sure if anyone uses it though.
the use of mentions? coracle does it too it's stupid, it should be a third type, so you have root, the OP, and then you have reply, the direct parent, and then maybe you can have ancestors or something, and they should be `e` tags and yeah then you can find all of them but mentioning doesn't do nothin
It's there to allow notes to get all descendants, even if they're not roots. I'm not sure if anyone uses it though.
the use of mentions? coracle does it too it's stupid, it should be a third type, so you have root, the OP, and then you have reply, the direct parent, and then maybe you can have ancestors or something, and they should be `e` tags and yeah then you can find all of them but mentioning doesn't do nothin
Hi, thank you for replying. It's actually relatively simple. Yes, the spec does contradict itself about how to quote a note. You are right. Some clients include both the "q" tag and the "e" tag with "mention" mark when quoting a note. I think, for now, that is the right choice. When posting a reply, there was an old standard without marks. The new standard, which should be used, does have marks. Clients should still support the old one when parsing a note. There is no ambiguity when writing a reply: the reply should contain two "e" tags: one with "root" mark pointing to the root and one with "reply" mark pointing to the parent, except when the parent is also the root: in that case only one tag with the "root" mark is included. The correct behavior is to not include other ancestors at all. To sum up, my suggestion is: - Assume some clients will use the mark semantic and some the positional semantic. Your client should parse both. - When writing a note, always use the mark semantic and assume other clients will parse it. The positional semantic is deprecated. - Only include parent and root as "e" tags in a reply, with corresponding marks. - Include, for now, both "q" tag and "e" tag with "mention" mark when another note is being quoted/mentioned. Never use either of these in any other case, especially not for an ancestor.
