julian@activitypub.space 1 week ago
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.
melroy@kbin.melroy.org 1 week ago
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. So 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.
wjs018@piefed.social 1 week ago
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 what 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.
melroy@kbin.melroy.org 1 week ago
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.
melroy@kbin.melroy.org 1 week ago
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.
silverpill@mitra.social 1 week ago
>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.
julian@activitypub.space 1 week ago
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...
silverpill@mitra.social 1 week ago
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.
Cooper8@feddit.online 1 week ago
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.
warmaster@lemmy.world 1 week ago
Isn’t this the way XMPP does it’s XEPs?