Jack William Bell
Today we have #ActivityPub, which provides real and actual #Federation, but is overly complex and difficult to implement, and we have ATProto, which promises Federation, but delivers central control and is even more complex and difficult to implement.
See this discussion (you'll need to scroll down a bit to find my contribution):
> https://circumstances.run/@davidgerard/115335451897410462
Dave Winer would love the point I was making there…
[contd]
silverpill
And I think it should be based on RSS 1.0 or the Atom Syndication spec (except dump XML and use JSON or something)
But ActivityPub is the evolution of Atom/RSS, with JSON instead of XML...
Perhaps you actually want a 'Really Simple ActivityPub'? It could be designed to be compatible with ActivityPub, so a bridge won't be necessary.
I think this is doable. I think the flavor of ActivityPub we use in Fediverse is already very close to Really Simple ActivityPub, it just doesn't have a spec (yet).
Jack William Bell
The goal is to have a specification you can read and grok in an afternoon – and then implement something usable in a week.
After that we create a bridge from RSF to ActivityPub and we let a thousand implementations bloom…
[fin]
Jack William Bell
This thread is getting long, so I'm going to cut to the chase: I think there needs to be yet another Federation protocol. A simple protocol with a full-featured and generic Reference Implementation.
And I think it should be based on RSS 1.0 or the Atom Syndication spec (except dump XML and use JSON or something):
> http://www.atomenabled.org/developers/syndication/
> https://validator.w3.org/feed/docs/rss1.html
And, finally? I think it should support peer-to-peer Federation.
Let's call it 'Really Simple Federation' – RSF…
[contd]
Jack William Bell
There are libraries out there for client implementations in many languages. And several of them even support Mastodon extensions to ActivityPub. But that's not what I'm talking about.
I'm saying I can't simply throw together a proof of concept ActivityPub server for some crazy idea I might have. And the reason for this is the protocol itself; so complex and layered every attempt to implement it has ended up tightly coupled to the rest of the implementation. This is a bad thing.
[contd]
Jack William Bell
Am I dunking on ActivityPub right now? Well, yeah, I guess I am.
Do not take this to mean I think we shouldn't be using ActivityPub. Hell, I'm using it right now! I'll take something that works over promised Pie in the Sky or 'doesn't actually deliver' any day. I'm not stupid.
Here's the problem: I can't easily roll my own Fedi servers. There is no such thing as a 'generic, but tweakable Fedi server' and there are no libraries implementing the server protocol without baggage.
[contd]
Jack William Bell
In fact, the closest thing we have to an ActivityPub *Reference Implementation* is the Express ActivityPub Server, which hasn't been updated recently and is only a *partial implementation*:
> https://github.com/dariusk/express-activitypub
I probably don't need to make the following point if you are a coder, but for the peanut gallery: Every substantial and mature protocol comes with a *Reference Implementation* as a testbed. And, by extension, this means ActivityPub is neither substantial nor mature.
[contd]
Jack William Bell
Why do I say #ActivityPub is overly complex and difficult to implement?
I'd need to get into some very geeky weeds to explain exactly why and I'm not going to do that on a thread. But, suffice to say, there's only a small number of full-featured Fedi implementations out there for a reason. And every single one of them is using a protocol implementation directly tied to their overall implementation.
This has been pointed out before:
> Playing with ActivityPub. https://macwright.com/2022/12/09/activitypub
[contd]
silverpill
I want something much simpler anyway. But I don't want to use JSON-LD, so no direct interop will be possible.
It's hard to find a developer who wants to use JSON-LD in a social application. But the good news is that JSON-LD is not required, and not even used: our servers produce and consume plain JSON documents. Yes, these documents have @context property, but for most implementations this is purely ceremonial thing.
Here's some test data: https://funfedi.dev/support_tables/hashtag_jsonld/
That's what I meant when I said that the flavor of ActivityPub we use in Fediverse is already quite close to 'Really Simple ActivityPub'. Nobody wanted an over-engineered protocol, so it was simplified and optimized by early adopters.
Jack William Bell
Also, FWIW? In the end Dave Winer was right about the 'Semantic Web'. Not only did it *not* take the web by storm, it failed PRECISELY for the reasons Dave said it would fail.
You can say a lot of things about Dave, I know I've said most of them. But I've come to fully internalize and accept his main orgainizing precept: "Do the simplest thing that could possibly work."
Jack William Bell
While I'm referring to that ancient Slashdot post, let me surface a comment offering a reason why Dave Winer didn't like RDF and my response.
The point here? Whenever we have something like JSON-LD or RDF XML (or, for that matter, SOAP) we are dealing with what some people (and I among them) will call an over-engineered mess.
In this conceptualization ActivityStreams are capable of supporting nearly ANY use case. But they are over-engineered for 80% of use cases.
Jack William Bell
Follow this link and scroll down to my contribution:
> (fixed url) https://circumstances.run/@davidgerard/115335451897410462
There I explain (a) I don't have a problem with subject/predicate/object triplet-based network graphs, but (b) lots of people have difficulty conceptualizing them.
JSON-LD, like RDF XML, is incredibly flexible and you can do amazing things with it based on few simple rules. But, as I wrote in this ancient Slashdot post, RDF is hard PRECISELY because RDF is simple:
Jack William Bell
> "But ActivityPub is the evolution of Atom/RSS, with JSON instead of XML..."
Not exactly. ActivityPub is based on ActivityStreams. And ActivityStreams are a variant of RDF using JSON-LD instead of RDF XML. So, at best ActivityPub is based on RSS 2.0. (Which itself is overly complex IMHO.)
> "Perhaps you actually want a 'Really Simple ActivityPub'?"
Sort of. I want something much simpler anyway. But I don't want to use JSON-LD, so no direct interop will be possible.
silverpill
URLs which are then ignored by the implementation (Mastodon in my case) and given URLs on the local server?
The URL is added because the originating server has a different view of hashtag. You can visit it and discover other posts with that tag that your server doesn't have.
Not all implementations rewrite tag URLs in post content.
Why even have hashtags as part of the protocol? Why not let the implementation decide how to parse and handle them in the first place?
Tags may not be present in post content. And I think it's nice that parsing HTML on the server side is not necessary.
Jack William Bell
Gotcha. But compare and contrast to:
- Atom – http://www.atomenabled.org/
OR
- JSON Feed – https://www.jsonfeed.org/version/1/
And ask yourself why you need a type and name and a list consisting of names and URLs for hashtags. URLs which are then ignored by the implementation (Mastodon in my case) and given URLs on the local server?
IOW? Why even have hashtags as part of the protocol? Why not let the implementation decide how to parse and handle them in the first place?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.