fep
I am working on a new revision of FEP-8b32:
https://codeberg.org/fediverse/fep/pulls/527
There are many editorial changes, such as replacing Controller Documents with Controlled Identifiers, new implementation (apsig), and one new requirement:
>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.
This is related to today's FEP-fe34 update 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.
After reviewing FEP-5624: Per-object reply control policies and GoToSocial's interaction policy spec, I find myself leaning toward the latter for long-term considerations, though both have merit.
FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, #GoToSocial's approach seems to offer some architectural advantages:
The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny
Separating approval objects from interactions appears more secure against forgery
The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics
The extensible framework allows for handling diverse interaction types, not just replies
I wonder if creating an #FEP 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 #ActivityPub.
This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.
#FEP5624 #fedidev #fediverse #replycontrol #interactionpolicy
Started writing a new FEP:
FEP-0151: NodeInfo in Fediverse Software (2025 edition)
Mentioned some best practices. What else should be added there?
I wrote a #FEP about actor statuses. Yeah, those things near the name that Facebook had in 2007.
https://codeberg.org/fediverse/fep/src/branch/main/fep/82f6/fep-82f6.md
FEP-9098: Custom emojis has been published.
The Work Continues: What’s Next
Details will follow soon — but the work on events in the #Fediverse is far from complete. Key upcoming milestones include:
Improvements and new features for the Event Bridge for ActivityPub plugin for WordPress
Continued development to maintain, fix issues, enhance, and expand functionality.
Work on Fediverse Enhancement Proposals (FEPs)
Ensuring a robust final status of FEP-8a8e and focus on recurring and irregularly scheduled events.
Support for event interoperability in other Fediverse applications
Contribute to other Fediverse applications and help them to explore and improve support for Event objects. For example, @linos has outlined a potential roadmap for Mastodon.
Contribution to GatherPress
Active involvement in the GatherPress project — a modern and truly FLOSS community oriented WordPress event plugin — to ensure full ActivityPub compatibility, including RSVP support and advanced federation features.
Community engagement and outreach
Participation in conferences, public talks, and direct conversations to foster knowledge exchange, gather feedback, and grow the ecosystem around federated events.
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.
#ActivityPub #Events #Fediverse #FEP #GatherPress #WordPress
FEP-844e: Capability discovery has been published to the FEP repository:
https://codeberg.org/fediverse/fep/src/branch/main/fep/844e/fep-844e.md
I already use it to signal RFC-9421 support. An anonymous Application object is added to actors:
{ "generator": { "type": "Application", "implements": [ { "name": "RFC-9421: HTTP Message Signatures", "href": "https://datatracker.ietf.org/doc/html/rfc9421" } ] }}
All important information is embedded, so additional HTTP requests are not necessary.
Two upcoming changes in the #FEP process:
- Withdrawing stale proposals. 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).
- Implementation tracking. 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.