FEP-ef61: Portable Objects

Hello!

This is a discussion thread for the proposed FEP-ef61: Portable Objects.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Portable ActivityPub objects with server-independent IDs.

2 Likes

I’m updating the proposal: #224 - FEP-ef61: Update proposal - fediverse/fep - Codeberg.org

The /.well-known/apkey endpoint works similarly to a DID resolver, so I think it makes sense to align its specification with Decentralized Identifier Resolution (DID Resolution) document.

I’m also wondering if did:apkey should be changed to did:ap:key (providing a common base for did:ap:web and others).

A quick nitpick: both the examples in this FEP have

"@context": "https://www.w3.org/ns/activitystreams"

They should include "https://w3id.org/security/data-integrity/v1" as well.

1 Like

Out of curiosity, is there a specific design reason why there’s use of aliases instead of alsoKnownAs?

That would conflict with other uses of alsoKnownAs. I talked about this recently in adjacent topic:

The name of this property can be changed (to sameAs?), but it should be distinct from alsoKnownAs.

1 Like

Just as a mentionable find: apparently alsoKnownAs is in the DID core spec as an optional way to indicate other identifiers for a DID subject (actor?): Decentralized Identifiers (DIDs) v1.0

Interestingly in the JSON-LD context for DIDs (https://www.w3.org/ns/did/v1) it actually aliases to the ActivityStreams ID for alsoKnownAs right now:

{
  "@context": {
    "@protected": true,
    "id": "@id",
    "type": "@type",
    "alsoKnownAs": {
      "@id": "https://www.w3.org/ns/activitystreams#alsoKnownAs",
      "@type": "@id"
    },
(...)
2 Likes

yes, this is the source of the conflict described in Defining alsoKnownAs - #30 by trwnh

essentially, DIDWG and SWICG had a joint meeting in 2021 to formalize that DID would use as:alsoKnownAs (and that the official activitystreams context would adopt as:alsoKnownAs). this led to the situation we currently have, where the property is in the activitystreams namespace but is actually defined in the DID spec. and of course, to further complicate things, mastodon had already been using the as:alsoKnownAs property unofficially for some years prior… with a slightly different semantic usage. where the DID spec defines it as “different identifiers for the same subject”, mastodon’s usage is more like “different subjects with the same controller”. i really wish that mastodon had gone with some other method of establishing requirements for a Move activity, such as rel-me links in the actor’s attachment fields.

a DID subject doesn’t have to be an actor, btw, it’s just the thing that a URI would be identifying, and the corresponding resource would be describing.

Update: #240 - FEP-ef61: Update proposal - fediverse/fep - Codeberg.org

Switching to did:ap:key:

did:ap is a DID method that can be used to add DID URL functionality to other types of DIDs.

This change creates a boundary between identities (represented by ordinary DIDs) and data (did:ap and DID URLs). One can imagine similar constructions such as did:ap:web, did:ap:pkh and others.

Update: #275 - FEP-ef61: Update proposal - fediverse/fep - Codeberg.org

I added some notes on backward compatibility and property names.