Plebbit is a selfhosted, opensource, nonprofit social media protocol, this project was created due to wanting to give control of communication and data back to the people.
Plebbit only hosts text. Images from google and other sites can be linked/embedded in posts. This fixes the issue of hosting any nefarious content.
it has no central server, database, HTTP endpoint or DNS - it is pure peer to peer. Unlike federated instances, which are regular websites that can get deplatformed at any time,
ENS domain are used to name communities.
Plebbit currently offers different UIs. Old reddit and new reddit, 4chan, and have a Blog. Plebbit intend to have an app, internet archive, wiki and twitter and Lemmy. Choice is important. The backend/communities are shared across clients.
The code is fully open source on
Hold up plebs (hah), this alternative to dns (domain name system) called ens is actually more centralized.
The pros listed here over federation: no central http endpoint, database or dns are a lie. The whole point of having federated instances is that they're not a central thing. Yes, individual instances can be knocked out. It'll be just the same for plebbit except no one can moderate trolls creating scummy or phishing domain names.
Whomever came up with the idea to charge people gas fees is a billionaire now. Ignoring that bit, this blockchain based domain system looks cool, but an unmoderatable free-for-all is an absolutely terrible idea
I read through the whitepaper, and it has moderators similar to Reddit/Lemmy. Basically, whoever creates the community (subplebbit) is the owner/admin (they like to say "adminless," but each community has an admin), and they can select moderators, who can do moderation tasks like deleting posts.
So it should have the same benefits and problems as Reddit since it'll all come down to the moderation team the admin selects.
If you think of it like Lemmy, but instead of instance admins you have community admins, you'll be more right than wrong.
On an unrelated topic, I'm working on my own P2P Reddit clone that doesn't have centralized moderation, but instead relies on a Web of Trust system to handle moderation, but instead of binary trust, it's fractional (i.e. you can trust someone 10%, someone else 20%, and posts will be filtered accordingly). In fact, trust isn't manually handled, it's handled based on how similarly you act vs others (i.e. you both upvote/downvote similarly, flag posts similarly, etc), and I'm deciding whether making this based on community makes sense (i.e. you trust user A on community X, but not on community Y).
Just because moderation doesn't look similar to what you're familiar with doesn't mean it's ineffective. We'll see if Plebbit works out, but I'm still going to try my own approach and see if that works. Oh, and my approach doesn't have a blockchain, crypto currency, or really any way to monetize it FWIW.
Wouldn't this just create an impenetrable filter bubble/echo chamber where you see nothing else than content you 100% agree with?
For many users, probably. I do have plans to have a "moderation queue" or something where you can opt in to seeing stuff that was hidden and adjust your moderation preferences.
On Reddit, the recommendation was to upvote constructive comments even if you didn't agree, and downvote unconstructive comments even if you do. People didn't do that, so we got echo chambers.
On mine, I plan to have four responses to a comment:
Users could adjust the weights of each, but by default "relevant" and "flag" would be much more highly weighed than "agree" and "disagree." You can also block users. All of those are taken into account by the moderation graph to decide which content to show and in what order.
You misread, the unmoderatable free-for-all is about the domain name system alternative. Not the hosted platforms they point to
Good to see they've got some moderation tools for the platform regardless tho!
What do you need moderation for that for? All a domain name service needs is some kind of reputable link between two things (e.g. domain name and IP), and Plebbit seems to be using it to reserve community names (so name -> public key, or maybe the other way, I haven't looked into it). The reputation comes from the blockchain, which dramatically increases the barrier for an attacker to change an entry. Instead of a central authority, you have a group of individuals (ETH is based on proof-of-stake now, and I assume ENS is as well) who verify claims before it becomes part of the blockchain.
To me, it's the least problematic part of it, I'm more concerned about communities having owners, and thus communities can die if the owner decides to stop hosting it or decides to dramatically change the rules (or moderators, etc). One of the major points of decentralization is to remove the power of individuals to change/break things, and Plebbit doesn't do that. The most problematic part, IMO, is ties to cryptocurrency, which seems to be its profit motive, so the moment it takes off, the creator gets rich (because they hold a ton of PLEB token), and that doesn't bode well for the long-term viability of the project.
That said, we'll see how it works out. I think it has some interesting ideas, and I'm all for alternatives to the established players in the social media space.
Have you been living under a rock? Just allow me to register plebbbit.eth and make it simple steal user accounts then redirect to the actual website. This, and plenty of other tricks need to dealt with
You could do the same with DNS, nothing is stopping you from registering a similar domain name and doing the exact same thing. ENS doesn't change anything with the attack, it merely exchanges registrars for a block chain.
Except dns requires proper registration, and has a place to report abuse, and those reports are actually acted upon. Moderation here is not preventative, it's reactive.
Stop trying to justify this approach, a blockchain is cool but you're really just monopolizing domain registration
Oh, I think the approach is problematic, I just don't think ENS is a major concern here. I don't think you need DNS/ENS for this kind of service, nor do you need any form of blockchain.
My point is a blockchain DNS system isn't significantly worse than the current system, where we already see a ton of similar abuse. The proper solution, IMO, is to avoid the need for DNS at all.
Accurate, what would you do instead of dns though?
Nothing?
DNS exists to give an authoritative answer for who owns something. I would have a completely different design where nobody owns communities.
Basically, I'd treat communities as topics that live on a DHT as keys, posts would be keys semantically related to the community (e.g. "communities..posts."), and so on. Anyone can post to that topic or to any posts or comments related to that topic by creating subkeys, all of which use UUIDs to guarantee uniqueness. All entries in the hash table are signed by the author's key, and people can create identical entries (i.e. the same key), which can be distinguished by the signature. The signature is important, because we can't trust timestamps to distinguish between collisions (e.g. someone mimicking someone else's post id vs someone editing their own post).
Moderation consists of a web of trust system, where users are given weights based on how much you trust them. When deciding whether to display a post, you'll check the moderation of that post by people you trust, and show/hide it accordingly. The same goes for votes, you could disregard votes from users you consider spammers/trolls. Building that moderation graph is largely automatic, if you vote or moderate similarly to someone else, you start to trust them more, and their weight in your graph increases.
In other words, nobody owns communities, so there's no reason to have DNS, and the main reason to have DNS is for moderation, which becomes moot when moderation is itself distributed.
A domain name system is for naming domains, not moderation. And just use a database instead of reinventing the wheel.
That alternative "show if trusted" approach would be nice in an ideal world where everyone already has a perfect filter bubble with only their perfect friends. But unfortunately the world isn't like that.
You gotta learn to walk before you can run
Right, plebbit seems to use ENS to connect a name to a place. If the name doesn't point to a place but instead a distributed collection of posts, you don't need a domain name system.
A DHT is a distributed key value database. I'm modeling everything in terms of structured keys using existing data structures.
Moderation is the hardest nut here to crack, and that's pretty much the entire point of this experiment: can I build a distributed trust system? I've read a few papers on approaches that could work, and this transitive trust system should do okay. The idea is that I trust user A by X%, A trusts B by Y%, so I should trust B by something less than both X% and Y%. To get a decent result, I need enough data to make it work well, but not so much that computation is slow.
I think it's feasible. If it works, we don't need centralized moderation, which solves a ton of problems in current social media networks.
Note: we don't have centralized moderation here either. We're talking in two completely different instances. Just like plebbit would have
It's still centralized in the sense that there are specific individuals who have moderation power. If you think of each instance as a separate thing altogether, it's the same as Reddit.
I'm on reddthat.com and you're on sh.itjust.works. These individual instances have their own moderation setups. There's no central or overarching system here. We're on two seperate websites. That's the idea, a bit oversimplified.
But yes, you could go local only, but wouldn't that kind of defeat the point? I want to be able to switch instances, and talk to friends on other ones. That decentralization brings the huge benefit of not having a u/spez situation
Sure, but something being federated doesn't make it decentralized, it just makes centralized systems cooperate through established protocols.
This community is on lemmy.world, which neither of us are part of. If the admin of lemmy.world doesn't like a comment or post, they can delete it. So even though we're not affiliated with lemmy.world directly, we're still subject to their rules, because lemmy.world is a centralized service that just happens to share some data with other centralized services. If lemmy.world goes away, so does this community; we'll still see our respective copies of the data on our instances, but we can no longer see each others' posts and comments.
The main benefit federation provides is mitigating damage to the service as a whole if a node goes down. It doesn't protect individual communities at all.
Plebbit is the same as federation, it just cuts the centralization to the community level and distributes load across the network. But it the community owner disables the community, it's dead.
I prefer that nobody can kill a community. I don't want to trade one tyrant for a handful of tyrants or even a lot of tyrants, I prefer no tyrants.
You can always zoom in and say "see, this little bit is centralized on it's own"
Not necessarily.
Is Bittorrent centralized in any way? Once something is seeded by peers, there's no single authoritative source, and it's trivial to host new relays (in BitTorrent parlance, either a PEX or Tracker) if some get shut down. You'd have to take a ton down to really impact the Bittorrent network, whereas with Lemmy, you just need to take down one or two instances to cause a mass exodus. With Plebbit, that number is probably a bit higher, but a dozen or so of the most popular communities is probably enough to impact nearly everyone. Likewise, infiltrating (i.e. court gag orders) would be incredibly effective on Lemmy and perhaps Plebbit, but fairly useless on BitTorrent without added technical measures (e.g. seeding something with an exploit).
The gold standard IMO for free speech is complete decentralization with local moderation.
There's a lot of lemmy instances, which two would you shoot at?
BitTorrent still relies on trackers, but much like a lemmy instance you can move over and share things elsewhere
Lemmy.world and lemmy.ml or sh.itjust.works. Those are the largest and host the most popular communities.
If an instance goes down, all the communities hosted there become dead. If a BitTorrent tracker goes down, you pick another and nothing changes, because the tracker doesn't own the data. This is especially true for peer exchanges.
A properly decentralized service is largely unaffected by any one node going down.
I suppose you're right, It's still a lot better than a reddit like situation though. I'll have to keep that in mind
Sure, and that's why I'm here and not on Reddit, and I may switch to Plebbit if that gets traction since I think its design is better. But it's also why I'm not hosting my own instance or actively contributing to either project. I did contribute some bug fixes to Lemmy in the past, and will probably do the same for Plebbit at some point, but my focus will be on my own project.
I'm just glad the market is diversifying
Same. At least in the medium term. Longer term, I'd like one to make it mainstream.
Doesn't bkuesky support federation?
Yeah, but it's not very similar to Activity Pub from what can tell. Details.
Hmm, it is a bit halfway there. Glad to see user data being separated though
No, it does not "seem", it explicitly states.
A hash table is a way of storing data, I suppose you could call it a very primitive database. But that's not the common usage of the word database. Hash tables are used in database indexes, hence why I called it "reinventing the wheel".
The naming system is still a central part of any network, even if decentralized in design. So it will need some sort or central moderation.
One issue with ens though, is that the control over it is more centralized than dns. But without regulation, it's worse than the existing solution.
I haven't used the service or reviewed the code, I've only read the whitepaper and read the website. Early stage projects like this have a habit of stating this things that aren't yet true, hence the uncertainty.
It sounds like you're limiting your definition of "database" to relationship databases, there are a lot of other types of databases out there. The most common use case for Redis, for example, is as a key value store, and a hash table would be a perfect way to implement that. I've used
redbin this project, which is a disk based key value database.Sure, but DNS systems are authoritative, meaning there's only one right answer to a given query. This requires synchronization across the network, which creates a ton of complexity.
If we can avoid that synchronization, the design gets a lot simpler, which makes it more robust. In my design, I'm specifically avoiding mandatory deletes and updates, so the only operations my "database" needs to support are creates and reads. Communities are just topics you can post to, and moderation is just client-side filtering. The tricky part is getting the client side filtering good enough to not give spammers and trolls too much visibility.
Some nice parts about this:
Let's hope it's not true yet or ever. Did you mean relational? And no, that's not what I said.
The current dns system works, and has it's flaws. But ens is not an improvement, it's worse.
Yes, relational. Stupid auto correct...
And I'm not arguing for or against DNS vs ENS, I'm saying that whole concept is an unnecessary centralization for something that could be implemented without it at all. The only technical reason something like Reddit would need an authoritative answer for name resolution is for moderation (i.e. elevated privileges), so you can verify that you're getting authoritative moderation.
If you can do distributed moderation, you get a lot of nice flexibility and resiliency. That's what I'm interested in exploring, and my main criticism of Plebbit. If I take Plebbit to a region that blocks ENS or sending packets to the owner, I can't use the service, which to me means it's not truly decentralized. If I take my system there, I can keep using it with locals there provided I find a relay behind that firewall, and I can sync up with my usual peers later. The only hosting needed for my service is a relay to connect nodes, and someone needs to provide storage space on their client. That's it, and relays are cheap.
Without names you wouldn't have.. names though? We're still dealing with humans in the end, we like names
There would be names, just no owners of those names. You'd navigate to /c/technology or whatever, there just wouldn't be anyone who owns or controls that name, it's just a tag that anyone can post to.
To get the posts for /c/technology, you'd ask your peers, and they'd ask their peers until someone provides that data. Your client would then aggregate all of the responses, filter them through local moderation, and then display the feed.
Then how would you get to the platform? Direct ip?
Connect to a relay (ideally multiple), which connects you directly to peers. From there, peers can directly refer you to other peers. So just like a BitTorrent tracker or peer exchange.
There currently isn't a web frontend, but once there is, you could select any that you like. You could self host your own portal, use someone else's, or use the one I provide. That portal doesn't store any data, it just serves the page and facilitates connection to the platform, and any caching would be an implementation detail. It'll be incredibly lightweight, so you could host it on the cheapest VPS available.
Isn't that effectively the same? I like the lightweight aspect of it though
No. From what I can tell, Plebbit works like this:
If User A ends the service, moderation and signing of comments end, which effectively kills the community.
My proposal works like this:
That's it. Any moderation happens on the client. I have plans to make moderation largely automatic, so it's not a pain while still hopefully controlling spam and trolls. Half the network could go down and the data would still largely be intact. In fact, a country could block internet entirely, and you could still sneakernet it in as long as someone has a relay there. If somehow all relays go down, you spin one up and everyone resyncs and we call it an outage. You can even host your own within your LAN.
Domain names are convenient for relays, but they're not essential. The only thing required is some way to connect peers.
Oh, that might just create some legal issues
For who?
The biggest targets are individual users, but as we've seen with BitTorrent, that almost never happens. There's also no profit here, so there are no assets to seize, though I'll probably accept donations.
I don't mean crime, no. There's laws regarding moderation when a platform is big enough. And regarding personal data in a lot of cases
Ah, that's not a thing where I'm from (US). I wonder what that would look like without a central authority. There's no way to guarantee any particular moderation or ensure deletion of personal data, so I guess their options are to ban it or let it slide.
Probably only the instances big enough to qualify