Clicked through on that link for some reason
"The spec is ActivityPub, but federation is unfortunately Mastodon."
No
#ActivityPub is a protocol
It requires some sort of implementation in some sort of distribution/app
Mastodon (for one) is only *one* distribution/app
There are others
These others may or may not "federate" with each to varying degrees
They are all *different* and "varying" implementations of ActivityPub
I don't know why this is so hard to understand, but it sure seems to be...
Clicked through on that link for some reason
"The spec is ActivityPub, but federation is unfortunately Mastodon."
No
#ActivityPub is a protocol
It requires some sort of implementation in some sort of distribution/app
Mastodon (for one) is only *one* distribution/app
There are others
These others may or may not "federate" with each to varying degrees
They are all *different* and "varying" implementations of ActivityPub
I don't know why this is so hard to understand, but it sure seems to be...
I do not think that @naturzukunft2026 misunderstands this.
There's a difference between #ActivityPub the protocol and #fediverse the on-the-wire reality, and in the latter #Mastodon is the post-facto interoperability leader.
For there to be interoperabiity in a particular domain there needs to be agreement on data formats and msg exchanges, and the specs don't provide full coverage nor clear guidance on this. Though #ActivityStreams has a section on use cases it was designed to handle, they aren't fully specified.
Of course it is perfectly fine, and highly encouraged to model a domain in the best possible way, but you won't be "part of the fediverse" until you implement enough of the post-facto Mastodon microblogging interop quirks.
We don't have a good ecosystem-level extension approach, and the #FEP constitutes a best-effort. A bandaid that allows to present a best-practice in hopes it gets further adoption.
I'm not sure that JSON-LD offers solace though.
But I agree with your 2 prescriptions; realising the potential of Linked Data and the Client-2-Server API. Particularly the second one.
"Almost everyone focuses on Server-to-Server federation, but C2S enables client diversity — mobile apps, CLI tools, browser extensions that work with any ActivityPub server. This lowers the barrier for developers: build a client once, connect to any server. We need better C2S libraries and reference implementations."
(2/3)
Christine's vision for ActivityPub was a network where every app can login to every server. For example;
The web app on a PeerTube server can login into your home server and post to your video channel as @you@homeserver.foo, instead of people having to remember your videos are on @yourchannel@videoserver.bar.
And vice-versa! If your first account is on PT, you can login to a Mastodon web app and post 500 char text as @yourchannel@videoserver.bar. You don't need to set up a second fediverse account to post a different media type.
(3/3)
