<p>Just opened an issue for a major new task for <a href="/tags/fedify/" rel="tag">#Fedify</a>: building an <a href="/tags/interoperability/" rel="tag">#interoperability</a> smoke test suite.</p><p>To ensure Fedify-built servers federate correctly with the wider <a href="/tags/fediverse/" rel="tag">#fediverse</a>, we're planning to run automated E2E tests in <a href="/tags/ci/" rel="tag">#CI</a> against live instances of Mastodon, Misskey, and more. This is crucial for a framework's reliability.</p><p>You can see the full plan and discussion here:</p><p><a href="https://github.com/fedify-dev/fedify/issues/481" rel="nofollow" class="ellipsis" title="github.com/fedify-dev/fedify/issues/481"><span class="invisible">https://</span><span class="ellipsis">github.com/fedify-dev/fedify/i</span><span class="invisible">ssues/481</span></a></p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
fedify
<p>While working on <a href="/tags/fedify/" rel="tag">#Fedify</a>, I noticed something about how <a href="/tags/misskey/" rel="tag">#Misskey</a> handles <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> 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.</p><p><a href="/tags/mastodon/" rel="tag">#Mastodon</a> takes a different approach—when <a href="/tags/authorized_fetch/" rel="tag">#authorized_fetch</a> 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?</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
<p>🎉 Excited to announce that <a href="/tags/fedify/" rel="tag">#Fedify</a> is now on Open Collective! Support the project's development starting at:</p><p>Backer (from $5/mo)<br>Supporter (from $25/mo)<br>Sponsor (from $100/mo)<br>Corporate Sponsor (from $500/mo)<br>Custom donations welcome</p><p>Your support will help us maintain and improve Fedify. Check it out here:</p><p><a href="https://opencollective.com/fedify" rel="nofollow"><span class="invisible">https://</span>opencollective.com/fedify</a></p><p><img src="https://neodb.social/media/emoji/hollo.social/fedify.png" class="emoji" alt=":fedify:" title=":fedify:"></p><p><a href="/tags/opencollective/" rel="tag">#OpenCollective</a> <a href="/tags/support/" rel="tag">#support</a> <a href="/tags/backing/" rel="tag">#backing</a> <a href="/tags/sponsor/" rel="tag">#sponsor</a> <a href="/tags/donation/" rel="tag">#donation</a></p>
<p>Hi <a href="/tags/fediverse/" rel="tag">#fediverse</a> and <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> developers!</p><p>I'm currently working on interoperability testing for <a href="/tags/hollo/" rel="tag">#Hollo</a> and <a href="/tags/fedify/" rel="tag">#Fedify</a>, and I need a <a href="/tags/bonfire/" rel="tag">#Bonfire</a> account to test federation with their implementation.</p><p>Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/bonfirenetworks/" rel="tag">#BonfireNetworks</a></p>
<p>Started laying out a rough plan for implementing FEP-ef61: Portable Objects in <a href="/tags/fedify/" rel="tag">#Fedify</a>—server-independent <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> identities backed by <a href="/tags/dids/" rel="tag">#DIDs</a>, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.</p><p><a href="https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585" rel="nofollow" class="ellipsis" title="github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585"><span class="invisible">https://</span><span class="ellipsis">github.com/fedify-dev/fedify/i</span><span class="invisible">ssues/288#issuecomment-3971459585</span></a></p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/fediverse/" rel="tag">#fediverse</a> <a href="/tags/portableobjects/" rel="tag">#PortableObjects</a></p>
<p>When I first started working with <a href="/tags/activitypub/" rel="tag">#ActivityPub</a>, before <a href="/tags/fedify/" rel="tag">#Fedify</a> existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even exciting—but never comfortable. That era where your business logic and your protocol plumbing were just… the same thing:</p><p>print "HTTP/1.1 200 OK"print "Content-Type: text/html"printprint "Hello, world!"</p><p>Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.</p><p>ActivityPub development still feels like they are your problem. What do you do when the <a href="https://www.w3.org/ns/activitystreams#actor" rel="nofollow" class="ellipsis" title="www.w3.org/ns/activitystreams#actor"><span class="invisible">https://</span><span class="ellipsis">www.w3.org/ns/activitystreams#</span><span class="invisible">actor</span></a> property comes in as a string instead of an array? What about when <a href="https://www.w3.org/ns/activitystreams#object" rel="nofollow" class="ellipsis" title="www.w3.org/ns/activitystreams#object"><span class="invisible">https://</span><span class="ellipsis">www.w3.org/ns/activitystreams#</span><span class="invisible">object</span></a> is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And wait—what's Linked Data Signatures, and do you need that too?</p><p>The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows it—every edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.</p><p>What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you just… build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/fediverse/" rel="tag">#fediverse</a></p>
<p>I've been thinking about adding federation health monitoring to <a href="/tags/fedify/" rel="tag">#Fedify</a>—not as a separate data store or custom API, but by extending the existing <a href="/tags/opentelemetry/" rel="tag">#OpenTelemetry</a> integration. The idea is to expose delivery outcomes, signature verification failures, and per-remote-host error rates as OpenTelemetry metrics alongside the spans Fedify already emits. If you already have a Prometheus or Grafana setup, you'd get federation observability basically for free. Circuit breaker behavior (temporarily skipping a remote server that's been consistently unreachable) could surface as OpenTelemetry events, keeping everything in the same trace context rather than scattered across separate logs.</p><p>Does this sound useful to you? I'm curious whether people building on Fedify—or running federated servers in general—would actually reach for this, and what kinds of things you'd most want to observe. Happy to hear any thoughts.</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a></p>
<p>So, an interesting issue came up in the <a href="/tags/fedify/" rel="tag">#Fedify</a> repo that I've been thinking about: <a href="/tags/629/" rel="tag">#629</a>.</p><p>You know how every <a href="/tags/fediverse/" rel="tag">#fediverse</a> server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict <a href="/tags/as2/" rel="tag">#AS2</a> validators like <a href="https://browser.pub/" rel="nofollow">browser.pub</a> reject it, because the AS2 spec says attachment should only contain Object or Link—and <a href="https://docs.joinmastodon.org/spec/activitypub/#schema" rel="nofollow">PropertyValue is a schema.org type</a>, not an Activity Streams 2.0 type.</p><p>The thing is, we can't just drop the type like we did with Endpoints (<a href="/tags/576/" rel="tag">#576</a>), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.</p><p>I'm leaning towards writing a <a href="/tags/fep/" rel="tag">#FEP</a> to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.</p><p>What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/activitystreams/" rel="tag">#ActivityStreams</a> <a href="/tags/activitystreams2/" rel="tag">#ActivityStreams2</a> <a href="/tags/as2/" rel="tag">#AS2</a> <a href="/tags/propertyvalue/" rel="tag">#PropertyValue</a></p>
<p>What just <a href="https://github.com/rmdes/indiekit-endpoint-activitypub/blob/main/README.md" rel="nofollow">shipped</a> in 3.10.0:</p><p>Fedify 2.1.0 (RFC 9421 signatures, onUnverifiedActivity, GoToSocial fix)<br>Removed as:Endpoints workaround (6 fewer lines of patching)<br>FEP-5feb: indexable + discoverable on actor<br>FEP-f1d5: Rich NodeInfo (visible in the curl output above)<br>FEP-4f05: Tombstone responses for deleted posts<br>FEP-3b86: Activity Intent links in WebFinger for remote interactions<br>FEP-8fcf: Outbound collection sync (was already there, now documented)<br>Unverified Delete handler for orphaned actors</p><p>🔗 <a href="https://rmendes.net/notes/2026/03/26/83043" rel="nofollow" class="ellipsis" title="rmendes.net/notes/2026/03/26/83043"><span class="invisible">https://</span><span class="ellipsis">rmendes.net/notes/2026/03/26/8</span><span class="invisible">3043</span></a></p>