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

[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.

[Guest]

Fedify has just laid out a comprehensive implementation plan for this fep:

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

The core idea is replacing HTTP(S) URIs with server-independent identifiers: ap:// URIs that use a Decentralized Identifier (DID) as the authority component, rather than a domain name. An object identified as ap://did:key:z6Mk…/actor can live on multiple servers simultaneously and survives any single server disappearing.