How might peer-to-peer technology be incorporated into, or augment, existing fediverse tech?
This is a followup to my previous post, and a particular point that was raised briefly but most commenters didn't focus on.
I enjoy starting discussions like this and I'm glad the last one was received well. To be clear, I'm not dogmatic about a particular way to do things, my goal with these posts is to trigger interesting thoughts. I am not a programmer and do not "actually" contribute anything, beggars cannot be choosers, so you don't need to take my opinion too seriously.
That said, let's talk about what peer-to-peer social media might look like.
Why do this?
1. Scaling. This is actually the biggest and most immediate benefit, and would probably be substantially helpful even with only small opt-in P2P features. How is a decentralized network of thousands of small server operators going to scale up, if a mass migration occurs? If the migration started tomorrow, the opportunity might be largely lost. Let's say users could optionally seed a post or comment for a period of time after viewing it, that would help immensely when the next big rush of new users comes, wouldn't it?
Peertube already has some P2P tech in its video hosting for this same purpose, to help with scaling and meeting demand. But in their model everything is still coming from the servers. Imagine if the peertube viewers were actually seeding as they were viewing.
2. Internalizes externalities: ie it solves the social media freeriding problem by turning lurkers into productive providers. This is big because the vast majority of users are always going to be lurkers.
If you could figure out a very strict way to absolutely prevent content from being viewed unless the downloading computer agrees to seed, it would also make scraping bots actually useful or disincentivize them - both good outcomes. I am not knowledgeable enough to know if this is realistic or just a pipe-dream, though.
3. Reduces required trust: Yes, a fully-P2P network would probably not be privacy conscious (unless you do something like Quiet where things are routed through Tor or a similar network of relays). You'd need to be willing to seed. But on the other hand, you wouldn't need to trust the operator a random small server like many people currently do in the fediverse.
4. Makes it harder for a big institution to muscle into the fediverse to steal users and eventually close off their own bubbles, nor for a successful server to turn evil and "betray" the network; there will be no worry about a server becoming "too big" and too powerful, if there are no substantial servers in the first place.
Two specific questions for discussion:
1. How feasible would it be to implement P2P forum architecture either as a standalone social network, or 2. as an opt-in feature of existing fediverse server softwares like Lemmy, Piefed, Peertube, Pixelfed?
My own answers: 1) Quiet proves that it can be done at least for Slack-style networks. With Tor integration, their approach also seems more complicated than strictly necessary if your goal is just decentralization.
Who tracks credentials? The answer is likely a public key / private key username/password system, like blockchain. Quiet also uses a system like this.
Who hosts? When you post or comment, you seed your own. It stays accessible as long as you keep seeding, and vanishes when you stop, unless others have picked it up. What could be more fair than that?
- Existing services can already integrate P2P features:
Seeding as a big upvote: Come on, wouldn't this feel amazing? What better or more natural way to spread and reward good content?
Indiscriminate seeding: Users could sign up to actually take server load on an as-needed basis. If they are signed up, and if they are logged in at the same time the server gets a lot of demand, then it offloads some stuff to them of the server's choosing. There could be instance rewards linked to this.
User-specified seeding time: When you volunteer to seed, you choose how long you want to keep seeding. By default, it stops immediately when you log out.