<p>Mentioned by <span class="h-card"><a href="https://macaw.social/@andypiper" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>andypiper</span></a></span> :</p><p>The Mastodon team is planning to release a universal "share" button.</p><p>(It wasn't clear to me if this was just for Mastodon servers — or if it would work with non-Mastodon servers, too. It was mentioned briefly from the audience.)</p><p><a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/fedidevs/" rel="tag">#FediDevs</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/fosdem/" rel="tag">#FOSDEM</a> <a href="/tags/fosdem2026/" rel="tag">#FOSDEM2026</a> <a href="/tags/socialweb/" rel="tag">#SocialWeb</a> <a href="/tags/socialwebfosdem/" rel="tag">#SocialWebFOSDEM</a> <a href="/tags/socialwebfosdem2026/" rel="tag">#SocialWebFOSDEM2026</a> <a href="/tags/mastodon/" rel="tag">#Mastodon</a></p>
Edited 65d ago
<p>I dream of being able to store my online social presence, identity, and history just as — an (organized) set of static files.</p><p>A set that I control.</p><p>And, I can (if I want to) host myself. (I.e., I am the "source of truth" / "origin" for my files.)</p><p>RE: <a href="https://mastodon.social/@reiver/116018261922778583" rel="nofollow" class="ellipsis" title="mastodon.social/@reiver/116018261922778583"><span class="invisible">https://</span><span class="ellipsis">mastodon.social/@reiver/116018</span><span class="invisible">261922778583</span></a></p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/fedidevs/" rel="tag">#FediDevs</a> <a href="/tags/fediux/" rel="tag">#FediUX</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/fediverseux/" rel="tag">#FediverseUX</a></p>
<p>MastoAPI Enhancement Proposals? I'd like to hear some opinions about the idea.</p><p><a href="https://maep.fediverse.pl/issues/1" rel="nofollow"><span class="invisible">https://</span>maep.fediverse.pl/issues/1</a></p><p><a href="/tags/fedidev/" rel="tag">#FediDev</a></p>
<p>Today <span class="h-card"><a href="https://pl.fediverse.pl/users/mkljczk" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>mkljczk</span></a></span> introduced a proposal for MAEPs (Mastodon API Enhancement Proposals) which would be similar to the FEP process but for converging on API schema for servers that are not Mastodon but who are using the Mastodon client API<br><a href="https://codeberg.org/fediverse-pl/maep/issues/1" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse-pl/maep/issues/1"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse-pl/maep</span><span class="invisible">/issues/1</span></a><br><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/fediverse/" rel="tag">#fediverse</a> <a href="/tags/maeps/" rel="tag">#MAEPs</a></p>
<p>came across a thread by <span class="h-card"><a href="https://indieweb.studio/pub/actors/LiquidParasyte" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>LiquidParasyte</span></a></span> about things they are coming across that need work or are broken on <span class="h-card"><a href="https://bonfire.cafe/pub/actors/Bonfire" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>Bonfire</span></a></span><br><a href="https://indieweb.studio/post/01KJ0T79KGJRWHYTKWJJF4254R" rel="nofollow" class="ellipsis" title="indieweb.studio/post/01KJ0T79KGJRWHYTKWJJF4254R"><span class="invisible">https://</span><span class="ellipsis">indieweb.studio/post/01KJ0T79K</span><span class="invisible">GJRWHYTKWJJF4254R</span></a><br><a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/bonfire/" rel="tag">#bonfire</a></p>
<p>I've seen an ongoing debate between "Note" versus "Article" in ActivityPub / ActivityStreams.</p><p>When is something a "Note"‽<br>When is something an "Article"‽</p><p>Personally — I would probably have made the distinction this way.</p><p>An "Article" has a title.<br>A "Note" doesn't have a title.</p><p>(In ActivityPub / ActivityStreams, a 'title' seems to tend to get represented in the "name" field.)</p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/activitystreams/" rel="tag">#ActivityStreams</a> <a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/fedidevs/" rel="tag">#FediDevs</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</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>RE: <a href="https://mastodon.social/@fediversereport/116178002926045553" rel="nofollow" class="ellipsis" title="mastodon.social/@fediversereport/116178002926045553"><span class="invisible">https://</span><span class="ellipsis">mastodon.social/@fediverserepo</span><span class="invisible">rt/116178002926045553</span></a></p><p>Laurens Hof is at it again highlighting the problems of our lack of an adequate ActivityPub API and the hurdles that are to come in it getting adoption.<br><a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
<p>FEP website now displays the number of implementations for each implementable proposal:</p><p><a href="https://fediverse.codeberg.page/fep/final/" rel="nofollow" class="ellipsis" title="fediverse.codeberg.page/fep/final/"><span class="invisible">https://</span><span class="ellipsis">fediverse.codeberg.page/fep/fi</span><span class="invisible">nal/</span></a></p><p>These numbers are based on the information that authors provide in the "Implementations" section of a proposal.</p><p>By default, proposals are <a href="https://codeberg.org/fediverse/fep/src/commit/f68a69fc7911e7af39361deb0730d1f1ce50337b/fep/a4ed/fep-a4ed.md#proposal-type" rel="nofollow">informational</a>, so authors need to opt in by adding type: implementation to the metadata block.</p><p><a href="/tags/fep/" rel="tag">#fep</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
<p>Właśnie zaimplementowałam w <a href="/tags/nicolium/" rel="tag">#Nicolium</a> funkcjonalność usuwania Śledzika z wykorzystaniem kodu „5P13RD4L4J-5L3D21U” 🚀 </p><p><a href="https://codeberg.org/mkljczk/nicolium/commit/a8fc1717c443d091d5f90ea45b1e9af44dc45b0c" rel="nofollow" class="ellipsis" title="codeberg.org/mkljczk/nicolium/commit/a8fc1717c443d091d5f90ea45b1e9af44dc45b0c"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/mkljczk/nicolium/</span><span class="invisible">commit/a8fc1717c443d091d5f90ea45b1e9af44dc45b0c</span></a></p><p><a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/nicoliumdev/" rel="tag">#NicoliumDev</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>RE: <a href="https://blog.fabiomanganiello.com/article/Federated-replies-and-reactions-in-Madblog" rel="nofollow" class="ellipsis" title="blog.fabiomanganiello.com/article/Federated-replies-and-reactions-in-Madblog"><span class="invisible">https://</span><span class="ellipsis">blog.fabiomanganiello.com/arti</span><span class="invisible">cle/Federated-replies-and-reactions-in-Madblog</span></a></p><p>Madblog by <span class="h-card"><a href="https://blog.fabiomanganiello.com/@fabio" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>fabio</span></a></span> is really coming along!</p><p><a href="/tags/fedidev/" rel="tag">#fedidev</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>I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:</p><p><span class="h-card"><a href="https://floss.social/@COSCUP" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>COSCUP</span></a></span> 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.</p><p>Nothing is decided yet, but if you're working on <a href="/tags/activitypub/" rel="tag">#ActivityPub</a>, the <a href="/tags/fediverse/" rel="tag">#fediverse</a>, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.</p><p><a href="https://floss.social/@COSCUP/116152356550445285" rel="nofollow" class="ellipsis" title="floss.social/@COSCUP/116152356550445285"><span class="invisible">https://</span><span class="ellipsis">floss.social/@COSCUP/116152356</span><span class="invisible">550445285</span></a></p><p><a href="/tags/socialweb/" rel="tag">#SocialWeb</a> <a href="/tags/coscup/" rel="tag">#COSCUP</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
<p>The <a href="/tags/cfp/" rel="tag">#CFP</a> for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8–9) is now open! If you're working on <a href="/tags/activitypub/" rel="tag">#ActivityPub</a>, the <a href="/tags/fediverse/" rel="tag">#fediverse</a>, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. <a href="/tags/coscup/" rel="tag">#COSCUP</a> is free to attend.</p><p>👉 <a href="https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp" rel="nofollow" class="ellipsis" title="hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp"><span class="invisible">https://</span><span class="ellipsis">hackers.pub/@fedidevkr/2026/fe</span><span class="invisible">diverse-social-web-track-at-coscup-2026-cfp</span></a></p><p>(Boosts appreciated!)</p><p><a href="/tags/socialweb/" rel="tag">#SocialWeb</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a></p>
<p>RE: <a href="https://mastodon.social/@bagder/116359048796181736" rel="nofollow" class="ellipsis" title="mastodon.social/@bagder/116359048796181736"><span class="invisible">https://</span><span class="ellipsis">mastodon.social/@bagder/116359</span><span class="invisible">048796181736</span></a></p><p>Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.</p><p>On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by <span class="h-card"><a href="https://hollo.social/@fedify" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>fedify</span></a></span>, or at least scripts/aliases.</p><p>Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?</p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/rfc9421/" rel="tag">#RFC9421</a></p>
