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.
-
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]
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]
-
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]
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]
-
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]
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]
-
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]
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]
-
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]
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).
-
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).
> "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.
-
> "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.
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:
-
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:
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.
-
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.
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."
-
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."
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
@contextproperty, 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.
-
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]
NOTE: While spelunking on this stuff I discovered JSON Feed:
> https://www.jsonfeed.org/version/1/
Which is basically Atom Syndication or RSS 1.0 using JSON and fully compatible with them:
-
NOTE: While spelunking on this stuff I discovered JSON Feed:
> https://www.jsonfeed.org/version/1/
Which is basically Atom Syndication or RSS 1.0 using JSON and fully compatible with them:
@jackwilliambell I haven't looked at it in a while, but I *really* like the IndieWeb spec that did feed markup via classes on elements in your danged HTML page, where the content already freakin' exists, and where you can read what's showing up as a human.
So you just add some class tags to your blog's main page, and the syndicator gets update notifications and whatnot just like that... And there's no confusion about HTML escaping, or...
-
@jackwilliambell I haven't looked at it in a while, but I *really* like the IndieWeb spec that did feed markup via classes on elements in your danged HTML page, where the content already freakin' exists, and where you can read what's showing up as a human.
So you just add some class tags to your blog's main page, and the syndicator gets update notifications and whatnot just like that... And there's no confusion about HTML escaping, or...
I didn't catch that, but it goes directly to my point of keeping it simple. That is, unless they did some kind of RDF markup for the semantics…
I'll have to take a look at that.
-
I didn't catch that, but it goes directly to my point of keeping it simple. That is, unless they did some kind of RDF markup for the semantics…
I'll have to take a look at that.
@jackwilliambell I think it was at https://indieweb.org/microformats , and I think I remember implementing it for Flutterby, though my recent rebuild from circa 2013 backups might have blown that and I may need to re-do it.
-
> "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.
@jackwilliambell @silverpill you've got a missing link: https://activitystrea.ms started as an extension to atom, and then developed a json serialization that could be used instead of or alongside the atom serialization. json activity streams 1.0 was taken to the w3c and evolved into activity streams 2.0, which optionally uses json-ld if you want to use external vocabularies.
-
@jackwilliambell @silverpill you've got a missing link: https://activitystrea.ms started as an extension to atom, and then developed a json serialization that could be used instead of or alongside the atom serialization. json activity streams 1.0 was taken to the w3c and evolved into activity streams 2.0, which optionally uses json-ld if you want to use external vocabularies.
@jackwilliambell @silverpill in practice, fedi uses external vocab anyway without json-ld, they just expect everyone else to have the exact same context instead of actually using the provided context. in other words, they hardcode understanding certain shorthand terms without actually checking if those terms mean what they think they mean. this mostly only works because mastodon is the de facto protocol and reference implementation, and not many people care about publishing activities.
-
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.
@jackwilliambell @silverpill the confounding factor is that activitystreams was defined for the purpose of describing streams of activities. literal "activity streams". this is a very clear application and use case, and was even thought to be the unifying model for all social activity on the web. sure, you can map things into rdf just like you can map *anything* into rdf (and json-ld is a way to map any arbitrary json into flat statements). but activitystreams is not being used for that purpose.
-
@jackwilliambell @silverpill the confounding factor is that activitystreams was defined for the purpose of describing streams of activities. literal "activity streams". this is a very clear application and use case, and was even thought to be the unifying model for all social activity on the web. sure, you can map things into rdf just like you can map *anything* into rdf (and json-ld is a way to map any arbitrary json into flat statements). but activitystreams is not being used for that purpose.
@jackwilliambell @silverpill what ended up happening is that mastodon et al didn't actually care about activities; what they were *really* concerned with was their idea of a "post". you can see this in how basically no one on fedi ever renders a Create activity, they unwrap and discard the activity to get at the Note. this happens with basically every activity over the wire -- softwares like mastodon will take any incoming activity and treat it as a procedure call, then throw away the activity.
-
@jackwilliambell @silverpill what ended up happening is that mastodon et al didn't actually care about activities; what they were *really* concerned with was their idea of a "post". you can see this in how basically no one on fedi ever renders a Create activity, they unwrap and discard the activity to get at the Note. this happens with basically every activity over the wire -- softwares like mastodon will take any incoming activity and treat it as a procedure call, then throw away the activity.
@jackwilliambell @silverpill in this way, mastodon et al use activitypub more like a state synchronization protocol instead of as a publishing protocol. except they don't have measures to ensure consistency, like replayable event logs. they just grab whatever they consider a "post" and transform it and cache it in their database, and update records based on incoming activities without storing those activities.
-
@jackwilliambell @silverpill in practice, fedi uses external vocab anyway without json-ld, they just expect everyone else to have the exact same context instead of actually using the provided context. in other words, they hardcode understanding certain shorthand terms without actually checking if those terms mean what they think they mean. this mostly only works because mastodon is the de facto protocol and reference implementation, and not many people care about publishing activities.
Missing link: JSONfeed seems more suited to my intent, but I'll check out your link.
External vocabulary: RSS 1.0 and Atom Syndication both did this with 'extensions', meaning you whacked together a spec and a reference implementation and other projects either picked it up or they didn't. Namespaced to avoid collisions.
That seems to me to be (a) what you describe, but (b) without the need for JSON-LD or RDF or whatever 'does anything, but makes things hard to grok' design.
