@ -23,6 +23,12 @@ The proposed solution should satisfy the following constraints:
- The solution should be compatible with existing and emerging decentralized identity and storage systems.
- The solution should be transport-agnostic.
## History
[Streams](https://codeberg.org/streams/streams) implements [Nomadic Identity](https://codeberg.org/streams/streams/src/commit/11f5174fdd3dfcd8714974f93d8b8fc50378a193/FEDERATION.md?display=source#L54-L59) mechanism, that makes identity independent from a server. Nomadic accounts are currently not supported by ActivityPub but are available via the [Nomad protocol](https://codeberg.org/streams/streams/src/commit/11f5174fdd3dfcd8714974f93d8b8fc50378a193/spec/Nomad/Home.md).
[Decentralized Identifiers (DIDs) v1.0][DID] specification suggests that DIDs might be assigned to web resources in section [B.8 Assigning DIDs to existing web resources](https://www.w3.org/TR/did-core/#assigning-dids-to-existing-web-resources).
## Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119][RFC-2119].
@ -63,7 +69,7 @@ If object identified by `did:ap:key` URL is not stored on a server, it MUST retu
If object is not public, `/.well-known/apresolver` MUST return `404 Not Found` unless the request has a HTTP signature and the signer is allowed to view the object.
After retrieving an object, the client MUST verify its [FEP-8b32][FEP-8b32] integrity proof.
After retrieving an object, the client MUST verify its [FEP-8b32][FEP-8b32] integrity proof. The value of `verificationMethod` property of the proof MUST match the DID component of the DID URL.
## Portable actors
@ -166,6 +172,14 @@ Example:
}
```
## Compatibility
DID URLs are not compatible with existing [ActivityPub][ActivityPub] implementations. The following workarounds are being considered:
1. Use HTTP URL of a resolver query instead of an actual DID URL. Implementations that support DID URLs should be able to extract the DID URL from the HTTP URL and process the object accordingly.
2. Use regular HTTP URLs but include a link to a DID URL in the `url` (with the `canonical` relation type, as proposed in [FEP-fffd][FEP-fffd]).
3. Alter object ID depending on the capabilities of the peer which can be reported by [NodeInfo][NodeInfo] or some other mechanism.