“조용한 연합우주” 문제를 해결하는 두 가지 접근법: 대화 백필링 메커니즘
https://hackers.pub/@hongminhee/2025/quiet-fediverse-two-approaches

“조용한 연합우주” 문제를 해결하는 두 가지 접근법: 대화 백필링 메커니즘
https://hackers.pub/@hongminhee/2025/quiet-fediverse-two-approaches
Fedilab users, vote on #Codeberg for these issues on my quality-of-life fixes wishlist!
Add support for quoted posts: https://codeberg.org/tom79/Fedilab/issues/700
Make server announcements more visible: https://codeberg.org/tom79/Fedilab/issues/865
Implement grouping of boosts in timeline to a similar degree as Mastodon web client: https://codeberg.org/tom79/Fedilab/issues/857
Improve the UX of timeline refreshment: https://codeberg.org/tom79/Fedilab/issues/703#issuecomment-5040264
Support filters in Pleroma (and Akkoma): https://codeberg.org/tom79/Fedilab/issues/555
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.
Did you know? #Fedify provides #documentation optimized for LLMs through the llms.txt standard.
Available endpoints:
Useful for training #AI assistants on #ActivityPub/#fediverse development, building documentation chatbots, or #LLM-powered dev tools.
#Fedify 1.6 is approaching with three major enhancements: RFC 9421 HTTP Message Signatures support with double-knocking for seamless backward compatibility, a new builder pattern for better code organization in large applications, and native #Cloudflare #Workers support for serverless deployments. These additions strengthen Fedify's standards compliance while expanding deployment flexibility across different environments. Stay tuned for the official release!
#Cloudflare #Workers support is now complete! After implementing the test infrastructure, core module, examples, and comprehensive documentation, #Fedify can now run on Cloudflare Workers.
What's included:
@fedify/fedify/x/cfworkers
module with WorkersKvStore
and WorkersMessageQueue
Try it now: Available in the development release v1.6.1-dev.876+7b07d213:
This will be included in the upcoming Fedify 1.6 stable release. Thank you to everyone who requested this feature and provided feedback throughout the implementation!
If you're interested in building your own #ActivityPub server but don't know where to start, I recommend checking out #Fedify's #tutorial Creating your own federated microblog. It provides a comprehensive, step-by-step guide that walks you through building a fully functional federated application. Perfect for developers who want to dive into the #fediverse!
This is how I am thinking about pointing to the GreatApe WebSocket API in the activity file.
The GreatApe WebSocket API — ActivitySocket ? — is sending ActivityPub activities over a WebSocket, along with some other stuff (such a queries, and commands).
Right now, I am using the "endpoints" field with the sub-field "inoutbox" to point to the WebSockets API end-point.
We're planning to reorganize our #GitHub labels to better reflect #Fedify's project structure!
Currently using GitHub's default labels, but we want something more tailored to our needs—like component-specific labels (vocab, federation, actor, etc.), runtime tags (Deno/Node/Bun), and #ActivityPub compatibility tracking.
The proposal includes hierarchical labeling with categories like:
type/
for bug, feature, documentationcomponent/
for different parts of Fedifyactivitypub/
for interop issues with Mastodon, Misskey, etc.We'd love your thoughts! What labels would be most helpful for contributors and maintainers?
Check out the full proposal: https://github.com/fedify-dev/fedify/issues/238.
While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.
Fedify accepts vocabulary contributions when they meet any of these criteria:
Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties
section in the relevant .yaml file.
This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.
For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.
Had a wonderful time today at our second FediDev KR #sprint (@sprints.fedidev.kr) gathering at Turing's Apple (@TuringAppleDev) in #Seoul!
We spent the day contributing to various #fediverse open source projects including @fedify, @hollo, and Hackers' Pub. It was fantastic to see the community come together to build and improve tools for the decentralized social web.
Our participants made some great contributions, and you can read all about what we accomplished in today's blog post.
Looking forward to our next sprint!
GreatApe, a federated live audio platform, is hosting an event right now! Give it a go, help test it out.
Exciting update We're inviting a handful of select users to https://Channel.org now
https://Channel.org aims to bring together knowledge across the open social web, whilst offering organisations the ability to build a social home instead of renting from Big Tech dictators.
If you'd like to join the beta waitlist, let us know at support@channel.org
I've been thinking about adding a debug dashboard to #Fedify that shows all #ActivityPub activities being sent and received in real-time. This would include filters by activity type, detailed inspection of JSON-LD content, signature verification details, and retry management for failed deliveries.
As a #fedidev, would you find this useful for troubleshooting federation issues? Any other features that would be helpful in such a debugging tool?
PieFed adds PassKeys! As in, log in only with your passkey. Not just as a 2FA addition to your username/password.
I've been thinking about client-server interactions in the #fediverse. #ActivityPub #C2S isn't widely used, and most clients rely on Mastodon-compatible APIs instead.
What if we created a new standardized API based on GraphQL + Relay for client-server communication, while keeping ActivityPub for server-to-server federation?
The Mastodon-compatible API lacks formal schema definitions for code generation and type checking, which hurts developer productivity. And ActivityPub C2S is honestly too cumbersome to use directly from client apps.
#GraphQL would give us type safety, efficient data fetching (only get what you need), and the ability to evolve the API without breaking clients. #Relay's features for pagination, caching, and optimistic updates seem perfect for social apps.
Would this be valuable to our community? What challenges do you see? How might we handle backward compatibility? And should this be formalized as an FEP?
Curious what others think about this approach.
Okay, I've just deployed a bleeding edge #Fedify, which implements both RFC 9421 and double-knocking, to Hackers' Pub. If you'd like to test your implementations against a real server, please give it a try! (If you want to create an account, let me know—I can invite you.)
Looking for #ActivityPub implementations with #RFC9421 support!
As mentioned in the Fedify announcement below, I've implemented RFC 9421 (HTTP Message Signatures) and need to verify its interoperability with other ActivityPub implementations.
The challenge is that most major ActivityPub projects don't seem to have full RFC 9421 implementations in production yet. If you're working on an ActivityPub project that:
Please reach out! I'd love to collaborate on interoperability testing to ensure our implementations work properly with each other before merging this into #Fedify's main branch.
Any leads or connections would be greatly appreciated!
We're excited to announce that we've implemented RFC 9421 (HTTP Message Signatures) in #Fedify, complete with our double-knocking mechanism to maintain backward compatibility with the draft cavage version.
This implementation includes both signature generation and verification, meaning #RFC9421 is used when both sending and receiving activities. While we haven't merged the RFC 9421 implementation branch yet, we're currently conducting interoperability tests with development versions of Mastodon and other #ActivityPub implementations. Once these tests confirm compatibility, we'll proceed with the merge.
As noted in the attached docs, although RFC 9421 is the final and official standard for HTTP Signatures, the draft cavage version remains widely used across the #fediverse. Our double-knocking mechanism ensures maximum compatibility by trying the RFC 9421 version first, then falling back to draft cavage if needed.
Currently, we support RSA-PKCS#1-v1.5 key pairs for generating HTTP Message Signatures, with plans to expand to other signature types in future releases.
We look forward to contributing to a more standardized and secure fediverse!
4/
This relay could even use the ActivityPub actor type "Feed".