This is a general idea or concept I've had kicking around in my head about a way that a federated social network could work, wherein the user's own local device controls their identity rather than having a username on somebody's server.
To understand what I'm talking about, first let's run through what a federated social website even is. Briefly:
How would it look? With typical websites, there's a database and everyone has a user ID in it along with their email, username, bio text and whatever other details, and each website has their own database. What if you could move that user authentication to the client side? So instead of, "I log in as @kirsle with my password, so your back-end database can attest to my identity" it's instead "I'm telling you who I am, using a profile stored on my phone and not on your database."
The technologies to make this work on the client-side apps would be:
Now, what kind of site would this support? Not a site like Twitter or Instagram where users have a timeline and you host decades worth of pictures for them; these sort of sites require too much back-end state around user accounts.
Think instead of a site more like Reddit. Reddit is a "forum of forums" with tons of sub-communities but it's all on a centralized site. Imagine instead, that instead of subreddits on one site, each subreddit was its own separate server altogether, each server operated by different individuals on the Internet?
The server only hosts the forums and comment threads, not the user profiles. The user profiles are kept with the client app. If a server disappears, only its discussions are lost, not the users too.
So with my "self-authenticated client app" I could connect to a dozen different servers, each hosting their own communities, using my own local device identity to seamlessly authenticate to each server and post messages to their boards. The long-term state of each server, then, is only to do with the forum messages and less to do with maintaining profile pages and timelines. If a particular server decides to shut down and close up shop, nothing is lost, no user accounts were centrally tied to that server, users will just find replacements for their particular community discussions.
This idea is free for grabs, I don't think there's any money to be made from it, and I wouldn't mind if somebody made it a reality, I'll probably be too lazy to develop it myself. :)
There are 3 comments on this page. Add yours.
The idea of your device owning your profile data seems similar in concept to Tim Berners-Lee's SOLID project (albeit your suggestion is smaller in scope and probably a lot easier to realistically implement for a single system rather than trying to invent a general solution for data).
It seems like the challenging part would be preventing impersonation and identify spoofing by bad actors. Most sites that have a central account system seem to struggle with that, and the Fediverse has also had some challenges with impersonation across different servers.
Hey Darryl, good to see you again!
Yeah with my idea it would be easy to impersonate someone, but you wouldn't have their same public key signature, and an individual server would have a longer history of posts/comments left by the real user which would make the impersonator more obvious. A system of "avatar image generated from public key" could make it even more obvious if somebody is impersonating, similar to what (iirc) Keybase has and GitHub's default user avatars... generates a unique pictogram based on the key which would look wildly different if you generated a different key. Users familiar with the OG user account would immediately notice the pictogram is different for the impersonator.
It's not a lot different to PGP keys and key servers. Anybody can impersonate Linus Torvalds, but without their PGP key being cross-signed by as many people as the real Linus nobody would fall for it.
Another follow-up I thought of for this post later on, would be how to rate limit spammy account sign-ups; classic sites can require a validated e-mail address or some means to slow down creation of accounts. It could be that such a server just puts a deliberate wait time of 10 seconds the first time it sees a new user, or use a traditional CAPTCHA to slow and impair spam bots from just cranking out a billion user accounts to spam a site.