Important work happening around HTTP Signatures in the Fediverse. Stronger key validation, better digest handling, clearer test vectors—all steps toward more secure and trustworthy ActivityPub communication.
HTTP Signature Upgrades Coming Soon
https://activitypub.blog/2025/07/03/http-signature-upgrades-coming-soon/
#Fediverse #CyberSecurity #ActivityPub #DigitalIdentity #HTTPsignatures #Decentralisation #WebSecurity
We're excited to announce the release of #Fedify 1.6.1, which marks the beginning of the 1.6 series following the retraction of version 1.6.0. This release introduces significant new capabilities that expand Fedify's deployment options and enhance security compatibility across the #fediverse.
🌐 Cloudflare Workers support
Fedify 1.6 introduces first-class support for Cloudflare Workers, enabling #serverless deployment of #ActivityPub applications at the edge.
New components
WorkersKvStore: A key–value store implementation using Cloudflare's KV API for persistent storage in Workers environmentsWorkersMessageQueue: A message queue implementation leveraging Cloudflare Queues for reliable message processingKey features
queue() methodFederation.processQueuedTask() methodFor a complete working example, see the Cloudflare Workers example in the Fedify repository.
🏗️ Federation builder pattern
Fedify 1.6 introduces the FederationBuilder class and createFederationBuilder() function to support deferred federation instantiation. This pattern provides several benefits:
The builder pattern is particularly useful for large applications and environments like Cloudflare Workers where configuration data is only available at runtime.
🔐 HTTP Message Signatures (RFC 9421)
Fedify 1.6 implements the official HTTP Message Signatures standard (RFC 9421) specification, the final revision of the HTTP Signatures specification.
Double-knocking mechanism
To ensure maximum compatibility across the fediverse, Fedify 1.6 introduces an intelligent double-knocking mechanism:
This approach ensures seamless communication with both modern and legacy ActivityPub implementations while positioning Fedify at the forefront of security standards.
Interoperability testing
The RFC 9421 implementation has been thoroughly tested for interoperability with existing ActivityPub implementations that support RFC 9421 signature verification:
These tests confirm that other ActivityPub implementations can successfully verify RFC 9421 signatures generated by Fedify, ensuring proper federation as the ecosystem gradually adopts the official specification. While these implementations currently support verification of RFC 9421 signatures, they do not yet generate RFC 9421 signatures themselves—making Fedify one of the first ActivityPub implementations to support both generation and verification of the modern standard.
🔍 WebFinger enhancements
Dedicated WebFinger lookup
The new Context.lookupWebFinger() method provides direct access to WebFinger data, offering developers more granular control over account discovery and resource resolution beyond the higher-level Context.lookupObject() method.
🛠 Context API improvements
Context data replacement
The new Context.clone() method enables dynamic context data replacement, providing greater flexibility in request processing and data flow management. This is particularly useful for middleware implementations and complex request routing scenarios.
🚀 Migration considerations
Backward compatibility
Fedify 1.6 maintains full backward compatibility with existing applications. The new HTTP Message Signatures and double-knocking mechanisms work transparently without requiring any code changes.
Node.js version requirement
Important: Fedify 1.6 requires Node.js 22.0.0 or later for Node.js environments. This change does not affect applications using Deno or Bun runtimes. If you're currently using Node.js, please ensure your environment meets this requirement before upgrading.
New deployment options
For new deployments, consider leveraging Cloudflare Workers support for:
🎯 Looking forward
Fedify 1.6 represents a significant expansion of deployment possibilities while maintaining the framework's commitment to broad compatibility across the fediverse. The addition of Cloudflare Workers support opens new architectural patterns for federated applications, while the RFC 9421 implementation ensures Fedify stays current with emerging ActivityPub security standards.
For detailed migration guides, API documentation, and examples, please visit the Fedify documentation. Join our community on Matrix or Discord for support and discussions.
#fedidev #RFC9421 #HTTPSignatures #HTTPMessageSignatures #CloudflareWorkers
Any C# developer want to contribute a C# example of how to do HTTP Signing to go along with our existing Java, JavaScript, Python and Go examples?
When an #ActivityPub server implements authorized fetch (aka secure mode), how does it associate the keyId in an HTTP request with the actual actor? I know major implementations (like Mastodon) use a fragment appended to the actor IRI as a keyId, but in theory a keyId could be any IRI that seems unrelated to the actor IRI, right? Should I maintain a table of actor–keyIds somewhere in the server?
This document, edited by @snarfed.org, is really helpful for implementing #Fedify in practice.
Okay, so I wasn’t wrong that these are two very and hilariously different things maddeningly named the same.
STANDARDS! 🥴
There's a pretty big incompatible design gap between the"Signing HTTP Messages” draft proposal ¹ and the “HTTP Message Signatures” RFC-9421², right…?
Doesn't the Fediverse basically run on the former? And, according to the reference below, no one’s implemented the latter. Seems… odd.
Implementation reference: https://fedidevs.org/reference/signatures/
¹ https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12
² https://datatracker.ietf.org/doc/html/rfc9421
Si no ho he entés malament, si vols que un servidor #Mastodon et faci cas quan li envies una activitat #Activitypub, per exemple "Follow", et cal signar amb la clau privada del usuari emissor, xifrada amb el hash SHA256, l'activitat en format json que li envies.
Si el servidor Mastodon receptor no rep la signatura vàlida en els "headers", no fa ni cas.
#HTTPSignatures
I hate this requirement of having to sign the HTTP request to see the Activity-JSON for ActivityPub actor.
I hate it so much.
...
It makes it so I cannot do a simple "curl" command to get an ActivityPub actor's activity-JSON.
#ActivityPub #ActivityStreams #Fediverse #HTTPSignatures #Mastodon
My #SolidProject client and server are now ready for efficient access control demos on #BigData using the HTTP WG's 's "Signing HTTP Messages".
I can demo with a server publishing N resources (in this case, #LinkedData Event Stream (#LDES) data.
The client is implemented in #Scala using #http4s, and the server uses #Akka.
The libraries can be compiled to JS for use on #nodeJS frameworks too. Native is not far off, either.
The client need make no more than N+2 requests:
1. Request 1 on a resource R returning a "401 Unauthorised"
2. a max of 2 requests to get the access control rules
3. from there on, N signed requests using #HttpSignatures (when those all fall in the same container space)
Solid clients are essentially like Search Engine crawlers fetching data on the web, so they need to jump around from website to website. Having approx 2 requests extra per website for auth is very interesting in that scenario.
Note: those 2 requests can be cached, so those may be only needed once over a long period of time. The connection efficiency is possible by combining the following pieces:
• using the IETF's HTTPSig (a version from the beginning of the year)
• using default rules (part of the spec)
• caching of ACLs on the client
• the use of a "defaultAccessContainer" link header to reduce the number of requests.
I am trying to work out who may be interested in such a technical demo, what a good time for it may be, ...
so please just comment here or send me a mail at henry.story@bblfish.net
I think, I've discovered another strange behavior of Mastodon. When Lemmy announces a post, It creates an Announce with a Create with an Note. It appears that Mastodon then fetches the Create with a signed HTTP get and then fetches the Note without the signature. I'm not 100% sure if that's all the 401 showing up in my log file, but it seems likely to be the case.
If anyone has a test setup, where they can verify this behavior, feel free to check and then report it.
I'm not confident in my conclusions, as I have no idea how I would go about implementing it.
Is https://github.com/HelgeKrueger/bovine/blob/main/docs/client_to_server_activitypub.md#this your Client built to work with a generic #ActivityPub server?
I am interested in clients that want to work with our backend.
Note, #DBMS and Authentication matters are none issues since our servers implement most of these protocols (including the likes of #HTTPSignatures etc).
/cc @gabek @mike @atomicpoet @davew @judell @Mastodon @smallcircles
Notes so far on #Mastodon's #ActivityPub implementation, covering basics on #WebFinger, #HTTPSignatures, #JSONLD signatures, and #ActivityStream vocab. Pretty much a loosely-organized collection of links to useful specs and implementations for understanding how Mastodon specifically does things.
https://raphaelluckom.com/posts/Things%20I%27ve%20learned%20about%20ActivityPub%20so%20far.html
This is a mass surveillance action in the public eye #ukrainerussia #surveillance #httpsignatures https://m.youtube.com/watch?v=vdnTbeGtxuQ&feature=youtu.be&cbrd=1
Just found this how to. I think that is very well explained! Thanks for that! It's to earley for #rdfpub, but I'm looking forward to it.
