notfire/Iceshrimp.NET
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Iceshrimp.NET/FEDERATION.md
Kopper 36d9a8cc49
[backend/federation] Context collection
2024-11-23 18:20:41 +01:00

8.1 KiB
Raw Blame History

Federation

Terminology

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.

This document MAY alias JSON-LD namespace IRIs to their well-known aliases. Specifically, the following aliases are used:

  • as: - https://www.w3.org/ns/activitystreams#
  • toot: - http://joinmastodon.org/ns#
  • fedibird: - http://fedibird.com/ns#
  • misskey: - https://misskey-hub.net/ns#
  • litepub: - http://litepub.social/ns#

Supported federation protocols and standards

  • ActivityPub (Server-to-Server)
    • We perform full JSON-LD processing.
    • Incoming activities (whether sent to the shared/actor inbox or fetched via federation requests) MUST carry a valid JSON-LD context for successful federation with Iceshrimp.NET instances.
    • Regardless, we attempt to make sense of activities carrying some known invalid LD contexts. Specifically:
      • We resolve the nonexistent http://joinmastodon.org/ns context (toot.json) for federation with GTS (which references it by link)
      • We resolve some unofficial ActivityStreams context extensions (as-extensions.json), since some implementors incorrectly reference it by link.
      • See here and here to see all preloaded LD contexts we ship.
    • Outgoing activities are compacted against our well-known LD context (iceshrimp.json).
      • For compatibility with implementors that are not doing full LD processing, we force some attributes to be an array:
        • tag, attachment, to, cc, bcc, bto (all in the https://www.w3.org/ns/activitystreams namespace)
      • For the same reason, we forcibly keep https://www.w3.org/ns/activitystreams#Public as the full IRI, instead of compacting it to as:Public.
      • We trim unused inline properties from the context. For technical reasons, unused namespace aliases are currently not trimmed, but this is subject to change.
  • WebFinger
    • Any actors referenced in activities MUST be queryable via WebFinger for federation with Iceshrimp.NET instances.
    • Actor @id URIs SHOULD be directly queryable via WebFinger, but reverse discovery is performed as a fallback.
    • Split domain configurations are supported (for local and remote actors).
      • Implementors MUST NOT have multiple actors with the same preferredUsername on each web or account domain.
      • Mentions referencing a user by their non-canonical acct (@user@web.domain.tld) get canonicalized on note ingestion.
    • We support WebFinger over application/jrd+json as well as application/xrd+xml (both incoming and outgoing).
      • However, we do not ask for xrd+xml in our Accept header for outgoing WebFinger requests due to compatibility issues with Friendica.
      • Responses MUST have their Content-Type set to application/jrd+json, application/xrd+xml, application/json, or application/xml.
    • We support host-meta over application/jrd+json as well as application/xrd+xml (both incoming and outgoing).
      • The json representation is also accessible under /.well-known/host-meta.json.
      • Implementors SHOULD advertise the WebFinger Content-Type in the type attribute of the WebFinger template in the host-meta response.
        • However, since major implementors either omit the attribute, or incorrectly advertise jrd+json as xrd+xml, we presently ignore this property.
      • Implementors MUST return a link with the attributes rel='self' and type='application/activity+json' in the response.
        • application/ld+json; profile="https://www.w3.org/ns/activitystreams" is treated interchangably with application/activity+json.
  • HTTP Signatures
    • Incoming activities sent to the shared inbox or actor inbox MUST carry a valid HTTP signature, unless LD Signatures are explicitly enabled in the configuration, and the activity carries a valid LD signature.
    • Incoming federation requests MUST carry a valid HTTP signature, unless authorized fetch is explicitly disabled in the configuration.
  • LD Signatures
    • Both LD-signing outgoing activities and accepting LD signatures are disabled by default due to privacy concerns, but instance operators can choose to enable them.
    • as:Delete activities, which don't come with any of the privacy concerns mentioned above, are however accepted regardless of the configuration.
  • NodeInfo (versions 2.0 and 2.1)

Supported FEPs

FEPs we intend to support in the future

Supported non-FEP extensions

  • Bite activities (as specified in mia:Bite)