<p>Progress on the FEP for Event objects</p><p>The <a href="https://codeberg.org/fediverse/fep/pulls/430" rel="nofollow">FEP-8a8e</a> (Fediverse Enhancement Proposal) had at lot of progress in the last months. In the meantime, the document has become somewhat more extensive than originally planned, but contains not only instructions for new features that have to be tediously implemented, but also a lot of advice and points that should provide orientation for developers of Fediverse applications that support events.</p><p>It now covers:</p><p>Required attributes<br>Events with Open End<br>Timezone<br>Physical and Virtual Locations<br>Event status<br>RSVP (Attendee Management)<br>Event Banner and Poster Images<br>Event Categories<br>Discoverability<br>Event Organizers<br>Upcoming Events Collection for ActivityPub actors<br>Term Definitions</p><p>Many thanks again to all reviewers and co-editors:</p><p><span class="h-card"><a href="https://mastodon.cisti.org/@lesion" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>lesion</span></a></span> <span class="h-card"><a href="https://phpc.social/@heiglandreas" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>heiglandreas</span></a></span> <a href="https://mastodon.social/@naturzukunft" rel="nofollow">@naturzukunft</a> <span class="h-card"><a href="https://mastodon.online/@laurin" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>laurin</span></a></span></p><p>We warmly welcome further feedback from the communities of <a href="/tags/friendica/" rel="tag">#Friendica</a>, <a href="/tags/mobilizon/" rel="tag">#Mobilizon</a>, <a href="/tags/hubzilla/" rel="tag">#Hubzilla</a>, and other Fediverse platforms supporting events.<br>If you’re working on such an application or are part of these communities, your insights would be very valuable! <span class="h-card"><a href="https://forum.friendi.ca/profile/developers" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>developers</span></a></span> <span class="h-card"><a href="https://framapiaf.org/@mobilizon" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>mobilizon</span></a></span></p></p><p></p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/fep/" rel="tag">#FEP</a></p>
fep
<p><a href="https://lists.w3.org/Archives/Public/public-swicg/2025Oct/0001.html" rel="nofollow" class="ellipsis" title="lists.w3.org/Archives/Public/public-swicg/2025Oct/0001.html"><span class="invisible">https://</span><span class="ellipsis">lists.w3.org/Archives/Public/p</span><span class="invisible">ublic-swicg/2025Oct/0001.html</span></a></p><p>SocialCG people want to make their own FEP repository on GitHub where authors will be required to sign a CLA.</p><p>I'd like to make it clear: this is not associated with the original <a href="https://codeberg.org/fediverse/fep" rel="nofollow">FEP repository</a>. The <a href="/tags/fep/" rel="tag">#FEP</a> process is meant to be open to everyone, and I will do everything I can to stop any attempts to introduce CLAs there.</p>
Alrighty, it looks like I tossed my name into the hat to assist here. We'll see where this goes.<br><br><a href="https://codeberg.org/fediverse/fep/issues/89#issuecomment-7587883" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/issues/89#issuecomment-7587883"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/iss</span><span class="invisible">ues/89#issuecomment-7587883</span></a><br><br><a href="/tags/dns/" rel="tag">#DNS</a> <a href="/tags/fep/" rel="tag">#FEP</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a><br>
<p>After reviewing <a href="https://w3id.org/fep/5624" rel="nofollow">FEP-5624: Per-object reply control policies</a> and GoToSocial's <a href="https://docs.gotosocial.org/en/latest/federation/interaction_policy/" rel="nofollow">interaction policy</a> spec, I find myself leaning toward the latter for long-term considerations, though both have merit.</p><p>FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, <a href="/tags/gotosocial/" rel="tag">#GoToSocial</a>'s approach seems to offer some architectural advantages:</p><p>The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny<br>Separating approval objects from interactions appears more secure against forgery<br>The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics<br>The extensible framework allows for handling diverse interaction types, not just replies</p><p>I wonder if creating an <a href="/tags/fep/" rel="tag">#FEP</a> that extracts GoToSocial's interaction policy design into a standalone standard might be worthwhile. It could potentially serve as a more comprehensive foundation for access control in <a href="/tags/activitypub/" rel="tag">#ActivityPub</a>.</p><p>This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.</p><p><a href="/tags/fep5624/" rel="tag">#FEP5624</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/fediverse/" rel="tag">#fediverse</a> <a href="/tags/replycontrol/" rel="tag">#replycontrol</a> <a href="/tags/interactionpolicy/" rel="tag">#interactionpolicy</a></p>
<p>The <a href="/tags/fep/" rel="tag">#FEP</a> website built by <span class="h-card"><a href="https://mymath.rocks/timeline/" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>helge</span></a></span> is now online:</p><p><a href="https://fediverse.codeberg.page/fep/" rel="nofollow"><span class="invisible">https://</span>fediverse.codeberg.page/fep/</a></p><p>Enjoy!</p><p>RE: <a href="https://mymath.rocks/objects/dad3deb4-a29d-4df3-a017-ae5700a387f3" rel="nofollow" class="ellipsis" title="mymath.rocks/objects/dad3deb4-a29d-4df3-a017-ae5700a387f3"><span class="invisible">https://</span><span class="ellipsis">mymath.rocks/objects/dad3deb4-</span><span class="invisible">a29d-4df3-a017-ae5700a387f3</span></a></p>
<p>Started writing a new FEP:</p><p><a href="https://codeberg.org/silverpill/feps/src/branch/main/0151/fep-0151.md" rel="nofollow">FEP-0151: NodeInfo in Fediverse Software (2025 edition)</a></p><p>Mentioned some best practices. What else should be added there?</p><p><a href="/tags/fep/" rel="tag">#FEP</a> <a href="/tags/nodeinfo/" rel="tag">#NodeInfo</a></p>
<p>I wrote a <a href="/tags/fep/" rel="tag">#FEP</a> about actor statuses. Yeah, those things near the name that Facebook had in 2007.</p><p><a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/src</span><span class="invisible">/branch/main/fep/82f6/fep-82f6.md</span></a></p><p><a href="/tags/activitypub/" rel="tag">#activitypub</a></p>
<p>Working on polls and writing a new <a href="/tags/fep/" rel="tag">#FEP</a></p><p><a href="https://codeberg.org/silverpill/feps/src/branch/main/9967/fep-9967.md" rel="nofollow" class="ellipsis" title="codeberg.org/silverpill/feps/src/branch/main/9967/fep-9967.md"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/silverpill/feps/s</span><span class="invisible">rc/branch/main/9967/fep-9967.md</span></a></p>
<p>FEP-9967: Polls</p><p><a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/src/branch/main/fep/9967/fep-9967.md"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/src</span><span class="invisible">/branch/main/fep/9967/fep-9967.md</span></a></p><p><a href="/tags/activitypub/" rel="tag">#activitypub</a> <a href="/tags/fep/" rel="tag">#fep</a></p>
<p>I've made some changes to FEP-521a: <a href="https://codeberg.org/fediverse/fep/pulls/482" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/pulls/482"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/pul</span><span class="invisible">ls/482</span></a></p><p>- Many changes due to a rename of Controller Documents specification to <a href="https://w3c.github.io/cid/" rel="nofollow">Controlled Identifiers</a>.<br>- Using <a href="https://www.w3.org/ns/cid/v1" rel="nofollow"><span class="invisible">https://</span>www.w3.org/ns/cid/v1</a> context in example. I haven't tried it myself yet, but it works in JSON-LD playground.<br>- Key ID and actor ID are now recommended to have same origin.</p><p><a href="/tags/fep_521a/" rel="tag">#fep_521a</a> <a href="/tags/fep/" rel="tag">#fep</a></p>
<p>All implementations of <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md" rel="nofollow">FEP-521a</a> are implementations of Controlled Identifiers spec.</p><p><a href="/tags/fep/" rel="tag">#fep</a> <a href="/tags/fep_521a/" rel="tag">#fep_521a</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/controlledidentifiers/" rel="tag">#ControlledIdentifiers</a></p><p>RE: <a href="https://w3c.social/users/w3c/statuses/113947371169653222" rel="nofollow" class="ellipsis" title="w3c.social/users/w3c/statuses/113947371169653222"><span class="invisible">https://</span><span class="ellipsis">w3c.social/users/w3c/statuses/</span><span class="invisible">113947371169653222</span></a></p>
<p>The Work Continues: What’s Next</p><p>Details will follow soon — but the work on events in the <a href="/tags/fediverse/" rel="tag">#Fediverse</a> is far from complete. Key upcoming milestones include:</p><p>Improvements and new features for the <a href="https://codeberg.org/Event-Federation/wordpress-event-bridge-for-activitypub" rel="nofollow">Event Bridge for ActivityPub</a> plugin for WordPress<br>Continued development to maintain, fix issues, enhance, and expand functionality.<br>Work on Fediverse Enhancement Proposals (FEPs)<br>Ensuring a robust final status of FEP-8a8e and focus on recurring and irregularly scheduled events.<br>Support for event interoperability in other Fediverse applications<br>Contribute to other Fediverse applications and help them to explore and improve support for Event objects. For example, <span class="h-card"><a href="https://graz.social/@linos" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>linos</span></a></span> has outlined <a href="https://github.com/mastodon/mastodon/issues/20407#issuecomment-2960514632" rel="nofollow">a potential roadmap for Mastodon</a>.<br>Contribution to GatherPress<br>Active involvement in the <a href="https://gatherpress.org/" rel="nofollow">GatherPress</a> project — a modern and truly FLOSS community oriented WordPress event plugin — to ensure full ActivityPub compatibility, including RSVP support and advanced federation features.<br>Community engagement and outreach<br>Participation in conferences, public talks, and direct conversations to foster knowledge exchange, gather feedback, and grow the ecosystem around federated events.</p><p>Additional updates and technical details will be shared soon. Input, testing, and collaboration from interested parties are always welcome. Or if you know any conferences we should attend, let us know.</p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/events/" rel="tag">#Events</a> <a href="/tags/fediverse/" rel="tag">#Fediverse</a> <a href="/tags/fep/" rel="tag">#FEP</a> <a href="/tags/gatherpress/" rel="tag">#GatherPress</a> <a href="/tags/wordpress/" rel="tag">#WordPress</a></p>
Edited 299d ago
<p>FEP-844e: Capability discovery has been published to the FEP repository:</p><p><a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/src</span><span class="invisible">/branch/main/fep/844e/fep-844e.md</span></a></p><p>I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:</p><p>{ "generator": { "type": "Application", "implements": [ { "name": "RFC-9421: HTTP Message Signatures", "href": "<a href="https://datatracker.ietf.org/doc/html/rfc9421" rel="nofollow" class="ellipsis" title="datatracker.ietf.org/doc/html/rfc9421"><span class="invisible">https://</span><span class="ellipsis">datatracker.ietf.org/doc/html/</span><span class="invisible">rfc9421</span></a>" } ] }}</p><p>All important information is embedded, so additional HTTP requests are not necessary.</p><p><a href="/tags/fep/" rel="tag">#FEP</a></p>
<p>Two upcoming changes in the <a href="/tags/fep/" rel="tag">#FEP</a> process:</p><p>- <a href="https://codeberg.org/fediverse/fep/pulls/543" rel="nofollow">Withdrawing stale proposals</a>. If a proposal remains inactive for 2 years, its status is changed to WITHDRAWN. Previously, the period was 1 year after submission, and facilitators were supposed to contact authors before withdrawing (that didn't work well).<br>- <a href="https://codeberg.org/fediverse/fep/pulls/634" rel="nofollow">Implementation tracking</a>. If a proposal has type: implementation attribute, we will automatically count list items in the "Implementations" section and display that number somewhere (probably in README). If your proposal is implementable, I recommend adding type: implementation attribute to it. Also, don't forget to mention implementations if they exist - this information is very important.</p>
<p>I am working on a new revision of FEP-8b32:</p><p><a href="https://codeberg.org/fediverse/fep/pulls/527" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/pulls/527"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/pul</span><span class="invisible">ls/527</span></a></p><p>There are many editorial changes, such as replacing Controller Documents with <a href="https://www.w3.org/TR/cid/" rel="nofollow">Controlled Identifiers</a>, new implementation (<a href="https://github.com/AmaseCocoa/apsig" rel="nofollow">apsig</a>), and one new requirement:</p><p>>The identifier of the verification method MUST have the same origin as the identifier of the secured document, or have a different origin, but with an established cross-origin trust relationship to the identifier of the secured document.</p><p>This is related to today's <a href="https://mitra.social/objects/0195a90f-f97f-6551-b1a0-409a04f5d935" rel="nofollow">FEP-fe34 update</a> and should cover all possible uses of integrity proofs, including regular objects signed with DID keys, and portable objects (FEP-ef61). I expect that all existing implementations of FEP-8b32 already meet this new requirement, but if not, please let me know. I'll keep this PR open / WIP for a couple of days.</p><p><a href="/tags/fep_8b32/" rel="tag">#fep_8b32</a> <a href="/tags/fep/" rel="tag">#fep</a></p>
<p><a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/9098/fep-9098.md" rel="nofollow">FEP-9098: Custom emojis</a> has been published.</p><p><a href="/tags/fep/" rel="tag">#FEP</a> <a href="/tags/activitypub/" rel="tag">#ActivityPub</a></p>
<p>Does anyone know if Open Reads on Android can be used as an app for BookWyrm or NeoDB? If not, how much work would it take on each end to make live data sharing between them work? Could there be an FEP in this?</p><p><a href="/tags/askfedi/" rel="tag">#AskFedi</a> <a href="/tags/android/" rel="tag">#Android</a> <a href="/tags/openreads/" rel="tag">#OpenReads</a> <a href="/tags/bookwyrm/" rel="tag">#BookWyrm</a> <a href="/tags/neodb/" rel="tag">#NeoDB</a> <a href="/tags/fep/" rel="tag">#FEP</a></p><p><a href="https://flipboard.com/@Androidauth" rel="nofollow">@Androidauth</a> <span class="h-card"><a href="https://fosstodon.org/@openreads" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>openreads</span></a></span> <span class="h-card"><a href="https://tech.lgbt/@bookwyrm" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>bookwyrm</span></a></span> <span class="h-card"><a href="https://mastodon.social/@neodb" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>neodb</span></a></span></p>
<p>FEP-0151: NodeInfo in Fediverse Software (2025 edition)</p><p>I added the "Implementations" section and a reference to <a href="https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md" rel="nofollow">FEP-844e</a>:</p><p><a href="https://codeberg.org/fediverse/fep/pulls/741" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/pulls/741"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/pul</span><span class="invisible">ls/741</span></a></p><p>There are 3 independent implementations now. Since this is a "2025 edition", and 2025 is about to end, I think the FEP should be finalized.</p><p>If you have any suggestions, please comment here, on <a href="https://socialhub.activitypub.rocks/t/fep-0151-nodeinfo-in-fediverse-software-2025-edition/5307" rel="nofollow">SocialHub</a>, or <a href="https://codeberg.org/silverpill/feps/issues" rel="nofollow">create an issue</a>.</p><p><a href="/tags/fep/" rel="tag">#fep</a> <a href="/tags/fep_0151/" rel="tag">#fep_0151</a> <a href="/tags/activitypub/" rel="tag">#activitypub</a> <a href="/tags/nodeinfo/" rel="tag">#nodeinfo</a></p>
<p>Good morning Fediverse.</p><p>The <a href="https://helge.codeberg.page/fep/" rel="nofollow">FEP static site</a> is nearing completion. The preview is available at <a href="https://helge.codeberg.page/fep/" rel="nofollow"><span class="invisible">https://</span>helge.codeberg.page/fep/</a>.</p><p>The pull request is at <a href="https://codeberg.org/fediverse/fep/pulls/673" rel="nofollow" class="ellipsis" title="codeberg.org/fediverse/fep/pulls/673"><span class="invisible">https://</span><span class="ellipsis">codeberg.org/fediverse/fep/pul</span><span class="invisible">ls/673</span></a>.</p><p>If you have feedback, now is the time to submit it.</p>
<p>FEP drafting: Am I using “side effects” here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.</p><p><a href="/tags/activitypub/" rel="tag">#ActivityPub</a> <a href="/tags/fedidev/" rel="tag">#FediDev</a> <a href="/tags/fep/" rel="tag">#FEP</a></p>
<p>In this recent <a href="/tags/ft/" rel="tag">#FT</a> piece </p><p><a href="https://www.ft.com/content/8192467e-e9d7-4c0a-ab0d-59bd6351a1bb" rel="nofollow" class="ellipsis" title="www.ft.com/content/8192467e-e9d7-4c0a-ab0d-59bd6351a1bb"><span class="invisible">https://</span><span class="ellipsis">www.ft.com/content/8192467e-e9</span><span class="invisible">d7-4c0a-ab0d-59bd6351a1bb</span></a></p><p>(paywalled, unfortunately), <a href="/tags/karlfriston/" rel="tag">#KarlFriston</a> gets to say, once more (this time in his role as chief scientist of <a href="/tags/versesai/" rel="tag">#VersesAI</a>), that active inference and the <a href="/tags/fep/" rel="tag">#FEP</a> will allow <a href="/tags/ai/" rel="tag">#AI</a> to have true agency. </p><p>This is utter bullshit.</p><p>Agency requires <a href="/tags/relevancerealization/" rel="tag">#RelevanceRealization</a> but Friston's framework cannot deal with that. You will not get true agency from that. It's sill purely about problem *solving*, not *framing*.</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>New <a href="/tags/fep/" rel="tag">#FEP</a> view:<br> <br><a href="https://socialhub.activitypub.rocks/t/proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft" rel="nofollow" class="ellipsis" title="socialhub.activitypub.rocks/t/proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft"><span class="invisible">https://</span><span class="ellipsis">socialhub.activitypub.rocks/t/</span><span class="invisible">proposal-explore-page-with-filterable-fep-table/8572/3?u=naturzukunft</span></a></p><p><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>