Cryptographic public-keys are one way that one can have an identity (on the Fediverse, and elsewhere) while also having privacy — through a pseudonymous identity.

Yes, we have Fediverse IDs such as:

＠joeblow＠example.com

But a (non-delegated) public-key can function as a PORTABLE form of identity on the Fediverse.

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

I will be at FOSDEM 2026 — for the Social Web track.

https://fosdem.org/2026/schedule/track/social-web/

In Brussels on Saturday January 31st & Sunday February 1st.

See you there?

#FediDev #FediDevs #Fediverse #FOSDEM #FOSDEM2026 #SocialWeb #SocialWebFOSDEM #SocialWebFOSDEM2026

with all the meta about the new social network called W going on I thought it was funny I just discovered a new flavor of #fediverse server at https://z.org. Looks like its author @maxfield got federation working last month and they named the software #Elektrine
#fedidev

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but — I do recognize that it can be empowering to non-programmers

https://mastodon.social/@reiver/115639716286184653

...

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but — I do recognize that it can be empowering to non-programmers

https://mastodon.social/@reiver/115639716286184653

...

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

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?

#fedidev

Cryptographic public-keys are one way that one can have an identity (on the Fediverse, and elsewhere) while also having privacy — through a pseudonymous identity.

Yes, we have Fediverse IDs such as:

＠joeblow＠example.com

But a (non-delegated) public-key can function as a PORTABLE form of identity on the Fediverse.

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

Cryptographic public-keys are one way that one can have an identity (on the Fediverse, and elsewhere) while also having privacy — through a pseudonymous identity.

Yes, we have Fediverse IDs such as:

＠joeblow＠example.com

But a (non-delegated) public-key can function as a PORTABLE form of identity on the Fediverse.

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

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?

#fedidev

3/

All that requires that a Fediverse user can have multiple public-keys specified for them.

...

Although https://w3id.org/security/v1 seems to allow for multiple public-keys —

I wonder how much Fediverse software could actually handle multiple public-keys (rather than just one)?

(And, don't just assume one public-key?)

How mucg Fediverse software could handle public-keys changing over time?

Etc?

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

2/

To handle public-key cryptography safely, often a user should be able to have multiple public-keys.

For example, a user might have a different public-key on each device, rather than sharing public-keys.

A user might delegate to a 3rd party — and there may be a delegated versus non-delegated public-key distinction.

Key-rotation is also often necessary for safety reasons.

Etc.

...

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

1/

One way ActivityPub can be extended is — through JSON-LD namespaces.

For example, many Fediverse servers use the following JSON-LD namespace to specify cryptographic public-key(s) for the user.

https://w3id.org/security/v1

(This particular namespace is an HTTPS URL.)

...

But, does extant Fediverse software support cryptographic public-key(s) well?

...

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

3/

All that requires that a Fediverse user can have multiple public-keys specified for them.

...

Although https://w3id.org/security/v1 seems to allow for multiple public-keys —

I wonder how much Fediverse software could actually handle multiple public-keys (rather than just one)?

(And, don't just assume one public-key?)

How mucg Fediverse software could handle public-keys changing over time?

Etc?

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

3/

All that requires that a Fediverse user can have multiple public-keys specified for them.

...

Although https://w3id.org/security/v1 seems to allow for multiple public-keys —

I wonder how much Fediverse software could actually handle multiple public-keys (rather than just one)?

(And, don't just assume one public-key?)

How mucg Fediverse software could handle public-keys changing over time?

Etc?

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

2/

To handle public-key cryptography safely, often a user should be able to have multiple public-keys.

For example, a user might have a different public-key on each device, rather than sharing public-keys.

A user might delegate to a 3rd party — and there may be a delegated versus non-delegated public-key distinction.

Key-rotation is also often necessary for safety reasons.

Etc.

...

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

1/

One way ActivityPub can be extended is — through JSON-LD namespaces.

For example, many Fediverse servers use the following JSON-LD namespace to specify cryptographic public-key(s) for the user.

https://w3id.org/security/v1

(This particular namespace is an HTTPS URL.)

...

But, does extant Fediverse software support cryptographic public-key(s) well?

...

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

1/

One way ActivityPub can be extended is — through JSON-LD namespaces.

For example, many Fediverse servers use the following JSON-LD namespace to specify cryptographic public-key(s) for the user.

https://w3id.org/security/v1

(This particular namespace is an HTTPS URL.)

...

But, does extant Fediverse software support cryptographic public-key(s) well?

...

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD

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?

#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?

#fedidev

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

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

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

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?

#fedidev

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?

#fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

with all the meta about the new social network called W going on I thought it was funny I just discovered a new flavor of #fediverse server at https://z.org. Looks like its author @maxfield got federation working last month and they named the software #Elektrine
#fedidev

with all the meta about the new social network called W going on I thought it was funny I just discovered a new flavor of #fediverse server at https://z.org. Looks like its author @maxfield got federation working last month and they named the software #Elektrine
#fedidev

RE: https://varese.social/@emanuelecariati/115705909561429573

André Menrath (@linos) did a great talk called [Interoperability of Events in the Fediverse] that I only just now got a chance to watch. This is an area of the #fediverse that really doesn't get enough attention, and the work that André is doing with https://event-federation.eu is super excellent.

Anyway watch the presentation here https://vimeo.com/1137648835 and let's get events fully federating with all their depth and nuance intact!
#fediverse #fedidev

RE: https://varese.social/@emanuelecariati/115705909561429573

André Menrath (@linos) did a great talk called [Interoperability of Events in the Fediverse] that I only just now got a chance to watch. This is an area of the #fediverse that really doesn't get enough attention, and the work that André is doing with https://event-federation.eu is super excellent.

Anyway watch the presentation here https://vimeo.com/1137648835 and let's get events fully federating with all their depth and nuance intact!
#fediverse #fedidev

@elaine is building a new #fediverse server called #EchoCrate
https://ap.elaine.is/users/elaine/statuses/mkk63yzyftt9q0uznij
#ActivityPub #fedidev

RE: https://theforkiverse.com/@klemens/115915313316598172

this person is working on a mac app specifically for #theforkiverse
#fedidev

RE: https://theforkiverse.com/@klemens/115915313316598172

this person is working on a mac app specifically for #theforkiverse
#fedidev

So what’s the ActivityPub version of Pinterest? Looks like it will be in demand soon.

https://www.socialmediatoday.com/news/reports-suggest-that-openai-may-be-looking-to-acquire-pinterest/808773/

#Pinterest #ActivityPub #FediDev

So what’s the ActivityPub version of Pinterest? Looks like it will be in demand soon.

https://www.socialmediatoday.com/news/reports-suggest-that-openai-may-be-looking-to-acquire-pinterest/808773/

#Pinterest #ActivityPub #FediDev

So what’s the ActivityPub version of Pinterest? Looks like it will be in demand soon.

https://www.socialmediatoday.com/news/reports-suggest-that-openai-may-be-looking-to-acquire-pinterest/808773/

#Pinterest #ActivityPub #FediDev

So what’s the ActivityPub version of Pinterest? Looks like it will be in demand soon.

https://www.socialmediatoday.com/news/reports-suggest-that-openai-may-be-looking-to-acquire-pinterest/808773/

#Pinterest #ActivityPub #FediDev

So what’s the ActivityPub version of Pinterest? Looks like it will be in demand soon.

https://www.socialmediatoday.com/news/reports-suggest-that-openai-may-be-looking-to-acquire-pinterest/808773/

#Pinterest #ActivityPub #FediDev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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!

#fedidev

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!

#fedidev

If you'd like to support the development of @fedify or @hollo or @botkit, you can sponsor me on GitHub!

https://github.com/sponsors/dahlia

#ActivityPub #fedidev #Fedify #Hollo #BotKit #sponsor

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

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 information
• activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL
• activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation

Additionally, Fedify now instruments previously uncovered operations:

• activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs
• activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used

These 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 prefix
• SqliteKvStore — uses LIKE query with JSON key pattern
• PostgresKvStore — uses array slice comparison
• RedisKvStore — uses SCAN with pattern matching and key deserialization
• DenoKvStore — delegates to Deno KV's built-in list() API
• WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern

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

#fedidev #release

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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!

#Fedify #fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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!

#Fedify #fediverse #fedidev

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

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

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

#Fedify #ActivityPub #security #fediverse #fedidev

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

Calling all #fediverse developers for help: I'm currently trying to implement a #reporting (#flag) feature for Hackers' Pub, an #ActivityPub-enabled community for software engineers. Is there a formal specification for how cross-instance reporting should work in ActivityPub? Or, is there any well-documented material that explains how the major implementations handle it?

#fedidev #mastodev #askfedi

I will be at FOSDEM 2026 — for the Social Web track.

https://fosdem.org/2026/schedule/track/social-web/

In Brussels on Saturday January 31st & Sunday February 1st.

See you there?

#FediDev #FediDevs #Fediverse #FOSDEM #FOSDEM2026 #SocialWeb #SocialWebFOSDEM #SocialWebFOSDEM2026

I will be at FOSDEM 2026 — for the Social Web track.

https://fosdem.org/2026/schedule/track/social-web/

In Brussels on Saturday January 31st & Sunday February 1st.

See you there?

#FediDev #FediDevs #Fediverse #FOSDEM #FOSDEM2026 #SocialWeb #SocialWebFOSDEM #SocialWebFOSDEM2026

How many Fediverse software use Markdown as its default text format — rather than HTML?

I think both PeerTube and Lemmy are Markdown native — rather than HTML.

Anything else?

#FediDev #FediDevs #Fediverse #Markdown

How many Fediverse software use Markdown as its default text format — rather than HTML?

I think both PeerTube and Lemmy are Markdown native — rather than HTML.

Anything else?

#FediDev #FediDevs #Fediverse #Markdown

One person's request for Fediverse applications —

Alex wants to be able to choose what the preview image is for a video, chosen from the frames in the video.

...

I can imagine editing tools (in Fediverse applications) would also be useful.

It is also common elsewhere for people to be able to use custom images for preview images.

#FediDev #FediDevs #FediUX #Fediverse #FediverseUX #PreviewImage #Video

What one person wants from an alternative to a Twitter:

• choice of home-feed algorithm,
• editable posts,
• ability to moderate replies

RE: https://x.com/Plinz/status/1685945305320329216

#FediDev #FediDevs #FediUX #Fediverse #FediverseUX

9/

[Fediverse BackUp]

So, I think an (ActivityPub / ActivityStreams) Activity File COULD be a "good" format for backing-up a single post on the Fediverse, but —

Most (maybe all) extant Fediverse software would need to change a bit. Fediverse software would need to support embedding "everything" in a single Activity File (rather than referring to "everything" else by URLs).

.

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

8/

[Fediverse BackUp]

Also — what about comments / replies —

Someone people (including me) would want at least some of the comments / replies to be included in a BackUp for a post.

So, for an Activity File to be a "good" format for a BackUp, a single Activity File would also need to contain (all or selected) the comments / replies to the post.

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

1/

[Fediverse BackUp]

Could an ActivityPub / ActivityStreams file be a "good" format for backing up a post?

(I.e., what I call an "Activity File". I.e., the file that has a media-type of "application/activity+json".)

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

7/

[Fediverse BackUp]

Also — we would need to consider Threads / Storms —

Where people reply to their own post to make a larger post made up of smaller posts.

(I.e., what I have been doing here 🙂 )

For an Activity File to be a "good" format for a BackUp, a single Activity File would need to contain all the posts in the Thread / Storm.

Also —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

6/

[Fediverse BackUp]

Also — we would need to consider Threads / Storms —

Where people reply to their own post to make a larger post made up of smaller posts.

(I.e., what I have been doing here 🙂 )

for an Activity File to be a "good" format for a BackUp, a single Activity File would need to contain all the posts in the Thread / Storm.

Also —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

5/

[Fediverse BackUp]

But — for an Activity File to be a "good" format for a BackUp, there would need to be a way to get the Fediverse software to embed the (non-text) media (such as images, audio, video, etc) into an Activity File.

Also —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

5/

[Fediverse BackUp]

But — for an Activity File to be a "good" format for a BackUp, there would need to be a way to get the Fediverse software to embed the (non-text) media (such as images, audio, video, etc) into an Activity File.

Also —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

4/

[Fediverse BackUp]

Now, having said that, I don't think there is anything about ActivityPub / ActivityStreams that "prevents" Fediverse software from not embedding (non-text) media (such as images, audio, video, etc) into an Activity File —

For example, an "Image" Object can contain a ("mediaType" and a) "content" field (rather than an "href" field).

But —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

4/

[Fediverse BackUp]

Now, having said that, I don't think there is anything about ActivityPub / ActivityStreams that "prevents" Fediverse software from not embedding (non-text) media (such as images, audio, video, etc) into an Activity File —

For example, an "Image" Object can contain a ("mediaType" and a) "content" field (rather than an "href" field).

But —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

3/

[Fediverse BackUp]

If you wanted to BackUp a post on the Fediverse, and all you download was the Activity File (with URLs pointing to the non-text media), then — you lost all the (non-text) media (such as images, audio, video, etc) that were part of the post.

Which would be bad.

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

3/

[Fediverse BackUp]

If you wanted to BackUp a post on the Fediverse, and all you download was the Activity File (with URLs pointing to the non-text media), then — you lost all the (non-text) media (such as images, audio, video, etc) that were part of the post.

Which would be bad.

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

2/

[Fediverse BackUp]

I think one challenge, in practice, with using an Activity File as a BackUp Format is that — a lot of Fediverse software does NOT embed (non-text) media (such images, audio, video, etc) in the Activity File.

But, instead references them using URLs.

(And, by "URL" I mean "URI", "IRI", etc.)

Usually this is probably a good thing, but —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

2/

[Fediverse BackUp]

I think one challenge, in practice, with using an Activity File as a BackUp Format is that — a lot of Fediverse software does NOT embed (non-text) media (such images, audio, video, etc) in the Activity File.

But, instead references them using URLs.

(And, by "URL" I mean "URI", "IRI", etc.)

Usually this is probably a good thing, but —

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

1/

[Fediverse BackUp]

Could an ActivityPub / ActivityStreams file be a "good" format for backing up a post?

(I.e., what I call an "Activity File". I.e., the file that has a media-type of "application/activity+json".)

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

1/

[Fediverse BackUp]

Could an ActivityPub / ActivityStreams file be a "good" format for backing up a post?

(I.e., what I call an "Activity File". I.e., the file that has a media-type of "application/activity+json".)

...

#ActivityPub #ActivityStreams #BackUp #BackUps #FediBackUp #FediDev #FediDevs #Fediverse

This is an area I think we could improve on the Fediverse —

Nested Comments

This (in the attached screen-shot) is from someone on Twitter who is also on Mastodon and Bluesky.

He seems to be a fan of the nested comments UI on Bluesky.

We have some great applications on the Fediverse. They could be made even greater with this improvement.

#FediUX #Fediverse #FediDev #FediDevs #FediverseUX

3/

[Fediverse CDN]

Once you have Fediverse Caching servers — you have the basis to create a Fediverse content-distribution-network (CDN).

A (Fediverse-native) Fediverse content-distribution-network (CDN) could bring a new level of robustness and scalability to the Fediverse — while still maintaining the properties of decentralization, federation, and localization.

#CDN #ContentDeliveryNetwork #ContentDistributionNetwork #FediCDN #FediDev #FediDevs #Fediverse

2/

[Fediverse CDN]

One way to increase the robustness of the Fediverse is — to introduce the concept of a Fediverse Caching server.

It (the Fediverse Cachine server) caches stuff from the Fediverse rather than the regular Fediverse servers (that house local users and local content).

...

#CDN #ContentDeliveryNetwork #ContentDistributionNetwork #FediCDN #FediDev #FediDevs #Fediverse

RE: https://mastodon.social/@reiver/114009413139340907

1/

[Fediverse CDN]

One thing that crashes Fediverse servers (maybe the most) is — caching.

And, in particular, their storage drivers filling up (due to caching), which crashes the server.

Fediverse servers cache profiles, posts, images, and other servers on the Fediverse.

...

#CDN #ContentDeliveryNetwork #ContentDistributionNetwork #FediCDN #FediDev #FediDevs #Fediverse

User profiles, posts, images, and other content is cached across the various servers on the Fediverse.

Conceptually, software could access any of that from any server that cached it (and not just the origin server).

You could have a type of Fediverse content-distribution-network (CDN) if you did.

#CDN #ContentDeliveryNetwork #ContentDistributionNetwork #DeSo #FediCDN #FediDev #FediDevs #Fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

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.

#Fedify #fedidev #fediverse

I forgot how tedious it is to chase code coverage when writing tests.

However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.

So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.

I hope I can reuse some of the test logic in the other backends, as they need to perform identically.

#go #ActivityPub #fedidev

I forgot how tedious it is to chase code coverage when writing tests.

However this was part of the reason that made me include the "boring" parts of building a robust library into the goals set for the #nlnet grant.

So after a couple of days of work I finally got the first of the storage backends for the #GoActivityPub library go past 80% test coverage.

I hope I can reuse some of the test logic in the other backends, as they need to perform identically.

#go #ActivityPub #fedidev

In the past I've coded lots of things for blocking various things, which is all about excluding what we don't want.

I'm finding it much harder to think of ways to attract and promote things we DO want.

In an ideal utopia we'd be making social media that makes people feel better. Not neutral or the same as before and certainly not worse than before. I don't think we can get there by excluding bad things, we need to be including/nurturing/promoting good things too.

#fediverse #fedidev

RE: https://fietkau.software/daily_rucks/ap/activity/2025-11-08

I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot. You can now quote post the daily voice lines as much as you want! 🥳

This would be noteworthy on its own if there weren't already a bunch of non-Mastodon implementations, but I'm actually late to the party. WordPress, Bonfire, micro.blog, dotmakeup, and ActivityBot all got there before I did.

However, I think my approach is novel for being *stateless*. Thread incoming.

🧵 1/6

#Fediverse #FediDev #ActivityPub

RE: https://fietkau.software/daily_rucks/ap/activity/2025-11-08

I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot. You can now quote post the daily voice lines as much as you want! 🥳

This would be noteworthy on its own if there weren't already a bunch of non-Mastodon implementations, but I'm actually late to the party. WordPress, Bonfire, micro.blog, dotmakeup, and ActivityBot all got there before I did.

However, I think my approach is novel for being *stateless*. Thread incoming.

🧵 1/6

#Fediverse #FediDev #ActivityPub

RE: https://fietkau.software/daily_rucks/ap/activity/2025-11-08

I have added Mastodon-style (FEP-044f) quote post compatibility to my @DailyRucks bot. You can now quote post the daily voice lines as much as you want! 🥳

This would be noteworthy on its own if there weren't already a bunch of non-Mastodon implementations, but I'm actually late to the party. WordPress, Bonfire, micro.blog, dotmakeup, and ActivityBot all got there before I did.

However, I think my approach is novel for being *stateless*. Thread incoming.

🧵 1/6

#Fediverse #FediDev #ActivityPub

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

In the past I've coded lots of things for blocking various things, which is all about excluding what we don't want.

I'm finding it much harder to think of ways to attract and promote things we DO want.

In an ideal utopia we'd be making social media that makes people feel better. Not neutral or the same as before and certainly not worse than before. I don't think we can get there by excluding bad things, we need to be including/nurturing/promoting good things too.

#fediverse #fedidev

@bonfire have just released Bonfire v1.0 (big congratulations! 🥳) and are crowdfunding further development. Go help them out if you can!

I think the tools Bonfire offers are brilliant for both personal and institutional users alike, and will only strengthen the Fediverse.

https://www.indiegogo.com/en/projects/bonfire/community #fedidev #fediverse #Bonfire

@bonfire have just released Bonfire v1.0 (big congratulations! 🥳) and are crowdfunding further development. Go help them out if you can!

I think the tools Bonfire offers are brilliant for both personal and institutional users alike, and will only strengthen the Fediverse.

https://www.indiegogo.com/en/projects/bonfire/community #fedidev #fediverse #Bonfire

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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:

https://github.com/fedify-dev/fedify/issues/481

#ActivityPub #fedidev

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.