shakedown.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A community for live music fans with roots in the jam scene. Shakedown Social is run by a team of volunteers (led by @clifff and @sethadam1) and funded by donations.

Administered by:

Server stats:

244
active users

#fedidev

4 posts4 participants0 posts today

“조용한 연합우주” 문제를 해결하는 두 가지 접근법: 대화 백필링 메커니즘

hackers.pub/@hongminhee/2025/q

Hackers' Pub · “조용한 연합우주” 문제를 해결하는 두 가지 접근법: 대화 백필링 메커니즘이 글은 연합우주(fediverse)에서 발생하는 "조용한 연합우주" 문제, 즉 대화의 일부만 보이는 현상의 원인과 해결책을 탐구합니다. ActivityPub 프로토콜의 분산 특성으로 인해 대화가 여러 서버에 분산되어 저장되면서 발생하는 이 문제를 해결하기 위해, 답글 트리 크롤링과 컨텍스트 소유자 기반 방식이라는 두 가지 주요 접근법을 제시합니다. 답글 트리 크롤링은 모든 답글을 순차적으로 가져오는 방식이지만 네트워크 취약성과 작업량 증가의 단점이 있고, 컨텍스트 소유자 방식은 대화의 원 작성자가 대화 내용을 관리하는 중앙화된 접근법이지만 컨텍스트 소유자에 대한 의존성이 높다는 단점이 있습니다. 또한, 모더레이션 패러다임의 충돌과 상위 전파 누락 문제와 같은 논쟁점을 지적하며, 주기적 크롤링, 사용자 트리거, 멘션 기반 백필과 같은 추가적인 백필 메커니즘을 소개합니다. 마지막으로, FEP 수렴 논의와 구현체 간 협력 현황을 통해 향후 개발 방향으로 하이브리드 접근법의 표준화를 제시하며, 다중 전략 구현, 리소스 관리, 모니터링 및 로깅의 모범 사례 가이드라인을 제시합니다. 이 글은 연합우주가 더욱 풍부하고 연결된 소셜 네트워크로 발전하기 위한 노력과 사용자 경험 개선의 중요성을 강조합니다.

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

Key features

  • Seamless integration with #Cloudflare's serverless runtime
  • Automatic handling of queue message processing through Workers' queue() method
  • Support for Node.js compatibility flag required for Fedify's cryptographic operations
  • Manual queue processing via Federation.processQueuedTask() method

For 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:

  • Deferred instantiation: Set up dispatchers and listeners before creating the federation object
  • Better code organization: Avoid circular dependencies and improve project structure
  • Cloudflare #Workers compatibility: Accommodates binding-based architectures where resources are passed as arguments rather than globals
  • Modular setup: Build complex federations piece by piece before instantiation

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:

  1. Primary attempt: RFC 9421 (HTTP Message Signatures) for modern implementations
  2. Fallback: Draft cavage version for legacy compatibility
  3. Adaptive caching: The system remembers which version each server supports to optimize future requests

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:

  • Mitra 4.4.0: Successfully verified Fedify-generated RFC 9421 signatures
  • Mastodon 4.4.0 development version: Tested RFC 9421 signature verification against Fedify's implementation (refer to Mastodon PR #34814, though Mastodon 4.4.0 has not yet been released)

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:

  • Global edge deployment with low latency
  • Serverless scaling and automatic resource management
  • Integration with Cloudflare's ecosystem of services

🎯 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.

workers.cloudflare.comCloudflare Workers©Build your next application with Cloudflare Workers

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.

llms-txtThe /llms.txt file – llms-txtA proposal to standardise on using an /llms.txt file to provide information to help LLMs use a website at inference time.

#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! 🚀

Continued thread

🎉 #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:

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!

unstable.fedify.devKey–value store | FedifyFedify docs

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!

fedify.devCreating your own federated microblog | FedifyIn this tutorial, we will build a small microblog that implements the ActivityPub protocol, similar to Mastodon or Misskey, using Fedify, an ActivityPub server framework.

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.

RE: mastodon.social/@reiver/114590

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, documentation
  • component/ for different parts of Fedify
  • activitypub/ 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.

Problem Currently, the Fedify repository uses GitHub's default labels, which don't reflect the specific needs and structure of the Fedify project. These generic labels make it difficult to: Categor...
GitHubReorganize repository labels to better fit Fedify project structure · Issue #238 · fedify-dev/fedifyBy dahlia

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:

  • Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
  • Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
  • Thoroughly discussed within the Fedify community (Discord, Matrix, GitHub Discussions)

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.

Summary card of repository fediverse/fep
Codeberg.orgfepFediverse Enhancement Proposals

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!

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?

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.

graphql.orgGraphQL | A query language for your API

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:

  • has implemented RFC 9421 (even in a development branch)
  • is currently implementing it
  • has plans to implement it soon

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! 🙏

hollo.socialWe're excited to announce that…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][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! #fedidev [RFC 9421]: https://www.rfc-editor.org/rfc/rfc9421 [double-knocking]: https://swicg.github.io/activitypub-http-signature/#how-to-upgrade-supported-versions [draft cavage]: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12 [branch]: https://github.com/fedify-dev/fedify/tree/rfc9421

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!