Decentralised user accounts

[ara4n]

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:

• Make MXIDs a 3PID(!) https://github.com/vector-im/riot-web/issues/3634
• Split users into alias & opaque ID, like rooms: https://github.com/matrix-org/matrix-doc/issues/494
• Use pub/priv keys for identity: https://github.com/matrix-org/matrix-doc/issues/778
• ...

[richvdh]

Another idea was to use a .forward system: https://github.com/matrix-org/matrix-doc/issues/496

[richvdh]

https://github.com/matrix-org/matrix-doc/issues/883 is somewhat related

As is matrix-org/synapse#1209

[leonerd]

Split users into alias & opaque ID, like rooms: matrix-org/matrix-spec-proposals#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?

[EternityForest]

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 [email protected]"

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]

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]

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]

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]

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).

[uniconstructor]

I described some possible solutions for standardization and unification for decentralized user identity IDs with IPLD / IPFS in #203

Direct link to comment: https://github.com/matrix-org/matrix-doc/issues/712#issuecomment-466301585

[ghost]

With all the matrix.org HS hosting issues lately and the general slowness of the HS because of too many users is there a chance this could get higher priority so we could maybe get it sometime soon-ish?

When people ask about this feature https://modular.im/tools/matrix-migration keeps getting brought up but it's not really a proper solution.

[ManDay]

Given recent experience, I think this issue might become a greater danger to Matrix as a whole, much quicker than anticipated.

Many people have waited for the release of RiotX/Element to recommend Matrix to their friends and families, notoriously as a replacement for the widespread WhatsApp. Element is about to be released.

People at vector-im know the numbers best, but it's apparent that once Matrix gains just a noteworthy fraction of Facebook/WhatsApp's users, the performance problems that have been plaguing the HS at matrix.org on-and-off will cripple connections all over the place.

Without Decentralized User Accounts, Matrix' federation approach lacks substance (it does not provide the fail-safety and redundancy of what a federation would promise) to handle the amounts of users we hope to acquire, soon. There are only two realistic scenarios how Matrix might scale, both of which end badly in my opinion:

• The amount of public HS increases, thus the probability that at least one of them will go down, thus severing all their users
• Individual HS will increase their ressources, thus increasing the amount of users being severed in case of failure

The transparently federated nature of Matrix so becomes parts of its own fragility. Because, contrary to other messagers which can do behind-the-scenes load managing, users need to gamble for a single point of failure:
They must hope that the HS at which they register will not only remain operational, but is furthermore upscaled to handle increased loads for all time! Should they lose that bet, they will inevitably be frustrated, be it by lack of performance or loss of their accounts.

That is the real danger to Matrix: Not converting users from "Messanger X" is not the same as losing them due to frustration. In the latter case, the loss is most likely permanent. Few "Messanger X" users will give Matrix another chance after such an experience, and that could come costly.

Decentralized accounts, for example where the host in their MXID @user:host will only perform authentication, but not handle any load, will reduce the requirements for that server to only perform authentication (for all time). That seems to be a much safer bet: The average WhatsApp user may rely on matrix.org to perform this task and vector-im has almost no obligation to upscale their servers like they currently would have to.

[7h3kk1d]

It seems like there's also some opportunities for the different home server implementations to operate in more of a "client mode" so they don't have to scale as well. I use one of the small modular/elemental instances and would like to federated to large rooms but can't since my home server can't handle it.

[ShadowJonathan]

@ManDay how would a failure scenario look like? Where a room would become inaccessible due to it's corresponding HS failing, would that HS already pre-emptively have given access (credentials) to "backup" servers to continue handling load, corresponding to amounts of users on those servers participating in that room? Or how would a scenario look like where one's homeserver would go down? As what would that user then "appear" as, and who would host/provide "leaf data" to their profile (such as display name and avatar) from that point on?

In that case, how would username collisions not occur, or migrations happen "offline" (and securely)? If i understand correctly, with this in place, the user would have @user:host as a "current front" identity, basically rallying their identity around that host, but having a backing credential method to their identity, with which they can migrate it.

How would they go about doing that? Both with the HS "online" and "offline", if a user would decide to migrate because their HS has been offline for an unacceptable amount of time, how would the process work? If the user cannot contact their HS to "decouple" their identity anymore, how would the new HS know that it's legit, how would the old HS know (once it comes up) that such a thing has happened in the first place?

What about devices having been compromised? If a malicious actor initiates such a process, what safeguards can/should be in place to prevent such an unauthorized transfer? Unanimous agreement amongst all (known) device sessions? What if a user doesn't have access to them all?

Sorry if my questions seem naive, or too much, or uneducated, I think this is a big improvement, but the goal posts for who trusts who will shift a lot, and in some cases may even be undefined. Please correct my assumptions if they're wrong, or simply unfounded.

[ShadowJonathan]

Also if I understand the other general idea floating around correctly (which I most surely don't, but I like to entertain it) is that one user would have a "myriad" of MXID/@user:host identities, selecting one to display "by default", but all being backed by a single key/ID/pubkey or similar

How would authentication happen this way? Would a user be able to access "all" of it's identities if it logs into one of the HSes? Or would access to identities be on a "log in to each" basis? How would migration, addition, or removal of those identities work?

[ShadowJonathan]

Continuing from the idea of the pubkey; I'm currently thinking of something similar to libp2p's Peer IDs, which are multihashed versions of their public keys, which can then be verified and secured with private keys.

In the case of decentralised accounts, if a user wants to have a "truly" decentralised account, maybe a string would then start to back their user-id-myriad, maybe a multihash encoded in base32 or 64, and having servers uniquely identify an account on that, then the old @user:server becomes simply an alias to the backing multihash.

This way, when any used server (that the user allocated a username in) receives a "control" message encrypted with the private key, the server could then decrypt it with the user's public key (which is identified/verified by the user's multihash), and take the corresponding action on the account (change password, evict other sessions, change avatar, etc.), which then gets added to an internal room and federated to other participating servers, in this room also trivial "server actions" from users can be added, such as session details, device details, and other shared state.

The advantage of using multihashes is that multihashes are equipped to upgrade to newer hash functions, while it might be a future task to look at how-to-upgrade a user's ID between hash functions (maybe something similar to m.room.tombstone), for now i think sticking with generating multihashes with sha256 will be alright.

TL;DR: My proposal is to use multihashes for backing user IDs, controlling events/actions encrypted with private key, backed with internal room federated over used servers (the user is in).

[ShadowJonathan]

Yes, I acknowledge that having a singular private key representing a users' account is a compromise, maybe the key can be stolen, or probably somehow lost, and it requires additional user awareness, i'll say that before it's pointed out.

I give this proposal because I think any proposal to have the servers control the user's account is a no-go, in this case, servers are not to be trusted, servers shouldn't be the highest authority over a user's account if the account is decentralised, even in cases or with solutions like Raft consensus, it'll fail as soon as participating servers go down, or the source of information from one singular server is questionable. Another idea is to have users "update" each server themselves when they perform an administrative action (over their own account), but that's functionally no different than having multiple accounts over multiple servers, as this would not effectively "merge" them, but only virtually. (and don't forget a possible split-brain case if a user updates details when server D is down, and when server D is up, there is no "reliable" or "trusted" way to update user details via backfill then, if the user had to push the data to all servers)

(Strictly personal opinion about private keys and users: I think that the case of additional user awareness over private keys should be spread further anyway, as I think that it will become important enough in the future, to have users be educated and be able to master the idea of a private key being essentially an unchangeable password is something i'd be willing to be let taught in apps extensively these days, as the opposite is a security nightmare, which server admins cannot control then, as control lays with the key)

Edit: In the case to trade-off security with user usability, I think the existence then of "Key Servers" or "Key Services" (something as simple as a yubikey) could help massively, they'd be able to store and back up private keys and/or airgap them (have data be encrypted via an interface), which could give some user usability back, and also allow an administrator (of a type) to back up, administrate, and be responsible for the key data, to allow users to choose whom they trust. This last situation can exist in a communal or friend setting, where 1 admin can preside over 10 users, whom all trust eachother in a close-knit fashion. This is less compromise-able and problematic than a potential 3 admins presiding over all data, access, and information for possibly dozens of users, which is technically the case today for many community matrix servers.

[ShadowJonathan]

I just found out about MSC 1228, and I think it should be mentioned for the sake of idea deduplication; that proposal adds a way to decouple rooms and users from the servers they come from, so maybe looking at that and/or altering it so it could receive this proposal, or adding this proposal to it, could help.

[xuhcc]

There is a draft of W3C standard for decentralized identifiers: https://w3c.github.io/did-core/

[ara4n]

Work started on this a few weeks ago, fwiw - and is scheduled to be the next big thing for the synapse team to work on once Faster Joins land.

[catfromplan9]

Work started on this a few weeks ago, fwiw - and is scheduled to be the next big thing for the synapse team to work on once Faster Joins land.

Awesome, this is very exciting news!

[tgr]

That's great news!
Is there any public information on how you are planning to implement it? Is it related to the OIDC plans?

[montaropdf]

Great news indeed. Is there any spec or a document listing the planned features related to decentralized accounts?

[ara4n]

not yet. we're still finishing off Faster Joins, which is taking forever.

[montaropdf]

not yet. we're still finishing off Faster Joins, which is taking forever.

Is Faster Joins about SQL queries?

[ghost]

@ara4n Faster Joins are completed once every issue on that milestone gets fixed, right?

Also, you mentioned the synapse team, does that mean that only synapse will get this feature and not Dendrite?

[ara4n]

faster joins are completed once synapse ships with support for faster joins, which is basically https://github.com/matrix-org/synapse/milestone/8.

we expect account portability to be implemented first on synapse, and then obviously on dendrite and other HSes too.

[trymeouteh]

Will decentralized acounts allow the user to have unlimited addresses and be able to manage addresses like cryptocurrency wallet address are with a seed phrase? The ability to generate matrix ID for friends, a matrix ID for family, the ability to generate a Matrix ID for business A, etc. Essentially bringing the functionality of SimpleLogin or Anonaddy into Matrix by allowing the user to have as many Matrix ID “aliases” as they want with one account and with the ability to enable/disable a Matrix ID.

[ccgarant]

Will decentralized acounts allow the user to have unlimited addresses and be able to manage addresses like cryptocurrency wallet address are with a seed phrase? The ability to generate matrix ID for friends, a matrix ID for family, the ability to generate a Matrix ID for business A, etc. Essentially bringing the functionality of SimpleLogin or Anonaddy into Matrix by allowing the user to have as many Matrix ID “aliases” as they want with one account and with the ability to enable/disable a Matrix ID.

I agree on this @trymeouteh. We need a master key account ID, from which if I choose to switch servers, I can re-authenticate myself. Some form of wallet, DID, PGP, Self-Sovereign Identity solution is needed.

Problem: I joined on the matrix.org server, and then switched to a personal server. I think had to create a whole new "identity", and could not see any of my prior posts.

You could use CIP-34 for Hierarchical Deterministic Wallets.

[izN8nu6RyeneG5XnBoBgyRMVGH6H43WF]

@ccgarant said:
Some form of [DID] is needed

What a coincidence, the W3C recommendation for Decentralized Identifiers (DIDs) was recently approved.

After reviewing the spec, I think we should use these. As I noted in matrix-org/matrix-spec-proposals#2787:

We currently have several outstanding MSCs and other issues related to decentralized identity, including:

• [WIP] MSC1762: Support user-owned identifiers as new 3PID type matrix-spec-proposals#1762
• [WIP] MSC1768: Proposal to authenticate with public keys matrix-spec-proposals#1768
• [WIP] MSC1781: Proposal for associations for DIDs and DID names matrix-spec-proposals#1781
• MSC3839: primary-identity-as-key matrix-spec-proposals#3839
• Decentralised identity (SPEC-458) #203
• Decentralised user accounts #246

Due to how generic they are, W3C DIDs can (and should) be used as the portable and decentralized identifier mentioned in these GitHub issues.

What this doesn't address, as I noted in element-hq/element-web#1781, is the distinction between the DIDs proper, and the human-friendly Identifier, which is not in scope for the DID spec, so human-friendly Identifiers should also be out of scope for Matrix portable identities. Under the hood, Matrix should probably consider only the DID proper, regardless of how we present this to the user.

If I understood the DID spec, the "standard" way to integrate this into Matrix is to

1. Specify a Matrix-specific DID method.
2. Specify how to resolve a DID using this method into a DID document. The document will include information on how to authenticate the DID subject, which is usually just a Matrix user. Note that this resolution is not the same as the "mapping" from a human-readable identifier to a DID.
3. Specify which authentication methods MUST or SHOULD be supported by clients and servers.
4. Implement.

[seth586]

I agree on this @trymeouteh. We need a master key account ID, from which if I choose to switch servers, I can re-authenticate myself. Some form of wallet, DID, PGP, Self-Sovereign Identity solution is needed.

Problem: I joined on the matrix.org server, and then switched to a personal server. I think had to create a whole new "identity", and could not see any of my prior posts.

You could use CIP-34 for Hierarchical Deterministic Wallets.

Reauthentication isn't even necessary when you are signing your events with your public key. The signature should be the only authentication necessary. The nostr protocol even allows users to switch servers on the fly, and broadcast to several at the same time for the same events.

Identity mapping a public key to a DNS internet identifier is handled with a simple .well-known response. This json response could be updated as DIDs evolve.

[bkil]

Related: matrix-org/synapse#8885

[izN8nu6RyeneG5XnBoBgyRMVGH6H43WF]

...the W3C recommendation for Decentralized Identifiers (DIDs) was recently approved.

A related spec, which DIDs are specifically designed to be used in, is the W3C Verifiable Credentials Data Model (VC-DATA-MODEL). This purports to provide a generalized framework for decentralized authentication.

Insofar as it's useful to analyze portable identities under a common framework for compatibility reasons, it may be worth verifying that our approach to decentralizing user accounts is compatible with VC-DATA-MODEL semantics.

Also, for both DID and VC-DATA-MODEL, if we first describe the current Matrix spec in terms of these frameworks, that might allow us to evolve certain components of Matrix in a decoupled manner. Notably, it might be more obvious how to implement "portable/decentralized user accounts" and e.g. "p2p/shared client-homeserver" functionality separately, so that they don't block each other.

[LorenDB]

Are there any progress reports on this? I see that the faster joins milestone is done in synapse, so maybe this can see some progress? :)

[erlend-sh]

Decentralized identity is also a major topic in the fediverse, where it’s typically referred to as Nomadic Identity:

https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101?u=erlend_sh

One promising solution considers using the emerging UCAN standard as an established starting point to build with DIDs.

UCAN’s local-first approach also seems to mesh well with Matrix’ long term p2p ambitions.

[claell]

Not sure whether it has been mentioned already, or there is an already existing issue about that. If so, I'd love to know.

For me, in addition to being able to switch accounts, I also think that merging accounts will be really important. Let's say I have multiple accounts on different servers. Now, one server shuts down. So with this issue, I can migrate that account, but there is no way to merge it with an existing one (although that might be pretty difficult for conversations where both accounts participated).

[bumblefudge]

tagging myself into the thread as someone with DID WG, crypto wallet, and activitypub experience - happy to help

[Zig-Rust-Odin]

Set up in advance the portable account requests that are automatically sent to other add servers on a daily basis.
server provider is suddenly shut down, just verify the both migration key and the accounts are migrated.
Migrate accounts and contacts only. Chat logs will not be migrated

other

• AT Protocol Portable accounts
• XMPP Account Portability
• https://github.com/snikket-im/xmpp-account-exporter