Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Decentralised user accounts #915
We seem not to have a bug for the age-old feature of decentralised user accounts. This would let users migrate or replicate their accounts between different homeservers, such that their homeserver is not a single point of failure for their account. See also https://github.com/matrix-org/GSoC/blob/master/IDEAS.md#decentralised-accounts
Various possible ideas:
What about having normal domain based user accounts forward to public keys? That way we have the option to change and revoke public keys, and we don't have to interact directly with the long hash strings.
That way a public key wouldn't "be" a user's identity, the server would just be telling you "Even if you can't reach me, whoever has this pubkey is the real firstname.lastname@example.org"
The pointer record on the homeserver could also contain the IP and SSL certificate of the server the user is actually at, allowing for seamless roaming. Maybe most of the time you want to be on your self hosted server, but you also want to have a backup in the cloud? Maybe you want a plug and play way to run your own server without worrying about domains, DNS, certificates, etc?
Also, by making "your current location" totally dynamic, we can do things like auto discovering servers on the LAN. If the internet goes out, you can show a popup and let people know that there's still a LAN server available. This kind of seamless online and offline stuff might be very useful for the IoT, emergency preparedness, and off-grid communities.
You could have publically advertised discoverable rooms on wifi at conferences for announcements.
You could also query the local network and say "Hey do any local servers know where the user with the pubkey that hashes to this is?" You'd still have the pubkey cached from last time you checked with the cloud servers that holds their identity until it expires.
Even if you've never contacted a user's public server before, you could still join a local public room where they were and send and receive messages, they would just be marked as "unverified", as in "This user is claiming to be foo:example.com, but we can't reach example.com to confirm, so all we really know is that they have the public key XYZ."
The ability to use cloud-hosted identities offline would be major for preparedness, corporate, IoT, traveling, etc, and it's the kind of feature you don't think about until you really wish you had it, so including it in a mainstream messaging app as a core part of the protocol makes sense.
Plus, it's a pretty uncommon feature, the other protocols that support it are mostly DHT based with huge bandwidth usage. Server roaming would give matrix a major advantage.
Is the suggestion here to sync user accounts among homeservers? I'm guessing the aim is to provide a way for people to smoothly interact with rooms they've already joined but from a different server. So you'd need some cryptographic way of identifying yourself.
A short-term solution could be to let people export/import a csv of each room they belong to. Upon importing, it would request access to each room again. The only challenge I can envision is separating direct chats from other rooms, but Riot already does this.
I think any two users should be able to communicate via any server, even if neither party has used that server before and none of the computers involved can access either homeserver. That way everything works as normal even on isolated networks, you just have to configure a fallback server.
I'm thinking the easiest way to do offline portable ID without going entirely to a "Pubkey as ID" model, is to create a keypair on the client, then have the server sign a message with the public key.
The message could possibly expire at a certain time depending on the user's "Keep me logged in" preferences.
For maximum reliability in a situation with very limited internet, the message could contain the full cert chain up to the homeserver's CA, so that there's no need for the server to know anything about the homeserver beforehand.
From a somewhat incompetent sysadmin point of view. (Which I think Is an view worth considering to make It accessible to run a homeserver.) This sounds very promising as my inability keep a high uptime is a constant problem. Provoking the following reaction to me potentially getting the librem 5 smarphone enthusiastically explaining that it runs matrix for all communications. " So then I will never be able to reach you!" ... :(
I would happily volunteer some of my bandwidth, processor-power, and memmory to in turn get It back when I accidentally unknowingly shut down synapse leaving it down for a couple of hours.
referenced this issue
Oct 18, 2017
referenced this issue
Aug 22, 2018
And that would help people living in countries using censureship (China, Iran) to be able to keep using matrix. No country which allow internet access (all but north korea) could censure all world matrix server. there would always be one reachable (unless switching off from Internet).