#Bluesky is easier for users than #Mastodon, but #ATproto is harder for developers than #ActivityPub.
General Discussion
2
Post
2
Autori
1
Visualizzazioni
-
#Bluesky is easier for users than #Mastodon, but #ATproto is harder for developers than #ActivityPub. I think.
-
#Bluesky is easier for users than #Mastodon, but #ATproto is harder for developers than #ActivityPub. I think.
CBOR is more difficult than JSON-LD.
(AT-Protocol uses CBOR where ActivityPub uses JSON-LD.)
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@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 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 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.
-
@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.
-
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.
-
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."
-
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.
-
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:
