search

kitsune-soc / kitsune

🦊 (fast) ActivityPub-federated microblogging
https://joinkitsune.org
Other
317 stars 20 forks source link

Nomadic Identity #190

Open erlend-sh opened 1 year ago

erlend-sh commented 1 year ago

https://socialhub.activitypub.rocks/t/defining-alsoknownas/907 https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101/ https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-c390.md

Example implementation of fep-c390: https://codeberg.org/silverpill/mitra

Implementing this fep for Kitsune to be compatible with Mitra would set a strong precedent for a stable fep proposal, ready for wider adoption.

aumetra commented 1 year ago

Related to #134

erlend-sh commented 1 year ago

Ah there it is. I had forgotten about the ‘identity proofs’ moniker when I looked ahead of posting. Feel free to just merge these links in there and delete this issue, as it may be redundant.

erlend-sh commented 4 months ago

https://socialhub.activitypub.rocks/t/fep-7952-roadmap-for-actor-and-object-portability/4332

Proposal text

The prime objective of the FEP is summed up pretty well here:

Unbundle the services and concerns of a typical instance

  1. Sign everything: Recognize client-side cryptographic signatures as proof of authorship (by implementing FEP-8b32: Object Integrity Proofs), in addition to the current practice of relying solely on the instance URL.
  2. B.Y.O. Actor ID: Using Object Integrity proofs enables Identity Hosting to be separated from the other instance concerns. Actor profiles can now be hosted separately from the instance (including as a static JSON object on a personal website), which in turn enables service providers to offer their users a “BYO (Bring Your Own) domain name” feature.
  3. Separate Inbox/Outbox: (Optional) The previous steps enable message transfer and Inbox/Outbox hosting to be outsourced to separate service providers (the Actor profile links to these in the usual manner).
  4. Separate Object and Collection hosting: (Optional) Similarly, AP Objects and Collections can now be stored on domains separate from the Actor's domain (since authorship and controller-ship can be proven cryptographically, in a domain-independent way). This enables the user to migrate storage service providers without having to change their Actor ID.

Bring-your-own Actor ID! 🪪💫

That’s really all I ever needed from the notion of a ‘single-user instance’. What I want to manage primarily on my own is just my identity, not a full AP server.

In this paradigm, someone’s tiny personal website could also be their Actor-ID Provider, and nothing more. That ID could in turn be used to as a (reasonably nomadic) account on any FEP-7952 compatible instance.

the idea is to detach the Actor object (which could be operated by a microserver that consumes almost zero resources, and basically just operates a big redirect table like a link-shortener) from the Service Provider, to be a little more like

  • email (in the use case where you point a domain that you own and configure at protonmail or mailgun or some other provider)
  • or SMS service (in that regulation enables you to keep your number when you switch phone co’s).
silverpill commented 4 months ago

Meanwhile, FEP-c390 has been superseded by FEP-ef61. FEP-c390 still can be useful for linking cryptographic keys to actors, but it doesn't provide data portability. That problem was solved in FEP-ef61, which was then implemented by two projects, Streams and Mitra (though our implementations are incomplete and not yet interoperable).

FEP-ae97 has been rewritten as a companion to FEP-ef61. The server-side API is implemented in Mitra, and there is also a proof-of-concept client.

I'm now preparing to release a Rust library containing the building blocks for nomadic ActivityPub.

erlend-sh commented 1 week ago

Looks like @silverpill has moved Nomadic Identity into a general-purpose AP crate 💫

https://codeberg.org/silverpill/mitra/src/branch/main/apx_sdk https://codeberg.org/silverpill/fep-ae97-client

silverpill commented 1 week ago

Yep :) Unpolished and undocumented, but it has everything one needs to start building nomadic applications. I'll move it into a separate repo and publish on crates.io once API stabilizes (tracking issue: https://github.com/kitsune-soc/kitsune/issues/190).

erlend-sh commented 1 week ago

Regarding this: from fep-ef61:

Implementers MUST support the did:key method and MAY support the did:web method. Other DID methods SHOULD NOT be used, as it might hinder interoperability.

@silverpill would you consider did:tdw as an alternative (or replacement) for did:web?

silverpill commented 1 week ago

Yes, I plan to add a list of DID methods which might be "blessed" in the future: did:tdw, did:dns and did:fedi. did:web will also be moved to that list because no one supports it yet.