mirrors/fep
1
0
Fork 0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-08 13:35:51 +00:00
Code Packages Wiki Activity

fix: update FEP 11dd with additional clarity fixes, upgrade inheritance logic to be stricter (inherit root node's context), and add in sentence re: out-of-scope situations where context may not inherited (#724)

Browse Source 
Co-authored-by: Julian Lam <julian@nodebb.org>
Reviewed-on: https://codeberg.org/fediverse/fep/pulls/724
Co-authored-by: devnull <devnull@noreply.codeberg.org>
Co-committed-by: devnull <devnull@noreply.codeberg.org>
This commit is contained in:
devnull
2025-11-07 17:25:44 +01:00
committed by silverpill
parent 6035bae2e4
commit 043bf5bffb
1 changed files with 22 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fep/11dd/fep-11dd.md
+22 -11
View File
@@ -11,12 +11,16 @@ trackingIssue: https://codeberg.org/fediverse/fep/issues/675
## Summary
### What is a context?
[FEP 7888] lays out some guidelines for use of the `context` as a common property between a set of objects when they can be grouped together through reply association (e.g. a reply-tree).
### What is this for?
This proposal aims to extend these guidelines further by codifying:
1. That a context declares an owner via `context.attributedTo`.
1. The situations where a context may be inherited by new objects.
1. That a context must declare an owner via `context.attributedTo`.
1. Where and when a context may be inherited by new objects.
## Requirements
@@ -26,16 +30,16 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
## Context Ownership
A context MUST have an owner. Actions carried out pertaining to the context itself MUST be carried out (via `actor`) by the context owner . These actions are out of scope of this FEP.
The following are upgrades to FEP 7888 that pertain to ownership:
A context MUST have an owner. The following are upgrades to FEP 7888 that pertain to ownership:
1. A `context` MUST be resolvable.
1. When resolved the `context` MUST contain:
* `attributedTo` denoting the authority/owner of that context.
* `attributedTo` MUST resolve to an actor.
1. `context.attributedTo` MUST resolve to an actor ([ActivityPub §4.1 Actor Objects](https://www.w3.org/TR/activitypub/#actor-objects)).
e.g. A resolvable context collection (see [FEP f228]) declares an owner by setting `context.attributedTo` to a resolvable URI.
### Example
A resolvable context collection (see [FEP f228]) declares an owner by setting `context.attributedTo` to a resolvable URI.
```
{
@@ -48,20 +52,27 @@ e.g. A resolvable context collection (see [FEP f228]) declares an owner by setti
## Context Inheritance
Inheritance is considered only when a new object being published has a relation (typically via `inReplyTo`) to another object.
There are situations where a relation exists but context is explicitly *not* inherited (e.g. forked topic, quote post). These situations are out of scope of this FEP.
### As a publisher
The object SHOULD inherit a `context` other than its own. It is RECOMMENDED that the object inherit the `context` of the object it is in reply to. Doing so will allow for all members of a `context` collection (per [FEP f228]) to refer to the same `context`.
The object MUST inherit `context` from the root node, if the property is present and resolvable. Otherwise the object MUST NOT publish a context.
The object MAY inherit `context` further up the chain.
Implementors SHOULD map that inherited context to a local identifier (if applicable) to support future use-cases/activities.
When publishing an object with a `context` property _outside the local domain_, the context owner SHOULD be addressed (`to`, `cc`, `bto`, `bcc`).
When publishing an object with a `context` property _outside the local domain_, the context owner SHOULD be addressed (`to`, `cc`, `audience`).
> [!NOTE]
> If an object is at the root/top-level, then there is nothing to inherit and a new context should be generated.
### As a consumer
When consuming an object declaring a `context` _outside the local domain_, the object's membership MAY be verified by resolving the context directly.
>[!NOTE]
> The remote `context`'s server may not immediately reflect the object's membership due to delays in processing.
> The remote `context`'s server may not reflect the object's membership in a timely manner due to delays in processing (i.e. network congestion, approval queues, etc.)
## References