Recommendations for working with nested signed objects (FEP-8b32):

https://codeberg.org/fediverse/fep/pulls/292/files

FEP-ae97 and FEP-ef61 require embedding signed objects into other signed objects (example: Create activity), but Data Integrity specification doesn't say how to do that correctly.

Looks like we have two options:

1. Use RDF canonicalization instead of JCS, double down on JSON-LD and RDF
2. Use JCS, but break compatibility with some JSON-LD processors

The proposed change represents option 2 (discussion on SocialHub: https://socialhub.activitypub.rocks/t/use-cases-of-fep-8b32-object-integrity-proofs/3249/18).

#fep_ef61

https://help.instagram.com/914046486923176/

>When Threads blocks communication with other servers on the fediverse
>...fails to meet our Community Guidelines...
>We’ll also block a server if it doesn’t have a:
>Sufficient privacy policy; or
>Publicly available policy to restrict access to users under the age of 13; or
>Publicly accessible feed

There are two fediverses. One of them will comply with these rules, and with whatever rules come after that.

I changed FEP-ef61 representations to use resolver URLs instead of DID URLs. And my resolver now can resolve actor IDs:

https://mitra.social/.well-known/apresolver/did:ap:key:z6MkjtdL1hhAtJDRTti4JZtjGVkMiqbrQWhLQjK8wV4neCvS/actor

The major downside of resolver-URL-as-ID is that existing actors can't be easily upgraded because of ID change, and migration via Move activity will be required. It is a one-time migration, and your actor will be forever free from the server of origin, so maybe it's worth it.

Another thing to note is that inbox is distributed too (its path is relative to DID-based actor ID). Initially I thought that clients will use resolver to get server-local HTTPS URL of an inbox (see section Dereferencing DID URLs, paragraph about the Link header). But now I'm wondering: why not make POST requests directly to the resolver?

Instead of being read-only, it can be read-write. So it's not really a resolver anymore, but maybe a gateway

#fep_ef61

Decentralized identifiers (DIDs) can be divided into 3 categories, depending on where the authority resides:

- Secret key (did:key, did:pkh).
- Server (did:web).
- Blockchain (hundreds of them).

With a #DID derived from a secret key you can truly own your identity. Unfortunately, key rotation is not supported, and if you lose your key, you lose everything. This can be partially mitigated with distributed key generation techniques that make key recovery possible if only M of N shards are available, but they are complicated.

Servers can rotate keys, but they can also suddenly disappear, and again you lose everything.

Blockchain-based systems support key rotation and don't have a single point of failure (if done right). Sometimes they are called "servers with superpowers". However, popular ones are not suitable for the job because writing to them is very expensive and their clients need powerful computing devices and a lot of storage.

Is there a way around that? Yes. Blockchains can be very lightweight and they don't actually need a cryptocurrency, miners or stakers in order to work. There is a simple consensus algorithm known as Proof of authority, and one of the Fediverse competitors, Bluesky, seems to be planning to build such system:

https://github.com/did-method-plc/did-method-plc

>We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium.

They are afraid to say the B-word, but "permissioned consortium" is exactly what it is. Of course, their identity #blockchain doesn't have to be the only one in existence. I think in the future we might see quite a lot of "identity cooperatives" of different shapes and sizes. Perhaps even a universal client, curl for identity, can be developed.

FEP-ef61 resolver endpoint:

https://mitra.social/.well-known/apresolver/did:ap:key:z6MkjtdL1hhAtJDRTti4JZtjGVkMiqbrQWhLQjK8wV4neCvS/objects/018e1080-3792-c4f9-69b0-a6a0f609f94e

This service is a very important part of FEP-ef61. It connects the regular web with the web of signed AP objects, similarly to how IPFS gateways provide access to IPFS objects. However, unlike IPFS objects, AP objects are mutable.

Resolver URLs and DID URLs are equivalent, and implementations that support FEP-ef61 will simply strip the resolver part when they encounter it.

#fep_ef61