Easy account migration between instances (nomadic identity)

[mariha]

[Draft]

Ideas:

• export / import of user profiles across platforms
• datashards
• decouple data storage from hospex platform that writes/reads it. Data is stored in some external storage that each platform may be authorized (or not) to access. User changes the platform but data is kept where it was, in the cloud of their choice, possibly even a cloud they self-host. User controls who is authorized to read the data.

Would require common data format + extensions and/or adapters/transformers

---

From A People’s History of the Fediverse

ActivityPub didn’t solve the longstanding federation issues which had been known about since before its creation, such as nomadic identity, key based identity rather than domain based identity and the ability to easily migrate accounts between instances.

These problems had to a large extent been solved some years before with the Zot protocol of Hubzilla, but the creators of ActivityPub appeared to have no interest in that even though they were aware of it.

---

https://socialhub.activitypub.rocks/pub/guide-for-new-activitypub-implementers

There are initiatives towards complimentary standards that could help address issues left unresolved in ActivityPub.

Datashards

brings secure storage foundations to the modern web. It allows users and application developers to reason about secure, private data online or offline.

Datashards might help with ActivityPub issues like account migration.

[nicksellen]

I think The Dream ©️ is that the fediverse/ActivityPub works seamlessly with SOLID.

There are some discussions about it: https://socialhub.activitypub.rocks/t/which-links-between-activitypub-and-solid-project/529 and linked from there some implementations, e.g. https://semapps.org/.

I don't have a very strong grasp of all the implications right now, but my simplistic understanding is something like:

• SOLID can define how/where your data is stored and accessed (in a way that you can migrate too)
• ActivityPub related stuff defines the interaction layers between you and other people using that data

[aschrijver]

Mastodon currently implements account migration, but only in a mastodon-specific way (masto 2 masto, not masto 2 pleroma). Such mechanism can be used for FediHospEx, and when implemented across apps / platforms, offer a universal solution.

I think The Dream is that the fediverse/ActivityPub works seamlessly with SOLID.

Solid might be interesting to FediHospEx in how it allows control over personal data. There's these topics I created on both community forums too:

• https://socialhub.activitypub.rocks/t/how-solid-and-activitypub-complement-each-other-best/727
• https://forum.solidproject.org/t/how-solid-and-activitypub-complement-each-other-best/3134

Solid community is getting more activity recently, but it is unclear what the status of the specs are (still very early days, I guess), and whether Solid vs. ActivityPub/Fediverse are converging or diverging from each other. Also Chris Webber, AP spec co-author, has big questions on the ACL approach of Solid (fediverse trends towards Object Capabilities, see Spritely Goblins).

Besides Solid project itself, the community is the go-to place for questions related to Linked Data in general.

[mulles]

Maybe it is to early (not yet stable technology). But Matrix is exploring your problem and calls it Portable Identities. matrix-org/matrix-spec-proposals#2787

A more generalized solution would be an Ethereum Wallet with an ENS (basically a privat domain) name for discovery. This would have the advantage to come with incentive infrastructure (ETH or other Token). And comes with the benefit that the identity (public adress that the privat key controls) can be used to login to other services as well.

All depends on wether you want to build on existing proven to work technology, which is at it's best federated or you go all, thus straight to web3 (decentralized). So you could use IPFS for Datastorage and ETH for identity management and incentives and/or disincentives.

[weex]

My feeling is that the federation community over-indexes on this kind of migration.

The user model is at the core of almost all app flows so putting in the level of abstraction required to make migration seamless is in my opinion very costly for not a lot of benefit.

The other thing I see with migration is that other parts of a system may not be designed with migration in mind. For example, if content from a user is signed and that signature doesn't survive migration (perhaps each server generates a key for the user, or the signature includes server-specific info), then you have some real work to do to maintain a smooth user experience.

Mostly what seems to work is that identities across servers can be linked. If my profiles on different systems link to one another, that's a pretty simple db entry on each side.

What I do think works is something more like client-side encryption (alluded to by the bullet point "decouple data storage"). Think lastpass or Metamask where a server stores an encrypted file with your PII which is only decrypted client side and all cryptographic ops involving a private key happen in browser or on a trusted hardware module.

---

I see this issue as one for brainstorming, so am simply adding in my two cents. It would be great to think of what's the first step in facilitating nomadic identity or reducing single-server lock-in and create an issue for that.

[aschrijver]

Nomadic identity is a typical subject to be addressed in a Fediverse Enhancement Proposal (FEP). The Zap implementation that's in production for a long time can be the input to that.

[mulles]

I think the key for an identity/authentification/idenification across servers/providers is privat key management/infrastructure with great UX.

PGP was not able to solve this.
Ethereum and Polkatdot are two blockchain project, which seems to be on a good path for it.
https://vitalik.ca/general/2021/01/11/recovery.html

Status.im and localcryptos.com are two projects beeing able to derive double rachet encryptions keys (signal,Matrix,Whatsapp standart) from ones master privat key (which is a derivation of 12/24 word seed phrase). This enables encryption of data, in above examples of messages. The fact that the same privat key is used for communication of value ( transaction of eth or other tokens on the blockchain) gives a strong incentive to the user to secure the privat keys, much more than it ever was concerning PGP keys. Moreover, social recovery helps securing and recovering your privat key.

I think by end of the year the technolgie might be ready to base a hospitaltity plattform on it. Their is the famous saying not your keys not your crypto.
I go further not your keys not your data/account. Crypto/tokens only beeing one kind of data.

[mulles]

I managed to migrate from matrix.org to managed matrix server, by automatically (migration tool) inviting my new user to every room the old user was in, effectively creating a copy of these rooms on my new server. This worked like a charm. Thus if every OHN Account would be a matrix account and furthermore a room would contain all whats needed to engage with a host/traveller, it would be easy to migrate from one server to another today :)

[mariha]

We did an app for SOLID workshop, as a prove of concept. The demo can be watched here: https://youtu.be/dxIOtWg_duQ

It focuses more on data ownership than account portability. Both can be tackled with SOLID.