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 https://github.com/matrix-org/synapse/issues/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 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]

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 matrix-org/matrix-spec#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/

[pocketnetteam]

Hi, have you progressed any further on this issue? What do you see as the biggest problem:

1. Is it the problems with authenticating users on different homeservers?
2. Is it synchronizing their accounts/roomss etc?
3. Or is it traffic synchronizing chat histories? Really appreciate your answer. We really want to make matrix into a decentralized chat where users do not have home servers per se. We also will keep only three days history, so it is not going to be massive amounts of data. Any help/suggestions are appreciated.

[nathanfranke]

Hi, have you progressed any further on this issue? What do you see as the biggest problem:

1. Is it the problems with authenticating users on different homeservers?
2. Is it synchronizing their accounts/roomss etc?
3. Or is it traffic synchronizing chat histories? Really appreciate your answer. We really want to make matrix into a decentralized chat where users do not have home servers per se. We also will keep only three days history, so it is not going to be massive amounts of data. Any help/suggestions are appreciated.

I would recommend against replying here, the maintainers will just lock the issue to prevent discussion and bury it

[pocketnetteam]

Where is the best place?

[SimonBrandner]

@pocketnetteam Maybe Matrix HQ

[turt2live]

I would recommend against replying here, the maintainers will just lock the issue to prevent discussion and bury it

@nathanfranke we only lock discussion when no new points are being made and the conversation runs in circles over years. It doesn't look like that's the case here, so on-topic conversation is very welcome.

[ara4n]

@pocketnetteam There hasn't been much work on this since https://github.com/matrix-org/matrix-doc/pull/2787, but we'll be revisiting it as part of P2P work soon. P2P has been progressing relatively slowly because we've needed to polish core Matrix stuff to ensure today's network is usable for WhatsApp refugees etc - but we will get back to it this year.

[pocketnetteam]

Thank you! We are actually running an open sourced blockchain project that also has a social network component. We like the idea of Matrix very much and the project looks cool, but lack of decentralization is a major obstacle. We are currently thinking of overcoming it by changing the server side. We have an advantage in that all users are registered on the blockchain and already have a private/public key pair. Here is how we are looking to change it (would love to hear your thoughts):

1. Since every user registers on the blockchain, they can also register their current home server on the blockchain.
2. If their home server disappears, they can simply register a new home server and if the old one comes back, then it causes no conflicts.
3. Every server registers on the blockchain with a public key.
4. All rooms add a certain number of servers for redundancy. So, any room will share data with say at least 5 servers, even if all participants are on one HS. Those 5 servers are chosen deterministically (say public keys that are closes to the hash of the room name).
5. So, even if both HS disappear, users can find room data by the deterministic algorithm. And they can register to a new home server, if HS is not available.
6. In general, authentication on any server is done via private/public key signature, thus it is the same across all servers. This creates a decentralized network of servers. One question this does not resolve is that a user who lost a HS, must restore all of his/her rooms, but in the above framework, they are spread out across servers.

Do you have any thoughts on this? Also, very curious to understand what you are doing to accomodate whatsapp refugees.

[win-some]

I'm wary of putting a hard dependency on a blockchain for identity. It seems to me if one person wants to assert their identity there is no need for distributed consensus, which is what I understand blockchains provide (please correct me if mistaken). Regular PKI should suffice for that, maybe in conjunction with content-based addressing a la IPFS.

[KopfKrieg]

Do you have any thoughts on this?

I don't see the advantage of the blockchain here. What you describe should be doable with a DHT, which is also much simpler to implement, doesn't waste resources like a blockchain (depending on the type of blockchain), and nobody has to run blockchain nodes/miners for that.

Regular PKI should suffice for that,

Exactly my thought.

[pocketnetteam]

Blockchain already exists for other purposes and it provides real decentralization. I understand you are not interested in it, but was hoping to get an opinion on the problems with the scheme I outlined (other than there are differnet ways of doing it). Thank you!

[KopfKrieg]

It's a little bit offtopic, but I'd still like to comment on it:

Blockchain already exists for other purposes

…and waste a lot more energy than whole countries. Of course there are different types of blockchains, with different energy consumption, but I still don't see the advantage of using a blockchain for this application.

Who guarantees the blockchain will still be there in 10-20 years? Who maintains the nodes, the miners, the protocol? Do you realize that this means you have to - in the worst case - support a completely separate network?

and it provides real decentralization.

Do you know what DHT is or how it works? Because it provides "real" decentralization (okay, I have to ask: What is "real" decentralization? Because E-Mail has it, Matrix has it, every application using DHTs has it, so, why do you think blockchains are more "real" decentralized than other solutions?)

[win-some]

Let's try to keep this thread on-topic, because this could quickly devolve into a debate of the merits of blockchains in general, which is interesting but not terribly relevant to portable matrix identities. You both have emails attached to your git identites, so perhaps you could discuss it privately there.

[7h3kk1d]

I don't necessarily want to add more noise to the conversation without substance but it occurs to me that there would be some value in at least enumerating some "user stories" or goals that we're trying to accomplish. I'm not an expert in the domain but I'll kick it off:

1. Allow users to remove the single point of failure that is the homeserver by allowing them to connect to multiple home servers
2. Reduce homeserver load by allowing users (or administrators) to choose which data gets replicated across multiple homeservers.
   • Allow a member of a small homeserver/p2p to join Matrix HQ without having to store all the data clientside and instead trust the matrix.org homeserver
3. Semi-related: It would be convenient if a user could authenticate once and have multiple personas that could be associated with various homeservers.
   • The ability to alternate between a work persona and personal persona are useful and you can imagine having the work persona be owned by a systems administrator.

[kevincox]

In addition to redundancy a goal that I am very interested in is allowing server migration. I can think of a couple of cases.

1. I have a (reasonably trusted) homeserver server and I want to migrate to a new one. (for example from matrix.org to my own domain).
2. My homeserver has turned malicious and I wish to rehome myself. (Either another shared server or my own).
3. A homeserver wants to change it's domain.

[pocketnetteam]

…and waste a lot more energy than whole countries.

This is a proof-of-stake blockchain, let's leave it at that. And yes, when you depend on your home server not going away, that is centralization. Was just trying to understand how you intend to go around it. DHT may solve some problems, but not the problem of authentication, I think.

[pocketnetteam]

I don't necessarily want to add more noise to the conversation without substance but it occurs to me that there would be some value in at least enumerating some "user stories" or goals that we're trying to accomplish. I'm not an expert in the domain but I'll kick it off:

1. Allow users to remove the single point of failure that is the homeserver by allowing them to connect to multiple home servers

2. Reduce homeserver load by allowing users (or administrators) to choose which data gets replicated across multiple homeservers.

   • Allow a member of a small homeserver/p2p to join Matrix HQ without having to store all the data clientside and instead trust the matrix.org homeserver

3. Semi-related: It would be convenient if a user could authenticate once and have multiple personas that could be associated with various homeservers.

   • The ability to alternate between a work persona and personal persona are useful and you can imagine having the work persona be owned by a systems administrator.

matrix-org/matrix-spec-proposals#1 and matrix-org/matrix-spec-proposals#2 are of most interest, but ideally it is done algorithmically without any user or admin involvement via some algorithm.

[pocketnetteam]

Regular PKI should suffice for that, maybe in conjunction with content-based addressing a la IPFS.

So, PKI requires some infrastructure, in a particular someone in charge of a centralized server. I am looking for a permissionless infrastructure. Maybe I am missing something, but could you educate me on how PKI could be used in this environment without a central point of authority? Thank you!

[olanod]

Wanted to comment on the DID standard that didn't get any attention and I wouldn't like it to be overlooked. When it comes to identifying yourself in a decentralized manner solutions in that ecosystem look like a good way to go, different "did methods" can exist(e.g. did:matrix:foobar) that resolve identifiers in different ways, it could be blockchain or could be anything. The possibilities are broad, something like this looks interesting for example, having a self-issued OpenId connect provider that I imagine could fit with the existing OIDC infrastructure that matrix home servers support. Authentication is one step, a different one will be user's data that again can be accessed via DID methods that resolve to documents containing information about how to find information whether it's on a user's personal server, in a blockchain or a decentralized storage like IPFS.

[pocketnetteam]

…and waste a lot more energy than whole countries.

This is a proof-of-stake blockchain, let's leave it at that.

to elaborate, proof of stake blockchains do not use anymore energy than any normal PC running. Proof-of-work requires work, proof-of-stake simply requires a proof of ownership and there is no algorithmic hashing.

[kevincox]

The reason that people aren't responding to your idea is that we don't see any need for a blockchain. People can just sign their attestation and publish it to the DHT. There is no centralization required. There is no need for a provable history as the latest published attestation will be the only one that is used.

So if you think we should use a blockchain you need to be specific about what benefits it provides. Just saying that blockchain is decentralized won't draw people in because the currently proposed solution is already decentralized.

[7h3kk1d]

I don't necessarily want to add more noise to the conversation without substance but it occurs to me that there would be some value in at least enumerating some "user stories" or goals that we're trying to accomplish. I'm not an expert in the domain but I'll kick it off:

1. Allow users to remove the single point of failure that is the homeserver by allowing them to connect to multiple home servers

2. Reduce homeserver load by allowing users (or administrators) to choose which data gets replicated across multiple homeservers.

   • Allow a member of a small homeserver/p2p to join Matrix HQ without having to store all the data clientside and instead trust the matrix.org homeserver

3. Semi-related: It would be convenient if a user could authenticate once and have multiple personas that could be associated with various homeservers.

   • The ability to alternate between a work persona and personal persona are useful and you can imagine having the work persona be owned by a systems administrator.

matrix-org/matrix-spec-proposals#1 and matrix-org/matrix-spec-proposals#2 are of most interest, but ideally it is done algorithmically without any user or admin involvement via some algorithm.

I think this is still up for discussion because I would like control over where the data is persisted. I want decentralization but I don't necessarily want everything replicated everywhere.

[tgr]

My main user story would be decoupling identity from client choice. I want to use a homeserver that's fast, maybe geographically close to me, has a recent software version supporting whatever features I need, preferably run by an organization by I trust, with good privacy practices. All that is volatile and changes over time, and often takes experimentation with new servers to establish which is best. I really don't want to have to reestablish my identity every time I switch to a different homeserver, and I don't want my past conversations fractured between a hundred accounts. For something building as heavily on cryptographic handshakes between users as Matrix does, having a permanent overarching identity is especially important.

[ITwrx]

1. I have a (reasonably trusted) homeserver server and I want to migrate to a new one. (for example from matrix.org to my own domain).

this is my current use case. i want to use someone else's homeserver right now, as the current reference server is too resource intensive for me. Then, when the new go-powered homeserver software is ready for prime time, i will test self hosting. I don't want to create a profile and then start over with a new profile (especially if i get others to join me in the experiment), i want to migrate.

[0-st]

I hoped it could be as simple as e-mail, get a domain name and just adjust the dns records when changing servers, keep the important (or all) messages in a client and sync them back to the new server after migration.

[kevincox]

@Sarkasper There is discussion about using a file in /.well-known/. This is roughly equivalently easy to DNS (Probably easier for some harder for others) but allows for more flexibility.

https://github.com/matrix-org/matrix-doc/pull/2787#discussion_r563031023

[blueforesticarus]

One issue is whether ALL a users data gets copied to every homeserver they use. Ex) I have a matrix.org account. One day I decide I want to run my own homeserver, using that primarily and using matrix.org as a fallback. Then I start doing custom stuff with my homeserver, using it for realtime data with a faster transport backend, and what not. I definitely don't want to dump all that data on matrix.org. But I also don't want to have to use a separate account.

So I need a way to make sure those rooms are not copied anywhere.

[EternityForest]

I am a bit(incredibly) biased against blockchains, so take everything with a grain of salt but:

To me, the point of decentralization is that it keeps working, no matter what. As in, if I'm on a private network with you in Antarctica, it still works.

Blockchain takes that away, because nobody wants to run a full chain node on a phone. Nobody wants that kind of extra bandwidth load on a satellite internet connection.

Nobody is going to mine coins without serious hardware, and proof of stake means the whole thing costs money, and not only that, inconvenient money that probably requires going through some exchange somewhere for most people.

Look at Jami and OpenDHT for an example of decentralization done right, or BitTorrent DHT.

There are so many really cool looking project that I consider pretty much ruined by integrating some kind of blockchain and incentive layer.

Social apps are only worth the value the users give them. It's hard enough to convince someone to use something at all. Even the slightest performance, battery drain, or bandwidth issue, or convoluted multi step signup process, or annoying not-really-p2p-as-used-in-practice blockchain nodes stuff may cause people to lose interest.

On Mon, Feb 22, 2021, 3:50 PM Erich Spaker notifications@github.com wrote:

One issue is whether ALL a users data gets copied to every homeserver they use. Ex) I have a matrix.org account. One day I decide I want to run my own homeserver, using that primarily and using matrix.org as a fallback. Then I start doing custom stuff with my homeserver, using it for realtime data with a faster transport backend, and what not. I definitely don't want to dump all that data on matrix.org. I also don't really want to use a separate account.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/matrix-org/matrix-doc/issues/915#issuecomment-783762142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFZCHZNEL7SJFMSWTJGYCTTALUUDANCNFSM4DKW5DZA .

[blueforesticarus]

@EternityForest what projects do you consider ruined by blockchain?

[porglezomp]

Another user story if it's useful: I want to try out Matrix, but am immediately overwhelmed by having to pick a homeserver that I'll have to stick with, I want that to be a temporary choice where I can change my homeserver later once I know more, and have my existing conversation logs survive. I wouldn't mind updating links and things, but ideally I don't have to give people I have existing conversations with my new contact.

[ShadowJonathan]

Additional info; the fediverse doesn't have this pressure as much, as you can freely switch homeservers after you decide the one you picked at the start isn't for you.

(It achieves this by notifying every server of the migration, it merely switches over followers, follows, and such, I believe this'll obviously be harder in a federated trustless-ish environment like matrix)

[olanod]

Adding to that I would say it's not only about migrating(and notifying about the migration) but having a reliable decentralized mechanism to manage the set of aliases that represent who I am as I should be able to exist in different homeservers at the same time as well, like an in-device p2p homeserver that is not always online(e.g. @olanod:<p2p-id/public-key>) and my home-homeserver(e.g. @olanod:my.home).
I guess a DHT can be used for storing those mappings but that's an implementation detail that I think should be abstracted in case the future decides those kinds of registries should be stored in something more blockchainy or in a collective consciousness overseen by the AI overlords. I still think something like a DID Document or similar can be a good format for representing those mappings which can be exposed as a new API(or extension to the federation API?) used to update the mappings to tell the world we migrated server or have a new extra one that also wants updates.

[luxaritas]

To add a potential use case: We have an embedded chat on our website, which currently uses IRC. I'm toying with the idea of migrating to Matrix. Our embedded chat would likely work by automatically logging in via SSO via our website. Ideally, we would also require that logins are tied to accounts on our website to ensure consistency to users when displaying identities. Now, what happens if one of our users uses Matrix? It would be nice if they could connect their account on our server to their account on their normal homeserver, so that they can keep it synced with their homeserver while allowing us to automatically log them in via our website.