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:
- Facebook, Twitter, Instagram and so on are all centralized social networks.
You register a username on Twitter.com, their database holds your profile and
user information, and you can follow and talk to other Twitter users that are
on the same website. But from your Twitter page you can not comment on an
Instagram post; you need to go make an account on Instagram to use their
centralized social network instead.
- So then you have the Fediverse and
for a specific example, Mastodon is a federated
Twitter-like web app. It's open source, there's hundreds of servers, each run
by various individuals or small companies, and you can install the Mastodon
server on your own machine if you like. No matter which Mastodon server you
sign up a username on, you can like, follow and comment on anybody's posts on
any Mastodon server you like. I could be "@kirsle" on the "mastodon.online"
server and you can be "@soandso" on the "toot.online" server and we can follow
each other all the same. It's decentralized, but each server does still have
their own user account base.
- But what if my chosen Mastodon instance decides to shut down? My profile goes
down with it. Sure, I can sign up on another instance but I lose all my
history and gotta start over from scratch!
- What if there was a way to own my own profile on my local device, but still
be able to interact with users on a decentralized fediverse of different servers?
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:
- Public/private key cryptography. Each user device would roll its own encryption
keys, keep the private key to itself, and the fingerprint of the public key
becomes your "globally unique user identity token" -- in exactly the same way
that Bitcoin wallets work, or how Tor .onion hidden-service domains work, and
so on. You can't spoof my public key fingerprint unless you have the exact
private key that goes with it.
- My local device holds a JSON blob of my profile data: my nickname, my avatar
picture, my bio text for my profile page, and any other personal account info.
- When my device connects to your server: I send my public key fingerprint, + my
blob of personal account information, + a cryptographic signature of my account
blob signed by my private key which matches my public key fingerprint.
- When your server sees me the very first time, it could create a row in its
database using my public key signature as "user ID" or w/e as needed for
the server's operation, e.g., so if I create a post, the "user ID author" of
the post is my public key. Or it might cache my account info to be shown in
comment threads to others (for my avatar URL and display name, etc.)
- When I come back to your site later, your site still remembers me and I still
'own' the posts I made (can edit or delete them if I want, etc.); nobody else
can spoof as me unless they have my private key.
- If I spam your server you can ban my public key signature, and I'd need to
roll a new account. The landscape of spam problems on the Internet is not
any different to the current status quo (ppl can just sign up new usernames...)
- For the technically inclined: think JSON Web Tokens except
each individual client app is attesting to their own identity: the client
tells the server who it is, without passwords or anything, and the server just
takes their properly formed message as-is and uses their public key fingerprint
as user identifier for any back-end purposes.
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. :)
Kirsle.net
