Replying to 21823843...

nostr has no global source of truth, and that is a good thing

Out of interest, I follow the progress of a lot of other projects similar to nostr, and a couple links surfaced today:

BlueSky has a big "firehose" connection that streams all updates (new posts, reactions, etc) to subscribers. Unsurprisingly, this is difficult to process except on beefy servers with lots of bandwidth. So, one proposed solution is to strip out all that pesky cryptography (signatures, merkle tree data, etc): https://jazco.dev/2024/09/24/jetstream/

And over on Farcaster, keeping their hubs in sync is too difficult, so they want to make all posts globally sequenced, like a blockchain. The details are still being worked out, but I think it's safe to assume there will be a privileged global sequencer who decides on this ordering (and possibly which posts are included at all): https://github.com/farcasterxyz/protocol/discussions/193

In my opinion, both of these issues are symptoms of an underlying errant philosophy. These projects both want there to be a global source of truth: A single place you can go to guarantee you're seeing all the posts on a thread, from a particular user, etc. On BlueSky that is https://bluesky.app and on Farcaster that is https://warpcast.com .

Advocates of each of these projects of course would dispute this, pointing out that you could always self-host, or somehow avoid depending on their semi-official infrastructure, but the truth is that if you're not on bluesky.app or warpcast.com, you don't exist, and nobody cares that you don't exist.

nostr has eschewed the concept of global source of truth. You can't necessarily be sure you are seeing everything. Conversations may sometimes get fragmented, posts may disappear, and there may be the occasional bout of confusion and chaos. There is no official or semi-official nostr website, app, or relay, and this is a good thing. It means we are actually building a decentralised protocol, not just acting out decentralisation theatre, or pretending we'll get there eventually and that the ends justify the means.

Back when computers were primitive and professional data-centres didn't exist, it was impossible to build mega-apps like Twitter. Protocols had to be decentralised by default -- there was simply no other way. We can learn a lot by looking back to protocols of yesteryear, like Usenet and IRC, and still-popular protocols like email and HTTP. None of these assume global sources of truth, and they are stronger and better for it, as is nostr.

i can confirm about BS and FC, both are retarded... FC is actually less retarded than BC because they at least don't embed binary data nor use binary as their primary message format, but creating a global total ordering just turns it into another silo and it's pretty sad they don't get that

i'm working with Arweave on a project that involves both of these other protocols but recently i hear from them that they want to make arweave storage a fully persistent event storage for nostr and actually integrate properly with relays

different mindset, they are more interested in the fact that nostr is a delivery system instead of being stuck in the global consensus mindset... i also had problems with the Internet Computer Protocol people because their nodes have one replication setting which makes the cost of data storage absurdly high, and were "talking about" making lower reliability replication schemes for cheaper, larger storage... but who knows where that's gonna go

crypto project guys are completely mentally locked into the strongly consistent mindset and don't understand the most basic principle of distributed systems that you can only have 2 out of the three of CAP strong at the same time, and nostr has high availability and partition resistance (it's leaky, is how i describe that, it's not possible to stop replication across the network, partitioning is where you split the data) what nostr doesn't have is strong consistency, and that's the issue, they can have consistency, but the cost is either availability or partition resistance, and they are too dumb to realise that if they focus on consistency one of those two has to go

Reply to this note

Please Login to reply.

Discussion

i think part of the reason why arweave people understand it better is they already have a separation in their architecture between replicas and the consensus and the delivery API service, so it is simpler for them to think of their database as storage, indeed that's one of the whole points of their project is pretty much focused on storage so they have more realistic strategy about how to keep the cost contained and scaling replication to fit the use case instead of having a one-consensus-to-rule-them-all mentality

also, the replication strategy of farcaster is patently retarded it's just IPFS

and they are not gonna have a good time trying to make a total ordering, this is precisely what you can't make work at scale!