A Fediverse Enhancement Proposal (FEP) is a document that provides information to the Fediverse community. The goal of a FEP is to improve interoperability and well-being of diverse services, applications and communities that form the Fediverse.
The FEP Process is an initiative of the SocialHub developer community, a liaison of the W3C Social Web Incubator Community Group.
Discovered this today. If you’re on the developer side of things or are interested in how the Fediverse / ActivityPub is being built and enhanced, take a look at this codeberg repo.
You must log in or register to comment.
I knew that there was some kind of unifying force in the Fediverse. Thanks for sharing it.
Indeed, this is where the majority of improvements to the Fediverse are shared for archival.
The very way Lemmy Piefed Mbin and NodeBB can communicate and synchronize communities is detailed in those FEPs. Check out FEP 1b12.
Hi Melroy from Mbin. It’s true what you are saying Julian. These FEPs forms the basic of the fediverse. But at the same time I hate those FEPs alot. I would rather see a more detailed and better described ActivityPub protocol v2.0 or 3.0. My point is that the current ActivityPub is way too vague.
And we need dozens of various FEPs to get the features we actually need and want to get the basis features of today. Currently it’s hard to read, there is no single document. No single source of truth. All FEPs are actually optional to implement. And it’s a mess.
Could you imagine if an internet standard like http or TCP was documented like this? It would never have worked.
Isn’t this the way XMPP does it’s XEPs?
>Currently it’s hard to read, there is no single document. No single source of truth.
We can make it happen.
I am currently working on this: https://codeberg.org/ap-next/ap-next/src/branch/main/guide.md. It’s a guide for developers, but in the future it may be used as a base for a more formal specification.
Hmm, how do you reconcile the fact that not all FEPs are applicable to all application types?
For example soft deletion is preferable but not required…
By separating core protocol requirements and optional features.
The guide has a section titled “Protocol features”:
This is a place where information about optional features is collected, and soft deletion FEP could be mentioned there. A formal specification could be structured in a similar way.
You could include “either x or y or z…” specifications in the unified documentation.
So “Either soft deletion is to be disabled as by default in which case [explain standard behavior], or it is to be enabled by [yadda yadda]…”
The single document is searchable and cross-referenced internally, making it better in many cases.
100% agreed.
I have contributed quite a bit to the PieFed codebase, but the ActivityPub parts of the code are the main area where I dare not wander unless absolutely needed. Trying to make sense of what AP json should look like for specific actions is basically impossible and each software tends to have slightly different dialects anyway because of the a la carte nature of the FEPs.
To that end, I just saw that you (mbin) just published all of your AP json schema. It is so incredibly helpful to have complete schema in one place for each type of activity. So, thank you a lot! I am sure I will make use of it.
I fully agree. And you nailed it. This was exactly what I try to explain what is wrong with ActivityPub FEPs.
Thank you, we do indeed publish those schemas, these are coming from the code. So our documentation build is also relying on our code to expose these schemas, and that’s also why I can guarantee it’s always up to date.
For example we have ap issues with lemmy, lemmy doesn’t support multiple attachments. We use attachments for both links (url, other than image links) as well as images themselves can be an attachment.
But again AP fails, and lemmy only shows the picture.
Thats super cool!
