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.
-
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.
-
@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.
You are getting into some of the details about how ActivityPub and ActivityStreams do not actually fit well with how people want to use it. And, thus, got hacked in non-obvious and non-documented ways to work with the actual use cases – which is a major reason why ActivityPub is so hard to implement in a generic way.
I guess what I've been saying is: ActivityPub is great and all, but we need something a lot simpler you can use for the 80% use cases without knowing all that.
-
You are getting into some of the details about how ActivityPub and ActivityStreams do not actually fit well with how people want to use it. And, thus, got hacked in non-obvious and non-documented ways to work with the actual use cases – which is a major reason why ActivityPub is so hard to implement in a generic way.
I guess what I've been saying is: ActivityPub is great and all, but we need something a lot simpler you can use for the 80% use cases without knowing all that.
@jackwilliambell @silverpill i guess what i'm saying is that activitypub is already simple if you use it for what it was intended. but if you implement activitypub as intended, you can't talk to mastodon. the complexity isn't in activitypub, it's in everything mastodon requires to talk to mastodon.
the way atom was used in ostatus was a better fit for mastodon, but the reason mastodon moved from ostatus to activitypub was to have followers-only posts without separate feeds per subscriber.
-
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.
@jackwilliambell @silverpill extensions in fedi typically *aren't* namespaced. they would be if people used the json-ld context, but most people ignore the context.
jsonfeed is fine but the real question with any format is, who's actually consuming it? that's what drives adoption more than any quality. for web feeds, atom seems to be the cleanest while still being widely supported. rss is awful: https://nullprogram.com/blog/2013/09/23/
-
@jackwilliambell @silverpill i guess what i'm saying is that activitypub is already simple if you use it for what it was intended. but if you implement activitypub as intended, you can't talk to mastodon. the complexity isn't in activitypub, it's in everything mastodon requires to talk to mastodon.
the way atom was used in ostatus was a better fit for mastodon, but the reason mastodon moved from ostatus to activitypub was to have followers-only posts without separate feeds per subscriber.
That's more background information I didn't have. And I've done quite a bit of research into ActivityPub, before I gave up trying to figure out a way to untangle all the ways extant implementations were using it that didn't match the docs.
So, what about the non-Mastodon (and Mastodon workalike) Fedi implementations? It seems to me they all have some weirdness to them, but have we got to the point Mastodon-compatibility is required to use the Fedi? Has ActivityPub failed?
