Friend-ly enby-box

To follow up on my #ActivityPub C2S post from a few days ago, I wrote a blog article on my thoughts about improving the C2S protocol and a description of some related experimentation I've been doing.
stevebate.net/activitypub-clie…

ActivityPub Client API: A Way Forward | Steve Bate

The ActivityPub Client-to-Server (C2S) protocol was envisioned as a cornerstone of the decentralized social web, along with the Server-to-Server (S2S) protocol.

^{Steve Bate}

#activitypub

Als Antwort auf Steve Bate

just small circles 🕊

Als Antwort auf Steve Bate • 1 Monat her • •

just wanted to mention that this is a great inspiring article, and that Flowz is impressive as a C2S prototype. Thank you!

Als Antwort auf Steve Bate

silverpill

Als Antwort auf Steve Bate • 1 Monat her • •

Treating ActivityPub messages as plain JSON undermines extensibility because it prevents the use of JSON-LD features like context definitions, leading to potential property name collisions and making it difficult for implementations to reliably interpret or extend messages.

No, treating ActivityPub as JSON doesn't undermine extensibility. ActivityPub is extended by adding new properties to JSON objects, and if you want to avoid collisions you can use URLs or reverse-DNS strings for property names. JSON-LD is not needed for that, it only complicates things for no reason.

Als Antwort auf silverpill

Steve Bate

Als Antwort auf silverpill • 1 Monat her • •

@silverpill Those workarounds for the undermined extensibility don't negate my point and will not generally interoperate. According to the ActivityPub book, "One point to note is that correctly parsing and interacting with AS2 objects with extended properties requires a JSON-LD-aware parser." I agree this isn't absolutely true (in special cases) but try sending expanded "toot" context term URIs and see how well it works 😉 (since all servers AFAIK expect those terms to be compacted).

@silverpill

Als Antwort auf Steve Bate

silverpill

Als Antwort auf Steve Bate • 1 Monat her • •

Why would I send an expanded toot: URI when all servers expect a short name? Your example is another proof that JSON-LD is only useful for solving problems created by JSON-LD.

Als Antwort auf silverpill

infinite love ⴳ

Als Antwort auf silverpill • 1 Monat her • •

@silverpill “all servers expect a short name” is exactly the problem. you can’t expect everyone in the world to use the same short name. this is a recipe for ambiguity and semantic confusion… which is a problem that exists regardless of whether you specify a @/context or not.

@silverpill

Als Antwort auf silverpill

Raphael Lullis

Als Antwort auf silverpill • 1 Monat her • •

> Why would I send an expanded toot: URI

Because you might be using a different namespace which is conflict with the one from mastodon, so the extended form is needed to remove ambiguity?

Als Antwort auf Raphael Lullis

Raphael Lullis

Als Antwort auf Raphael Lullis • 1 Monat her • •

JSON-LD is just one different way to serialize RDF data. Throwing JSON-LD away means throwing away all the power, benefits and flexibility that RDF can bring and in exchange gives us what? Another series of ad-hoc of data exchange formats? Why not lean in into the standard which is in development for 25+ years?

Als Antwort auf Raphael Lullis

marius

Als Antwort auf Raphael Lullis • 1 Monat her • •

to be the devil's advocate: because it brings absolutely nothing to the interactions specified by ActivityPub itself.

@silverpill @steve

@Steve Bate @silverpill

Als Antwort auf Raphael Lullis

לקס (לא לותור)

Als Antwort auf Raphael Lullis • 1 Monat her • •

Because JsonLD doesn't bring magic automatic compatibility; rather, the opposite.

There needs to be only *one* canonical way to represent the same data. That way, it is extremely easy to parse a document, and simply ignore meanings you do not recognize.

Mastodon will *always* need to explicitly support other networks' features; pretending otherwise, via JsonLD Black Magic:tm: (that btw has *zero* working implementations in the wild), is flat out foolish.

Dieser Beitrag wurde bearbeitet. (1 Monat her)

Als Antwort auf לקס (לא לותור)

לקס (לא לותור)

Als Antwort auf לקס (לא לותור) • 1 Monat her • •

JsonLD makes parsing *more* complicated, because it allows *more* canonical ways to represent the same data.

If we want a network to interoperate, we want a *single* canonical way. Otherwise, two competing ways will simple become incompatible.

Als Antwort auf לקס (לא לותור)

לקס (לא לותור)

Als Antwort auf לקס (לא לותור) • 1 Monat her • •

Context, I've dedicated hundreds of hours into failing at properly implementing a JsonLD-compliant ActivityPub server. It would've taken me *exactly* two seconds if instead, there was a JSON specification, with some basic namespace declaration functionality.

Als Antwort auf לקס (לא לותור)

Raphael Lullis

Als Antwort auf לקס (לא לותור) • 1 Monat her • •

It looks like you are advocating for a Mastodon-centric view of the Fediverse.

> that btw has *zero* working implementations in the wild

There are:

- codeberg.org/Vocata/vocata
- rdf-pub.org/
- activitypub.mushroomlabs.com

vocata

Vocabulary-Agnostic Transport Agent

^Codeberg.org

Als Antwort auf Raphael Lullis

לקס (לא לותור)

Als Antwort auf Raphael Lullis • 1 Monat her • •

No, I'm not.

I'm advocating for a Fediverse that has *one* way to do every single action. How mastodon UX represents that action is 100% irrelevant. I want the ActivityPub spec to say exactly how favoriting works. How replies work. How all the basic things, shared to all fedi platforms, work.

If I want groups - that's an add-on, that needs a specification. Not expect some fifty different impls to automagically agree.

Als Antwort auf Steve Bate

infinite love ⴳ

Als Antwort auf Steve Bate • 1 Monat her • •

i still think the way forward is less that an activitypub client should hook into mastodon, but rather that mastodon should become the activitypub client. a lot of the ux expectations of mastodon are driven by the abstraction of the all-knowing“instance”, but this doesn’t have to be monolithic. storage and delivery can be outsourced to a generic activitypub server. but that would require people to care about activities instead of statuses.

Als Antwort auf infinite love ⴳ

infinite love ⴳ

Als Antwort auf infinite love ⴳ • 1 Monat her • •

for the ux features that mastodon api provides, there is no reason to shoehorn them into ap c2s. something like search can be its own api, and it is highly dependent on which data source you use to fulfill that request. it is valid to have a mastodon instance providing a search api but being able to bypass it with a direct POST to outbox when desired. you can then let all clients know that the outbox was updated, e.g. by sending them an activity

Als Antwort auf infinite love ⴳ

Steve Bate

Als Antwort auf infinite love ⴳ • 1 Monat her • •

@trwnh The objective is to motivate development of C2S clients by providing access to a significant number of users, even if the server platform hosting those users isn’t ready to support C2S yet. It’s addressing the often-discussed “chicken and egg” dilemma.

@infinite love ⴳ

Als Antwort auf Steve Bate

just small circles 🕊

Als Antwort auf Steve Bate • 1 Monat her • •

@trwnh

Yes, I think it is a good adoption strategy. Kind of an overlay network to ease the transition.

@infinite love ⴳ

⇧

Steve Bate 1 Monat her • •

Steve Bate
1 Monat her • •