mirror of
https://codeberg.org/fediverse/fep.git
synced 2026-08-05 11:46:04 +00:00
FEP-ef61: Update proposal
- Changed link to (streams) docs. - Added did:ap resolution algorithm. - Fixed contexts in examples. - Removed FEP-ae97 requirement. - Recommend using resolver URLs for backward compatibility. - Added note about ap:// URL scheme. - Added link to schema.org/sameAs
This commit is contained in:
silverpill
+54
-25
@@ -25,7 +25,7 @@ The proposed solution should satisfy the following constraints:
|
||||
|
||||
## 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).
|
||||
[Streams](https://codeberg.org/streams/streams) implements [Nomadic Identity](https://codeberg.org/streams/streams/src/commit/5a20e0102b73a2c05e72bead13ddd712e4c2f885/FEDERATION.md#nomadic-identity) 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).
|
||||
|
||||
@@ -35,15 +35,25 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
|
||||
|
||||
## DID URLs
|
||||
|
||||
ActivityPub objects can be made portable by using [DID URLs][DID URLs] for IDs instead of HTTP(S) URLs.
|
||||
[ActivityPub][ActivityPub] objects can be made portable by using [DID URLs][DID URLs] for IDs instead of HTTP(S) URLs.
|
||||
|
||||
## did:ap
|
||||
|
||||
`did:ap` is a [DID][DID] method that can be used to add DID URL functionality to other types of DIDs.
|
||||
|
||||
In such DID, the method name is `ap`, and the method-specific identifier is a DID with some other method.
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
did:ap:example:xyz
|
||||
```
|
||||
|
||||
To resolve a `did:ap` DID, implementations MUST remove the `:ap` segment and resolve the remaining DID. Any DID URL capabilities of a wrapped DID method MUST be ignored by the resolver.
|
||||
|
||||
### did:ap:key
|
||||
|
||||
`did:ap:key` method works in the same way as [did:key][did:key] method, but supports [DID URL syntax][DID URLs].
|
||||
DIDs starting with `did:ap:key` work in the same way as [did:key][did:key] identifiers, but support [DID URL syntax][DID URLs].
|
||||
|
||||
### Dereferencing DID URLs
|
||||
|
||||
@@ -65,9 +75,9 @@ Example:
|
||||
Link: <https://social.example/objects/did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/path/to/object>; rel="alternate"
|
||||
```
|
||||
|
||||
If object identified by `did:ap:key` URL is not stored on a server, it MUST return `404 Not Found`.
|
||||
If object identified by `did:ap:key` URL is not stored on the server, it MUST return `404 Not Found`.
|
||||
|
||||
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.
|
||||
If object is not public, the server 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. The value of `verificationMethod` property of the proof MUST match the DID component of the DID URL.
|
||||
|
||||
@@ -83,8 +93,12 @@ Example:
|
||||
"https://www.w3.org/ns/activitystreams",
|
||||
"https://w3id.org/security/data-integrity/v1",
|
||||
{
|
||||
"fep": "https://w3id.org/fep/c390#",
|
||||
"aliases": "fep:aliases"
|
||||
"xsd": "http://www.w3.org/2001/XMLSchema#",
|
||||
"aliases": {
|
||||
"@id": "xrd:Alias",
|
||||
"@type": "@id",
|
||||
"@container": "@list"
|
||||
}
|
||||
}
|
||||
],
|
||||
"type": "Person",
|
||||
@@ -108,7 +122,7 @@ Example:
|
||||
|
||||
### Actor IDs
|
||||
|
||||
When constructing ActivityPub objects, implementations SHOULD provide a list of HTTP(S) URLs where actor object can be retrieved.
|
||||
When ActivityPub objects that contain references to actors are being constructed, implementations SHOULD provide a list of HTTP(S) URLs where actor objects can be retrieved.
|
||||
|
||||
The list of URLs MUST be specified using the `aliases` query parameter, URL-endcoded and separated by commas.
|
||||
|
||||
@@ -129,20 +143,12 @@ Implementations MUST discard query parameters when comparing `did:ap:key` identi
|
||||
|
||||
Implementations obtain local addresses of inbox and outbox from a `Link` HTTP header after dereferencing corresponding DID URLs.
|
||||
|
||||
ActivityPub clients MUST follow [FEP-ae97][FEP-ae97] to publish activities. A client MAY deliver signed activities to multiple outboxes, located on different servers. A server SHOULD forward signed activities to outboxes located on other servers where actor's data is stored.
|
||||
ActivityPub clients MAY follow [FEP-ae97][FEP-ae97] to publish activities. In this case, the client MAY deliver signed activity to multiple outboxes, located on different servers.
|
||||
|
||||
Upon receiving an activity in actor's outbox, server SHOULD forward it to outboxes located on other servers where actor's data is stored.
|
||||
|
||||
Upon receiving an activity in actor's inbox, server SHOULD forward it to inboxes located on other servers where actor's data is stored.
|
||||
|
||||
### Discovering locations
|
||||
|
||||
(This section is non-normative.)
|
||||
|
||||
This proposal makes use of the `aliases` property, but the following alternatives are being considered:
|
||||
|
||||
- `sameAs`
|
||||
- `alsoKnownAs` (used for account migrations, so the usage of this property may cause issues)
|
||||
- `url` (with `alternate` [relation type](https://html.spec.whatwg.org/multipage/links.html#linkTypes))
|
||||
|
||||
## Portable objects
|
||||
|
||||
Objects identified by `did:ap:key` URLs MUST contain [FEP-8b32][FEP-8b32] integrity proof.
|
||||
@@ -153,7 +159,13 @@ Example:
|
||||
{
|
||||
"@context": [
|
||||
"https://www.w3.org/ns/activitystreams",
|
||||
"https://www.w3.org/ns/credentials/v2"
|
||||
"https://w3id.org/security/data-integrity/v1",
|
||||
{
|
||||
"digestMultibase": {
|
||||
"@id": "https://w3id.org/security#digestMultibase",
|
||||
"@type": "https://w3id.org/security#multibase"
|
||||
}
|
||||
}
|
||||
],
|
||||
"type": "Note",
|
||||
"id": "did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/objects/dc505858-08ec-4a80-81dd-e6670fd8c55f",
|
||||
@@ -184,13 +196,30 @@ Example:
|
||||
|
||||
## Compatibility
|
||||
|
||||
(This section is non-normative.)
|
||||
DID URLs are not compatible with existing [ActivityPub][ActivityPub] implementations.
|
||||
|
||||
DID URLs are not compatible with existing [ActivityPub][ActivityPub] implementations. The following workarounds are being considered:
|
||||
Publishers MAY use HTTP(S) URL of a resolver query instead of an actual DID URL. Implementations that support DID URLs MUST remove the part of the URL preceding `did:ap` and resolve the remaining DID.
|
||||
|
||||
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 `canonical` relation type, as proposed in [FEP-fffd][FEP-fffd]). For pointers to other objects such as `inReplyTo` property, an embedded object with `url` property can be used instead of a plain URL.
|
||||
3. Alter object ID depending on the capabilities of the peer which can be reported by [NodeInfo][NodeInfo] or some other mechanism.
|
||||
## Discussion
|
||||
|
||||
### URL scheme
|
||||
|
||||
An alternative to the `ap` DID method could be a URL scheme with the same name. Example: `ap://did:example:xyz/objects/123`.
|
||||
|
||||
### Discovering locations
|
||||
|
||||
This proposal makes use of the `aliases` property, but the following alternatives are being considered:
|
||||
|
||||
- [`sameAs`](https://schema.org/sameAs)
|
||||
- `alsoKnownAs` (used for account migrations, so the usage of this property may cause issues)
|
||||
- `url` (with `alternate` [relation type](https://html.spec.whatwg.org/multipage/links.html#linkTypes))
|
||||
|
||||
### Compatibility
|
||||
|
||||
The following alternatives to resolver URLs are being considered:
|
||||
|
||||
1. Use regular HTTP URLs but include a link to a DID URL in the `url` (with `canonical` relation type, as proposed in [FEP-fffd][FEP-fffd]). For pointers to other objects such as `inReplyTo` property, an embedded object with `url` property can be used instead of a plain URL.
|
||||
2. Alter object ID depending on the capabilities of the peer which can be reported by [NodeInfo][NodeInfo] or some other mechanism.
|
||||
|
||||
## References
|
||||
|
||||
|
||||
Reference in New Issue
Block a user