GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 03:15:35 JST silverpill 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.

    In conversation Sunday, 19-Nov-2023 03:15:35 JST from mitra.social permalink
    • Sexy Moon and lainy like this.
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:25:59 JST silverpill 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.

      In conversation Sunday, 19-Nov-2023 06:25:59 JST permalink
    • Embed this notice
      arcanicanis (arcanicanis@were.social)'s status on Sunday, 19-Nov-2023 06:26:00 JST arcanicanis 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).

      In conversation Sunday, 19-Nov-2023 06:26:00 JST permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:35:12 JST silverpill 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

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

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

      In conversation Sunday, 19-Nov-2023 06:35:13 JST permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 06:40:52 JST silverpill 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.

      In conversation Sunday, 19-Nov-2023 06:40:52 JST permalink
      Sexy Moon and lainy like this.
    • Embed this notice
      arcanicanis (arcanicanis@were.social)'s status on Sunday, 19-Nov-2023 06:40:53 JST arcanicanis 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.

      In conversation Sunday, 19-Nov-2023 06:40:53 JST permalink
    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Sunday, 19-Nov-2023 12:12:57 JST silverpill 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

      In conversation Sunday, 19-Nov-2023 12:12:57 JST permalink

      Attachments



    • Embed this notice
      silverpill (silverpill@mitra.social)'s status on Monday, 20-Nov-2023 03:48:13 JST silverpill 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

      In conversation Monday, 20-Nov-2023 03:48:13 JST permalink

      Attachments


    • Embed this notice
      arcanicanis (arcanicanis@were.social)'s status on Monday, 20-Nov-2023 03:48:14 JST arcanicanis 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" } }
      In conversation Monday, 20-Nov-2023 03:48:14 JST permalink

      Attachments



Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.