Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 03:15:35 JST silverpill

   I think FEP-ae97 with server-independent IDs is the best way to make identities and data portable in #ActivityPub world.

   FEP-c390 + Move activity makes identity portable but not data, and requires wide adoption to provide meaningful benefits. So far there haven't been much interest from developers.

   FEP-ae97 with server-independent IDs makes data portable as well, and while it is not compatible with existing software, the server can support both AP flavors at the same time, so it is not worse than FEP-c390 + Move. I also found a way to make it work with Mastodon API, that makes it a clear winner.

   There is still a couple of things that need to be figured out, of course:

   - What it the best way to specify a list of hosts where data is stored? I'm not entirely satisfied with ?hosts=server1.example,server2.example solution.
   - How to encrypt data? It's harder to maintain confidentiality of private messages when they are stored on multiple servers, therefore they should be encrypted.

   • Sexy Moon and on-lain ✔ᵛᵉʳᶦᶠᶦᵉᵈ like this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:25:59 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis

     >Maybe a public key-based identifier for a ‘activity/actor storage server’?

     I'm proposing DID URLs for IDs. Take a look at section named "Server independent IDs" in FEP-ae97.

     For example, if actor ID is

     did🔑z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2

     (just a public key), then we can construct object IDs in the following way:

     did🔑z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/object/f66a006b-fe66-4ca6-9a4c-b292e33712ec

     Resolution process:

     1. Resolve did🔑z6Mkr... to actor object.
     1.1. If you already know this actor, look it up in database.
     1.2. If you don't know this actor, use ?hosts= hint, look it up on specified servers
     1.3. If there's no hint, try to request object from some popular server (mastodon.social?) or from an indexer service
     2. Actor object should contain an up-to-date list of servers where data is replicated.
     3. Resolve DID URL to object
     3.1. If you already know this object, look it up in database
     3.2. If you don't know this object, look it up on servers associated with an actor

     Other types of DIDs will require a different resolution algorithm.

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Sunday, 19-Nov-2023 06:26:00 JST arcanicanis

     in reply to

     For server-independent IDs, would that be stored under another property name other than id, or something fully replacing the id or being appended to it and parsed?

     If a server is receiving an activity, then it should inherently have some implied discoverability about where the activity is stored, if it wasn’t sent through a relay. I don’t know if there’s some supplemental identifier that could be associated to an instance that’s decoupled from DNS. Maybe a public key-based identifier for a ‘activity/actor storage server’?

     For encrypting private data: perhaps start on a simple PGP-ish model, where payload is encrypted directly for the actor’s keypair. People may whine that it doesn’t fill every checkbox of their “demands” for privacy, but it would be trivial to implement, and some later “true E2EE with full forward secrecy” solution can come later as an optional upgrade. Perhaps there’d need to be a new object type (or something borrowed from vocabulary of other JSON-LD-based crypto specs) such as ‘EncryptedActivity’, maybe with an optional type-hint of what the payload activity/object type is (if it’s not anything somehow sensitive).

     Ultimately, I do strongly believe FEP-c390 and FEP-ae97 is the inherent future for ActivityPub, or some light variation of it, and I really hope to see the current hack of HTTP Signatures (and especially the current one-key-only per actor representation, for a key that’s just an entirely server-held always-unencrypted private key in a database) to be gradually phased out soon (or at least a shift towards a ‘server key’ for HTTP Signature-based delivery, of something that can be locked down, versus the lie of a private key for each actor, that the actor doesn’t even control, in the current use of HTTP Signatures).

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:35:12 JST silverpill

     in reply to

     • Steve Bate

     @steve Yes, and to keep this list up to date you need to update all your objects. However, this query parameter is just a hint and shouldn't be treated as part of ID. If the list of servers is outdated, consuming implementations may try to ask some big popular server to resolve this actor

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Sunday, 19-Nov-2023 06:35:13 JST Steve Bate

     in reply to

     @silverpill I'm not comfortable with the "hosts=" approach either because the full URI still depends on domain names.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:40:52 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis Yes, it's going to be two fediverses, but I think the cost of supporting two variants of AP protocol should be low because the data format is the same.
     Send activities with domain based IDs to legacy servers, send activities with DID based IDs to next gen servers.

     Sexy Moon and on-lain ✔ᵛᵉʳᶦᶠᶦᵉᵈ like this.
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Sunday, 19-Nov-2023 06:40:53 JST arcanicanis

     in reply to

     • arcanicanis

     Or sorry, I should have read first: you did explain server-independent IDs in FEP-ae97 (I may have overlooked it in the past). I guess I’m cautionary in using DIDs directly as JSON-LD IDs, for the concern of breaking compatibility. I think a separate property could be used instead, despite it adding more cruft (although I don’t know a comparable solution for endpoints in an actor object). Or alternately there having to be alternate representations of objects (DID and legacy), which however would inherently be it’s own separate fediverse entirely.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 12:12:57 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis

     >I think a separate property could be used instead, despite it adding more cruft

     With a separate property it will be difficult to create links. Take for example inReplyTo property, if you use a separate property the reply will look like this:

     { "type": "Note", "id": "https://alice.example/objects/123", "didUrl": "did🔑xyz/objects/123", "content": "This note has two IDs", "inReplyTo": { "id": "https://bob.example/objects/567", "didUrl": "did🔑ijk/objects/567" }, ... }

     Mastodon probably won't accept such inReplyTo value, so you'll get a separate fediverse either way. I think single ID approach is cleaner

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Monday, 20-Nov-2023 03:48:13 JST silverpill

     in reply to

     • arcanicanis

     @arcanicanis It might work, I don't see any serious flaws in this solution.

     It is not yet clear which solution is easier to implement

   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Monday, 20-Nov-2023 03:48:14 JST arcanicanis

     in reply to

     Perhaps a property that contains an associative array that serves as a substitution table for any referenced object IDs or it’s children (if I’m not making a grossly bloated proposition)?

     { "type": "Note", "id": "https://alice.example/objects/123", "content": "This is a AP/DID polyglot post", "inReplyTo": "https://bob.example/objects/567", "didMap": { "https://alice.example/objects/123": "did🔑zAbc123xyzBaSe64zyx/post/123", "https://bob.example/objects/567": "did🔑z6ZxyBl0bofMu1tih4sh3tc/post/567" } }