A few months ago, I posted here about my excitement for Plebbit and the promise it held for decentralization. I was convinced that a p2p social platform with a unique UI could be the future, with different UI of all social media…including Lemmy, a true alternative to centralized services. I saw the potential, and I wanted to believe in it.
Plebbit promised a lot of an innovative interface, decentralization, community driven governance. But after months of delays, vague updates, and little to no progress, it’s clear they never delivered. They had the right ideas but lacked the follow through to make them a reality. What was once an exciting project quickly turned into an example of what can go wrong when the hype overshadows the substance.
I wanted Plebbit to succeed, but in the end, I’ve realized that I’m better off sticking with what actually works.
If Plebbit had actually followed through on its promises especially with its vision of being a decentralized Reddit alternative. it could have been the best. The idea of a selfhosted platform, where users had true control over their content and communities, was a dream for those of us who wanted more than just another centralized app. It had the potential to be the go-to solution for anyone seeking real decentralization and p2p freedom. But unfortunately, that potential was never realized. Instead of delivering on its ambitious promises, Plebbit became just another project that failed to meet expectations, and the opportunity for a truly revolutionary platform faded away.
I don’t take issue with your points, but you’re conflating issues. I think it’s worth clarifying some terms up front.
Being utterly independent isn’t necessary for decentralization. Decentralization very specifically means there’s no single holder of the data; it does not have any implication for dependencies.
Lemmy is not decentralized; it’s federated. “Decentralized” and “federated” are not synonyms, and as long as you doing don’t run your own server, you’re effectively on a centralized platform. This is to your point about being “always dependent on something, somewhere in some way.” It’s true for Lemmy; it is not true for all systems, not unless you’re being pedantic, which wouldn’t be helpful: you being dependent on electricity from your electric company doesn’t mean an information network can’t be “truly” decentralized.
A distributed ledger can be truly decentralized. Blockchains aren’t always distributed ledgers, and not all distributed ledgers are blockchains, but whether or not a specific blockchain is resource intensive has no bearing on whether or not it’s centralized. This is the part I take issue with: it’s irrelevant to the decentralization discussion.
Bitcoin is decentralized: no single person or group of people control it, and there is no central server that serves as an authoritative source of information. If there were, it wouldn’t be nearly so ecologically expensive. Its very nature as something that exists on equally on every single full node is part of the cost. You can take out any node, or group of nodes, and as long as there’s one full node left in the world, bitcoin exists (you then have a consensus verification problem, but that’s a different issue).
But let’s look at a second, less controversial, example: git, or rather, git repositories. This is, again, fully decentralized, and depends on no single resource. Microsoft would like you to believe that github is the center of git, and indeed github is the main reason git is as popular as it is despite its many shortcomings, but many people don’t use github for their projects, and any full clone of any repository is a independent and fully decentralized copy, isolated and uncontrolled by anyone but the person on whose computer it exists. Everything else is just convention.
Nostr is yet another fully decentralized ecosystem. It is, unfortunately, colonized almost entirely by cryptobros, and that’s the majority of its content, but there’s nothing “blockchain” or crypto in the core design. Nodes are simple key/value stores, and when you publish something to Nostr you submit it to (usually) a half-dozen different nodes, and it propagates out from there to other nodes. If you run your own node, even if your node dies, you still have your account and can publish content to other nodes, because your identity - your private key - is stored on your computer. Or, if you’re smart, on your phone, and maybe your laptop too, with backups. Your identity need not even be centralized to one device. No single group can stop you from publishing - individual nodes can choose to reject your posts, and there are public block lists, but not every node uses those. It is truly decentralized.
I’m not familiar with Plebbit, but it seems to me they’re trying to establish a cryptographically verifiable distributed ledger - a distributed blockchain. There’s no proof-of-work in this, because the blocks are content, so the energy cost people associate with bitcoin is missing.
DHTs and distributed ledgers are notoriously difficult to design well, often suffering from syncing lags and block delivery failures. Jami is a good example of a project plagued by DHT sync issues. I’m not surprised they’re taking a long time to get stable, because this is a hard problem to solve - a deceptively simple problem to describe, but syncing hides issues like conflict resolution, updating published content, and all the administrative tools necessary in a world full of absolute shitheads who just want to cause chaos. It does look to me as it it would be fully decentralized, in a way Lemmy isn’t, if they can get it working reliably.
Plebbit is not a ledger, it’s a P2P protocol and has no DHT. Peers find each other by coordinating over HTTP routers, which are similar to bittorrent trackers. HTTP routers are essentially key-value stores so they’re very easy to deploy.
This is similar to Jami. Jami has http name servers for lookup, and (optional) http DHT proxy servers for NAT traversal. Beyond that, it’s peer-to-peer DHT. The DHT isn’t global, it’s shared between connected clients. DHT are also key-value stores, and Jami’s issues are not with the name server, they’re with message synchronization between clients.
Actually, I have to qualify that I don’t know what causes Jami’s delivery issues, but it’s probably not the name servers or proxies, because you can (and I have) hit them directly with a web browser or curl. From what I can tell, the Jami developers don’t acknowledge issues or are incapable of or unwilling to track them down, but the point is that it’s very likely the P2P part that is giving them trouble.
P2P is Ia hard problem to solve when the peers come and go online; peers may not be online at the same times and there’s no central mailbox to query for missed Messages; peers are mobile devices that change IPs frequently; or peers are behind a NAT.
You may be right about the design; I scanned the design summary, and easily could have misunderstood it. I don’t think it affects the difficulty of building robust, reliable P2P applications.
A global DHT unfortuantely is extremely resource intensive, and part of our design requirements is full p2p capabilities for both mobile and web browsers. This cannot be achieve with a DHT, although if a DHT design emerges with support for both, we will consider using it.
Next update for plebbit-js will have full p2p capabilities including gossipsub using libp2p/helia in browser/mobile! We’re excited to ship that.