#Bluesky is easier for users than #Mastodon, but #ATproto is harder for developers than #ActivityPub.
General Discussion
2
Post
2
Autori
0
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
-
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:
-
> "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.
-
CBOR is more difficult than JSON-LD.
(AT-Protocol uses CBOR where ActivityPub uses JSON-LD.)
-
@tommi @varia @fediforum @decentral1se @yawnbox okay, this was very funny to see only after I just bragged about the poutine bar.
-
Cous cous + @varia + @fediforum
= FediCousCous ❤️
Mmmmh 😋
(#ActivityPub-flavoured food is tastyyy! @decentral1se and @yawnbox can confirm)
