Did you know there's a community space for #Fedify, #Hollo, #BotKit, and other Fedify ecosystem projects?
Whether you have questions, want to share what you're building, or just want to hang out with fellow fediverse developers—come join us!
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
@hongminhee it's no biggie - I doubt there's many projects that accept and thread correctly for this corner case - I just like to use this conversation as a test for threading. :D
Btw, I don't know if it's relevant to #fedify but I have the logic for threading (based on JWZ's old email threading algorithm) in the ONI project: https://git.sr.ht/~mariusor/oni/tree/master/item/src/js/items-threading.js
Thanks all for listening to my talk about #Fedify at #FOSDEM 2026 today! Here's my deck for the talk: Fedify: Building ActivityPub servers without the pain.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
After months of struggling with the “zombie post” issue on Hackers' Pub—where deleted posts wouldn't disappear from remote servers—I had a sudden hypothesis today. As I dug into it, I realized it's a structural issue with Fedify's MessageQueue system: Create(Note) and Delete(Note) activities can be delivered out of order, causing remote instances to receive Delete(Note) before Create(Note).
The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.
Fedifyを開発していて気づいたことなんですが、MisskeyのActivityPubオブジェクトへのアクセス処理について少し疑問があります。リモートサーバーから、アクセス権限のあるアクターの有効なHTTP Signaturesを含むリクエストでフォロワー限定投稿やDMにアクセスしようとしても、Misskeyは内容を返さずに404を返すようです。どうやらMisskeyはHTTP Signaturesを検証せず、visibilityフィールド（publicとhome）だけを確認しているようです。
Mastodonの場合、authorized fetchを有効にすると、HTTP Signaturesを検証して、リクエストしているアクターに権限があれば内容を返します。MisskeyもMastodonのような仕組みを採用してくれたら、ActivityPubが意図しているアクセス制御のセマンティクスをより適切に尊重できるんじゃないかと思います。他の方も同じようなことに気づかれたことはありますか？それとも、Misskeyがこのような処理をしている特別な理由があるのでしょうか？
#Fedify #Misskey #ActivityPub #Mastodon #authorized_fetch #fedidev
While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all.
#Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way?
Fedify 1.10.0: Observability foundations for the future debug dashboard
Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.
We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications.
This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface.
Enhanced OpenTelemetry instrumentation
Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values.
The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations:
activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor informationactivitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URLactivitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representationAdditionally, Fedify now instruments previously uncovered operations:
activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLsactivitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method usedThese instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo.
Distributed trace storage with FedifySpanExporter
Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers.
The new @fedify/fedify/otel module provides the following types and interfaces:
import { MemoryKvStore } from "@fedify/fedify";
import { FedifySpanExporter } from "@fedify/fedify/otel";
import {
BasicTracerProvider,
SimpleSpanProcessor,
} from "@opentelemetry/sdk-trace-base";
const kv = new MemoryKvStore();
const exporter = new FedifySpanExporter(kv, {
ttl: Temporal.Duration.from({ hours: 1 }),
});
const provider = new BasicTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(exporter));The stored traces can be queried for display in debugging interfaces:
// Get all activities for a specific trace
const activities = await exporter.getActivitiesByTraceId(traceId);
// Get recent traces with summary information
const recentTraces = await exporter.getRecentTraces({ limit: 100 });The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace.
This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234.
Optional list() method for KvStore interface
Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries.
interface KvStore {
// ... existing methods
list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>;
}When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method:
MemoryKvStore — filters in-memory keys by prefixSqliteKvStore — uses LIKE query with JSON key patternPostgresKvStore — uses array slice comparisonRedisKvStore — uses SCAN with pattern matching and key deserializationDenoKvStore — delegates to Deno KV's built-in list() APIWorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix patternWhile list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle.
The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers.
NestJS 11 and Express 5 support
Thanks to a contribution from Cho Hasang (@crohasang), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4.
This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications.
What's next
Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available.
The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release.
Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies.
Acknowledgments
Special thanks to Cho Hasang (@crohasang) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features.
For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.
According to @tchambers's My 2026 Open Social Web Predictions:
Fedify will power the federation layer for at least one mid-sized social platform (500K+ users) that adds ActivityPub support in 2026. The “build vs. buy” calculation for federation shifts decisively toward “just use Fedify.”
We're honored by this recognition and will keep working hard to make #ActivityPub adoption easier for everyone. Thank you, Tim!
🔒 Security Release: BotKit 0.3.1
We've released BotKit 0.3.1 with an important security fix.
This update addresses CVE-2025-68475 (High severity, CVSS 7.5), a ReDoS vulnerability in Fedify's HTML parsing that could cause denial of service.
If you're using BotKit 0.3.x, please upgrade to 0.3.1 as soon as possible.
🚨 Security Advisory: CVE-2025-68475
A ReDoS (Regular Expression Denial of Service) vulnerability has been discovered in Fedify's HTML parsing code. This vulnerability could allow a malicious federated server to cause denial of service by sending specially crafted HTML responses.
CVE ID CVE-2025-68475 Severity High (CVSS 7.5) Affected versions ≤1.9.1 Patched versions 1.6.13, 1.7.14, 1.8.15, 1.9.2If you're running Fedify in production, please upgrade to one of the patched versions immediately.
For full details, see the security advisory: https://github.com/fedify-dev/fedify/security/advisories/GHSA-rchf-xwx2-hm93
Thank you to Yue (Knox) Liu for responsibly reporting this vulnerability.
Now i'm curious about my "Tooting age?" #WTF #mastodon #wrapstodon #fedify
https://mastodon.social/@counivers/wrapstodon/2025/c8c021a44f1bb116
BotKitは、ActivityPubボットを作るためのTypeScriptフレームワークです。既存のMastodon/Misskeyボットとの違いは、ボット自体が独立したサーバーとして動作すること。プラットフォームのアカウントは不要です。
文字数制限もなければ、APIレート制限に悩まされることもありません。
bot.onMention = async (session, message) => {
await message.reply(text`こんにちは、${message.actor}さん！`);
};フェデレーション、HTTP Signatures、配送キューといったActivityPub周りの処理はFedifyがすべて引き受けます。ボットのロジックを書くだけです。
DenoでもNode.jsでも動きます。
BotKit은 ActivityPub 봇을 만드는 #TypeScript 프레임워크입니다. 일반적인 Mastodon/Misskey 봇과 다른 점은, 봇 자체가 독립된 서버로 돌아간다는 겁니다. 플랫폼 계정이 필요 없습니다.
글자 수 제한도 없고, API 호출 제한에 시달릴 일도 없습니다.
bot.onMention = async (session, message) => {
await message.reply(text`안녕하세요, ${message.actor}님!`);
};연합(federation), HTTP Signatures, 메시지 전달 같은 #ActivityPub 관련 처리는 Fedify가 알아서 해줍니다. 봇 로직만 짜면 되는 거죠.
#BotKit is a #TypeScript framework for building #ActivityPub bots. The difference from typical Mastodon/Misskey bots? Your bot runs as its own independent server—no platform account needed.
This means no character limits, no rate limiting headaches, no API restrictions.
bot.onMention = async (session, message) => {
await message.reply(text`Hi, ${message.actor}!`);
};The ActivityPub stuff (federation, HTTP Signatures, delivery queues) is handled by #Fedify under the hood. You just write your bot logic.
A while back I mentioned the idea of “Fedify Studio”—a web-based toolkit for #ActivityPub debugging and development. I've been quietly working on shaping that idea into something more concrete.
Nothing to announce yet, but it's looking like this might become a team effort rather than a solo project, which would be nice. We'll see how it goes.
It's alive! 🧟
After a bit of trial-error, got fediverse comments showing on a #nextjs site running #fedify. My personal fediverse-connected youtube mirror is now mostly feature complete.
(The video post in the screenshot is over here: https://watch.hayes.software/video/16)
#fediverse
Just opened an issue for a major new task for #Fedify: building an #interoperability smoke test suite.
To ensure Fedify-built servers federate correctly with the wider #fediverse, we're planning to run automated E2E tests in #CI against live instances of Mastodon, Misskey, and more. This is crucial for a framework's reliability.
You can see the full plan and discussion here:
