this post was submitted on 08 Dec 2025
117 points (98.3% liked)
Fediverse
38449 readers
304 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, Mbin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
>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...
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.
By separating core protocol requirements and optional features.
The guide has a section titled "Protocol features":
https://codeberg.org/ap-next/ap-next/src/commit/f1ee497085f56cde9860b9417eba8cd05cd1522a/guide.md#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.