Julian FietkauApr 6

RE: https://mastodon.social/@bagder/116359048796181736

Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.

On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.

Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?

#ActivityPub #FediDev #RFC9421

Show threadmayel6d ago

we recently added RFC-9421 to @[email protected] : https://docs.bonfirenetworks.org/federation-interoperability.html#7-http-signatures-secure-fetch

not doing double-knock but rather using different methods to try and discover what the other side supports (in priority order):

  • Inbound signature caching: When a remote server sends us a signed request, we cache which format they used (cavage or RFC 9421)
  • Accept-Signature header: When we receive an Accept-Signature response header from a remote server (on any response — WebFinger, object fetch, inbox POST), we cache RFC 9421 support for that host
  • FEP-844e generator detection: Check remote actors' generator.implements or the instance service actor's implements property for RFC 9421 support URIs (see below)
  • NodeInfo software version: Look up the remote's software name and version against a known-support map (e.g., Mastodon ≥ 4.5.0, Fedify ≥ 1.6.0, Hollo, Mitra)
  • Default: Fall back to draft-cavage
    • Bonfire Federation Interoperability Guide — Bonfire v1.0.3-social-alpha.21

    Show threadEvan Prodromou
    @mayel @Bonfire why not do double-knocking, especially if you're already caching signature policy by host?
    Apr 11 at 12:40pmWeb