Update: https://codeberg.org/fediverse/fep/pulls/497

[silverpill@socialhub.activitypub.rocks]

I keep federated groups in mind when I am working on this. I don't think it limits ActivityPub in any way, but I guess we will see once implementations begin to emerge.In any case, the idea here is not to replace existing ActivityPub network, but to complement it.

[helge@socialhub.activitypub.rocks]

Can one use this combined with a HTTPS actor? e.g.

{ "@context": [ "https://www.w3.org/ns/activitystreams", "https://w3id.org/security/data-integrity/v1", "https://w3id.org/fep/ef61" ], "type": "Note", "id": "ap://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/objects/dc505858-08ec-4a80-81dd-e6670fd8c55f", "attributedTo": "http://host.example/actor", "content": "Hello!", "to": [ "http://host.example/followers", "https://www.w3.org/ns/activitystreams#Public" ], "proof": {"...": "..."}}

would be a message (with corresponding Create). http://host.example/actor would acknowledge did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2 by having it in its assertionMethod.

This would lead to portable objects without portable actors. In particular objects that don't need to live on servers.

[silverpill@socialhub.activitypub.rocks]

helge:

Can one use this combined with a HTTPS actor?

Yes, I think it might work:

• The did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2 authority claims that object is attributed to http://host.example/actor
• The host.example authority claims that did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2 can sign things on its behalf.

Authorities agree, therefore this object can be trusted.

helge:

This would lead to portable objects without portable actors. In particular objects that don’t need to live on servers.

Why not make actors portable too? FEP-ef61 can work in compatibility mode, in that case the actor ID would look like this:

http://host.example/.well-known/apgateway/did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor

[helge@socialhub.activitypub.rocks]

silverpill:

Why not make actors portable too?

It's the entire evolution not revolution concept. Sending portable objects from an existing https actor is kind of an intermediate step, where one doesn't have to change everything.

[silverpill@socialhub.activitypub.rocks]

Update: https://codeberg.org/fediverse/fep/pulls/529

Preferred gateways can be declared in a DID document (as DID services), and maybe in actor's endpoints mapping too.

I think using endpoints for that makes a lot of sense because according to the ActivityPub spec, this object "...maps additional (typically server/domain-wide) endpoints which may be useful either for this actor or someone referencing this actor." In FEP-ef61 world, these endpoints are "DID-wide".

[silverpill@socialhub.activitypub.rocks]

helge:

Can one use this combined with a HTTPS actor?

This is somewhat similar to FEP-c390 Identity proofs, where two authorities, domain-based and DID-based, are coordinating to create a verifiable link. I added a new section to FEP-fe34 called "Cross-origin relationships", where such use cases will be covered.

[Guest]

Hello! Just thought I'd share some early work I've done on adding FEP-ef61 support to my fork of Bluesky's PDS server with ActivityPub support. More information on that project can be found here:

https://github.com/bluesky-social/atproto/pull/3943

Anyway, as for FEP-ef61 support, it's not in my draft PR yet, but below you can find a few sample screenshots of responses. Notably, my in implementation I convert AtProto DID's into ActivityPub DID's by storing the AtProto DID's in did:key's with the MultiDID encoding (as a base58 string).

The first is my updated webfinger, and a placeholder apgateway showcasing DID conversion.

Second, an A/B comparison of what my standard actor profile response looks like, and what it looks like in "FEP ef61" format. It's currently only available behind a query parameter, at least until I finish the gateway.

EDIT: Click the GitHub link above. I'm not allowed to post 2 images or more than 2 links as a new user.

[silverpill@socialhub.activitypub.rocks]

Hello @PoV !

PoV:

Notably, my in implementation I convert AtProto DID’s into ActivityPub DID’s by storing the AtProto DID’s in did:key’s with the MultiDID encoding (as a base58 string).

You can use ATProto DIDs directly, without encoding them with multiDID.

FEP-ef61 is compatible with all DID methods, and did:key requirement was added only to facilitate implementation convergence. But existing FEP-ef61 implementations support only Ed25519 did:key, so we won't be able to interoperate.

What do you think about did:web? As far as I know, this method is supported by ATProto, and we also considered supporting it in Fediverse.

[Guest]

silverpill:

You can use ATProto DIDs directly, without encoding them with multiDID.

That would be nice. As you'd expect, this lead me down this path:

DID Methods

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

It might be worth clarifying that not using Multidid Ed25519 keys hinder interoperability, than simply not using did:key.

silverpill:

FEP-ef61 is compatible with all DID methods, and did:key requirement was added only to facilitate implementation convergence. But existing FEP-ef61 implementations support only Ed25519 did:key, so we won’t be able to interoperate.

I'm curious what existing implementations use the Ed25519 keys for, besides unique identifiers? I do realize they're also public keys, but I haven't got to signing or validating yet in my implementation.

silverpill:

What do you think about did:web? As far as I know, this method is supported by ATProto, and we also considered supporting it in Fediverse.

I'm indifferent as I haven't personally used AtProto's did:web support. That said, from my understanding, it doesn't technically support the full did:web standard (domains and subdomains only, no URLs). Parts of the code support encoding URL slashes as :'s, which I'm not sure is the standard or not, but according to the team this isn't the case everywhere. The only reliable part is the domain.

[silverpill@socialhub.activitypub.rocks]

PoV:

It might be worth clarifying that not using Multidid Ed25519 keys hinder interoperability, than simply not using did:key.

The recommendation to use Ed25519 is there too, it's in the next paragraph:

DID documents SHOULD contain Ed25519 public keys represented as verification methods with Multikey type (as defined in the Controlled Identifiers specification).

Both are SHOULD, however. This is to say: we are exploring various DID methods, but did:key + ed25519 is what is currently used in production.

PoV:

I’m curious what existing implementations use the Ed25519 keys for, besides unique identifiers? I do realize they’re also public keys, but I haven’t got to signing or validating yet in my implementation.

Those Ed25519 keys are used to sign ActivityPub objects. Here's an example of an actor:

https://mitra.social/.well-known/apgateway/did:key:z6MknVmyPtQmD2SaGnqyGgTVEqfqkkJJnY3YVKBmbzSUNCcX/actor

The signature is in the proof object, produced in accordance with https://www.w3.org/TR/vc-data-integrity/ standard.

[Guest]

Gotcha, thanks for that.

Curiously, I noticed that document has no JSON LD @context section. While I realize JSON LD doesn't necessarily require it, I just haven't seen any "valid" documents without it. Is that at all commonplace, or just a fluke that this specific implementation doesn't use them?

EDIT: Mmm... Is it omitted because the content type is application/ld+json; profile="https://www.w3.org/ns/activitystreams", thus "@content": "https://www.w3.org/ns/activitystreams" is implied?

[silverpill@socialhub.activitypub.rocks]

It was a test, the @context is already restored.ActivityPub says that "Implementers SHOULD include the ActivityPub context in their object definitions." I think it means that @context could be omitted if you have a good reason do so. But Mastodon rejects actor documents without @context, so everyone includes it for compatibility reasons. Other implementations seem to be more forgiving - this is what I was testing

[Guest]

Came across this historical artifact from @cwebber today that might be a good addition to the References:

https://bsky.app/profile/dustyweb.bsky.social/post/3lyvxn2ijt22g

https://github.com/WebOfTrustInfo/rwot5-boston/blob/2735129406b42bca9ea0d33c5e22f8f771c48aab/final-documents/activitypub-decentralized-distributed.md#activitypub-overview

[silverpill@socialhub.activitypub.rocks]

erlend_sh:

Came across this historical artifact from @cwebber today that might be a good addition to the References:

I probably read this document at some point, but I don't think it influenced the development of FEP-ef61 in any way. DIDs and content addressing were discussed on this forum too, there were even attempts to implement something, but they were not successful.

[silverpill@socialhub.activitypub.rocks]

I didn't post about the latest update here, it happened about one month ago: https://codeberg.org/fediverse/fep/pulls/668

[silverpill@socialhub.activitypub.rocks]

More updates:

• https://codeberg.org/fediverse/fep/pulls/695
• https://codeberg.org/fediverse/fep/pulls/717

[Guest]

Should one be able to publish a portable object that is repudiable? IIUC, FEP-ef61 portable objects (identified by ‘ap’ URIs) require FEP-8b32 integrity proofs, so they are non-repudiable. On the other hand, FEP-c390 identity proofs establishes links between DIDs and HTTP(S) actors, but they don’t make objects portable. So that seems to be not possible with current proposals.

I’m curious because there are cases where one doesn’t want non-repudiation. For example, you don’t want your private message to be disclosed by the recipient in a publicly verifiable way. But that does not necessarily mean that you don’t want the object to be portable.

[silverpill@socialhub.activitypub.rocks]

If you rotate verification method, all previous FEP-8b32 proofs become unverifiable. Does this count as repudiation?

did:key doesn't support VM rotation, but there will be other "blessed" DID methods (most likely did:web and did:webvh).

Additionally, some cryptographic tricks may exist that enable repudiable signatures, for example I was able to find this paper: https://dl.acm.org/doi/10.1145/3659467.3659901

[trwnh@socialhub.activitypub.rocks]

silverpill:

If you rotate verification method, all previous FEP-8b32 proofs become unverifiable. Does this count as repudiation?

this could work but only if the rotation was a "blind rotation", i.e. without a verifiable log of the old key being associated with the identity. if there is a log of the key rotation, then no.

more pressingly, if the key is your identity, then it cannot be rotated without also fundamentally changing your identity. so key rotation with repudiation requires a non-key identity -- in other words, a name (and authoritative name server) or description (and a way of asserting trusted claims that match the description).

silverpill:

Additionally, some cryptographic tricks may exist that enable repudiable signatures, for example I was able to find this paper: https://dl.acm.org/doi/10.1145/3659467.3659901

from what i understood of the paper, it seems this is just delegating signatures to some authority who can sign things on your behalf. you can then claim the authority forged signatures on your behalf. it's basically like how fedi uses custodial keys in most cases.

[silverpill@socialhub.activitypub.rocks]

My question was addressed to @tesaguri

Yes, did:key can not be rotated, I think this is exactly what I said in my comment.