mirror of
https://codeberg.org/fediverse/fep.git
synced 2026-08-09 14:05:53 +00:00
Deploying from 021c0abdd2 [SKIP CI]
This commit is contained in:
silverpill
+12
-12
@@ -6,7 +6,7 @@
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
|
||||
<meta name="description" content="Relays are important components within the decentralized Fediverse architecture. They act as intermediary servers that facilitate communication between different instances, enabling users on Fediverse platforms to share public content without requiring actor following relationships. These relays benefit small instances by enabling them to effectively participate in the federated social network, both as consumers and producers of Fediverse content. Several styles of relays existing in the Activity Fediverse. This FEP describe two popular styles of relays Mastodon-style relays LitePub-style relays NOTE This is an informational FEP documenting the current status quo. It uses [RFC-2119] requirements keywords only as a convenience. Also, these are not standardized protocols. They will generally not be conformant with the ActivityPub standard although they use some concepts from it.">
|
||||
<meta name="description" content="Relays are important components in the decentralized Fediverse architecture. They act as intermediary servers that facilitate communication between different instances, enabling users on Fediverse platforms to share public content without requiring actor following relationships. These relays benefit small instances by enabling them to effectively participate in the wider federated social network, both as consumers and producers of Fediverse content. Several styles of relays exist in the Activity Fediverse. This FEP describes two popular styles of relays Mastodon-style relays LitePub-style relays NOTE This is an informational FEP documenting the current status quo. It uses [RFC-2119] requirements keywords only as a convenience. Also, these are not standardized protocols. They will generally not be conformant with the ActivityPub standard although they use some concepts from it.">
|
||||
|
||||
|
||||
|
||||
@@ -850,9 +850,9 @@
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="summary">Summary<a class="headerlink" href="#summary" title="Permanent link">¶</a></h2>
|
||||
<p>Relays are important components within the decentralized Fediverse architecture. They act as intermediary servers that facilitate communication between different instances, enabling users on Fediverse platforms to share public content without requiring actor following relationships.</p>
|
||||
<p>These relays benefit small instances by enabling them to effectively participate in the federated social network, both as consumers and producers of Fediverse content. </p>
|
||||
<p>Several styles of relays existing in the Activity Fediverse. This FEP describe two popular styles of relays:</p>
|
||||
<p>Relays are important components in the decentralized Fediverse architecture. They act as intermediary servers that facilitate communication between different instances, enabling users on Fediverse platforms to share public content without requiring actor <code>following</code> relationships.</p>
|
||||
<p>These relays benefit small instances by enabling them to effectively participate in the wider federated social network, both as consumers and producers of Fediverse content. </p>
|
||||
<p>Several styles of relays exist in the Activity Fediverse. This FEP describes two popular styles of relays:</p>
|
||||
<ul>
|
||||
<li><a href="#mastodon-relay-protocol">Mastodon-style relays</a></li>
|
||||
<li><a href="#litepub-relay-protocol">LitePub-style relays</a></li>
|
||||
@@ -901,7 +901,7 @@
|
||||
<h2 id="mastodon-relay-protocol">Mastodon Relay Protocol<a class="headerlink" href="#mastodon-relay-protocol" title="Permanent link">¶</a></h2>
|
||||
<p>The Mastodon relay protocol relies on LD Signatures to verify relayed messages. This allows Mastodon to verify the relayed message although it is being sent by a different actor (the relay server actor).</p>
|
||||
<h3 id="relay-client-actor">Relay Client Actor<a class="headerlink" href="#relay-client-actor" title="Permanent link">¶</a></h3>
|
||||
<p>A Relay Client Actor establishes following relationship with a relay server actor and then processes relayed messages sent to the actor's <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a> inbox. The relay client server will add the relay inboxes to the delivery target for content with public visibility.</p>
|
||||
<p>A Relay Client Actor establishes a <code>following</code> relationship with a relay server actor and then processes relayed messages sent to the actor's <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a> inbox. The relay client server will add the relay inboxes to the delivery target for content with public visibility.</p>
|
||||
<h4 id="relay-subscription">Relay Subscription<a class="headerlink" href="#relay-subscription" title="Permanent link">¶</a></h4>
|
||||
<p>Mastodon will POST an ActivityPub <code>Follow</code> request to the relay ActivityPub <code>inbox</code> URI. The <code>object</code> of the <code>Follow</code> request MUST be the fully expanded URI of the Public pseudo-collection (<code>https://www.w3.org/ns/activitystreams#Public</code>). The relay then responds to the <code>Follow</code> request with an <code>Accept</code> or <code>Reject</code> activity. The response time for the acknowledgement can be arbitrarily long since the subscription MAY require manual approval. </p>
|
||||
<p>The request MUST be signed using the same <a href="https://docs.joinmastodon.org/spec/security/#http">HTTP Signature</a> (Cavage) algorithms that Mastodon uses for ActivityPub federation. The relay will fetch the relay client actor document to obtain the actor's public key. For best interoperability, the actor ActivityPub document SHOULD be Mastodon-compatible. For example, <code>preferredUsername</code> SHOULD be provided in addition to all actor fields required by <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a> and the actor SHOULD provide a <code>sharedInbox</code> endpoint URL.</p>
|
||||
@@ -935,7 +935,7 @@
|
||||
<p>To unsubscribe from a relay send an <code>Undo</code> with the original <code>Follow</code> activity (embedded, or the URI) as the <code>object</code>. There is typically no response to the <code>Undo</code>.</p>
|
||||
<p><strong>Example Undo/Follow Request</strong></p>
|
||||
<div class="highlight"><pre><span></span><code><span class="p">{</span>
|
||||
<span class="w"> </span><span class="nt">"@context"</span><span class="p">:</span><span class="w"> </span><span class="s2">"https: //www.w3.org/ns/activitystreams"</span><span class="p">,</span>
|
||||
<span class="w"> </span><span class="nt">"@context"</span><span class="p">:</span><span class="w"> </span><span class="s2">"https://www.w3.org/ns/activitystreams"</span><span class="p">,</span>
|
||||
<span class="w"> </span><span class="nt">"id"</span><span class="p">:</span><span class="w"> </span><span class="s2">"https://client.example/3f5ebd6d"</span><span class="p">,</span>
|
||||
<span class="w"> </span><span class="nt">"type"</span><span class="p">:</span><span class="w"> </span><span class="s2">"Undo"</span><span class="p">,</span>
|
||||
<span class="w"> </span><span class="nt">"actor"</span><span class="p">:</span><span class="w"> </span><span class="s2">"https://client.example/actor"</span><span class="p">,</span>
|
||||
@@ -984,7 +984,7 @@ Furthermore, the Mastodon documentation does not accurately describe the LD Sign
|
||||
<span class="p">}</span>
|
||||
</code></pre></div>
|
||||
<p>The <code>https://w3id.org/security/v1</code> JSON-LD context defines the <code>signature</code> and related properties, but is not used by Mastodon for LD Signature processing.</p>
|
||||
<p>When performing signature operations the signature document and the activity (without the signature document) are initially processed (hashed) separately. The SHA256 hash digests are concatenated that string is then signed.</p>
|
||||
<p>When performing signature operations the signature document and the activity (without the signature document) are initially processed (hashed) separately. The SHA256 hash digests are concatenated and that string is then signed.</p>
|
||||
<h4 id="signing-a-json-ld-activity">Signing a JSON-LD Activity<a class="headerlink" href="#signing-a-json-ld-activity" title="Permanent link">¶</a></h4>
|
||||
<ol>
|
||||
<li>Create a signature document with only the <code>creator</code> and <code>created</code> properties. Set the <code>@context</code> to <code>https://w3id.org/identity/v1</code>. (Note that this context doesn't appear to be accessible on the web any more. You may need a local copy with a custom JSON-LD context loader.) </li>
|
||||
@@ -1007,7 +1007,7 @@ Furthermore, the Mastodon documentation does not accurately describe the LD Sign
|
||||
<h2 id="litepub-relay-protocol">LitePub Relay Protocol<a class="headerlink" href="#litepub-relay-protocol" title="Permanent link">¶</a></h2>
|
||||
<p>The <a href="https://litepub.social/">LitePub</a> protocol is based on <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a> and is used in Pleroma-compatible servers. The reference implementation is the <a href="https://git.pleroma.social/pleroma/relay">Pleroma Relay</a>.</p>
|
||||
<h3 id="relay-client">Relay Client<a class="headerlink" href="#relay-client" title="Permanent link">¶</a></h3>
|
||||
<p>A LitePub relay client actor must have a type of <code>Application</code> and an actor ID ending with <code>/relay</code>. For best interoperability, it should be compatible with Mastodon actor documents and have WebFinger support. Other implementations may use different actor ID structures (e.g., AodeRelay apparently uses <code>/actor</code> and works with Pleroma). General relay interoperability of these LitePub variants is not known.</p>
|
||||
<p>A LitePub relay client actor MUST have a type of <code>Application</code> and an actor ID ending with <code>/relay</code>. For best interoperability, it should be compatible with Mastodon actor documents and have WebFinger support. Other implementations may use different actor ID structures (e.g., AodeRelay apparently uses <code>/actor</code> and works with Pleroma). General relay interoperability of these LitePub variants is not known.</p>
|
||||
<h4 id="relay-subscription_1">Relay Subscription<a class="headerlink" href="#relay-subscription_1" title="Permanent link">¶</a></h4>
|
||||
<p>The client relay actor will send a <code>Follow</code> to the relay server. The <code>Follow</code> <code>object</code> is the relay server actor URI.</p>
|
||||
<p>The relay server MUST respond to the <code>Follow</code> request with an <code>Accept</code> or <code>Reject</code>. If accepted, the relay server sends a reciprocal <code>Follow</code> request for the LitePub client actor. The client server SHOULD respond with <code>Accept</code> or <code>Reject</code> activity. A relay server MAY decide to ignore the subscription if no acknowledgement is received within a reasonable time interval.</p>
|
||||
@@ -1073,7 +1073,7 @@ Furthermore, the Mastodon documentation does not accurately describe the LD Sign
|
||||
</code></pre></div>
|
||||
<h4 id="publishing-messages-to-a-relay_1">Publishing Messages to a Relay<a class="headerlink" href="#publishing-messages-to-a-relay_1" title="Permanent link">¶</a></h4>
|
||||
<p>A LitePub relay client actor will send an <code>Announce</code> for a relayed object (like a <code>Note</code>). For best interoperability <code>Announce</code> should refer to the announced object using an URI (instead of embedding the object).</p>
|
||||
<p>The <code>Announce</code> activity MUST be address to the relay server actor's followers collection. (TODO it's not known if the admin addressing is also required). The <code>published</code> property should be included since some relay server will reject activities without it.</p>
|
||||
<p>The <code>Announce</code> activity MUST be addressed to the relay server actor's followers collection. (TODO it's not known if the admin addressing is also required). The <code>published</code> property should be included since some relay servers will reject activities without it.</p>
|
||||
<div class="highlight"><pre><span></span><code><span class="p">{</span>
|
||||
<span class="w"> </span><span class="nt">"@context"</span><span class="p">:</span><span class="w"> </span><span class="p">[</span>
|
||||
<span class="w"> </span><span class="s2">"https://www.w3.org/ns/activitystreams"</span><span class="p">,</span>
|
||||
@@ -1097,9 +1097,9 @@ Furthermore, the Mastodon documentation does not accurately describe the LD Sign
|
||||
<span class="p">}</span>
|
||||
</code></pre></div>
|
||||
<h4 id="receiving-messages-from-a-relay">Receiving Messages from a Relay<a class="headerlink" href="#receiving-messages-from-a-relay" title="Permanent link">¶</a></h4>
|
||||
<p>Messages received from a relay are typically wrapped in an <code>Announce</code> activity. AFter the <code>object</code> of the announce is fetched and validated, it is displayed on the federated timeline. It appears that <code>Pleroma</code> will accept a relayed <code>Create</code> activity (for Mastodon compatibility), but will refetch the <code>Create</code> <code>object</code> since the LD Signature isn't processed. (TODO verify this behavior.)</p>
|
||||
<p>Messages received from a relay are typically wrapped in an <code>Announce</code> activity. After the <code>object</code> of the announce is fetched and validated, it is displayed on the federated timeline. It appears that <code>Pleroma</code> will accept a relayed <code>Create</code> activity (for Mastodon compatibility), but will refetch the <code>Create</code> <code>object</code> since the LD Signature isn't processed.</p>
|
||||
<h2 id="other-relay-server-considerations">Other Relay Server Considerations<a class="headerlink" href="#other-relay-server-considerations" title="Permanent link">¶</a></h2>
|
||||
<p>The relay server hosting relay actors will have other functionality other than activity relaying.</p>
|
||||
<p>The relay server hosting relay actors will have functionality other than activity relaying.</p>
|
||||
<h3 id="webfinger">WebFinger<a class="headerlink" href="#webfinger" title="Permanent link">¶</a></h3>
|
||||
<p>A relay server MUST implement <a href="https://www.rfc-editor.org/rfc/rfc7033">WebFinger</a> support for relay actors. This is necessary because of Mastodon's actor fetching implementation. It's possible that it's not required for LitePub-only relay servers.</p>
|
||||
<h3 id="nodeinfo">NodeInfo<a class="headerlink" href="#nodeinfo" title="Permanent link">¶</a></h3>
|
||||
@@ -1107,7 +1107,7 @@ Furthermore, the Mastodon documentation does not accurately describe the LD Sign
|
||||
<h3 id="optional-relay-server-behaviors">Optional Relay Server Behaviors<a class="headerlink" href="#optional-relay-server-behaviors" title="Permanent link">¶</a></h3>
|
||||
<p>A relay server MAY support multiple relay protocols. However, there is no standard way to advertise those capabilities.</p>
|
||||
<p>A relay server often hosts a single actor, but any number of relay actors may be hosted. For example, a relay server may have a relay actor for specific topics, hashtags, or moderation categories. A relay client can subscribe to any number of relay actors in a given server.</p>
|
||||
<p>Some servers implement dynamic relay actor creation. A relay actor's <code>inbox</code> URI might be based on a hashtag or a topic name. When a client actor subscribes to this kind of inbox URI, the relay actor is created automatically. Obviously, there are risks to this approach when used by misbehaved clients.</p>
|
||||
<p>Some servers implement dynamic relay actor creation. A relay actor's <code>inbox</code> URI might be based on a hashtag or a topic name. When a client actor subscribes to this kind of inbox URI, the relay actor is created automatically. Obviously, there are risks to this approach when used by misbehaving clients.</p>
|
||||
<h2 id="references">References<a class="headerlink" href="#references" title="Permanent link">¶</a></h2>
|
||||
<ul>
|
||||
<li>Christine Lemmer Webber, Jessica Tallon, <a href="https://www.w3.org/TR/activitypub/">ActivityPub</a>, 2018</li>
|
||||
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user