New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decentralised user accounts #915

Open
ara4n opened this Issue May 9, 2017 · 8 comments

Comments

Projects
None yet
8 participants
@ara4n
Copy link
Member

ara4n commented May 9, 2017

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:

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented May 9, 2017

Another idea was to use a .forward system: #496

@richvdh

This comment has been minimized.

Copy link
Member

richvdh commented May 9, 2017

#883 is somewhat related

As is matrix-org/synapse#1209

@leonerd

This comment has been minimized.

Copy link
Contributor

leonerd commented May 11, 2017

Split users into alias & opaque ID, like rooms: #494

A potential vote in favour of this might be that it might make guest access easier, because it can be used to implement the Guest -> "Real User" flow somehow nicer?

@richvdh richvdh added the feature label Jul 5, 2017

@EternityForest

This comment has been minimized.

Copy link

EternityForest commented Jul 11, 2017

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 foo@example.com"

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.

@alexgleason

This comment has been minimized.

Copy link

alexgleason commented Oct 2, 2017

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.

@EternityForest

This comment has been minimized.

Copy link

EternityForest commented Oct 2, 2017

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.

@emiljoha

This comment has been minimized.

Copy link

emiljoha commented Oct 9, 2017

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.

@Thatoo

This comment has been minimized.

Copy link

Thatoo commented Sep 16, 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment