Benvenuto nel Poliverso

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

reshared this

in reply to Steve Bate

just small circles 🕊

in reply to Steve Bate • 2 mesi fa • •

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

in reply to Steve Bate

silverpill

in reply to Steve Bate • 2 mesi fa • •

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.

in reply to silverpill

Steve Bate

in reply to silverpill • 2 mesi fa • •

@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

in reply to Steve Bate

silverpill

in reply to Steve Bate • 2 mesi fa • •

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.

in reply to silverpill

infinite love ⴳ

in reply to silverpill • 2 mesi fa • •

@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

in reply to silverpill

Raphael Lullis

in reply to silverpill • 2 mesi fa • •

> 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?

in reply to Raphael Lullis

Raphael Lullis

in reply to Raphael Lullis • 2 mesi fa • •

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?

in reply to Raphael Lullis

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

in reply to Raphael Lullis • 2 mesi fa • •

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.

Questa voce è stata modificata (2 mesi fa)

in reply to לָקס (לא לותור)

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

in reply to לָקס (לא לותור) • 2 mesi fa • •

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.

in reply to לָקס (לא לותור)

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

in reply to לָקס (לא לותור) • 2 mesi fa • •

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.

in reply to לָקס (לא לותור)

Raphael Lullis

in reply to לָקס (לא לותור) • 2 mesi fa • •

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

in reply to Raphael Lullis

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

in reply to Raphael Lullis • 2 mesi fa • •

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.

in reply to Steve Bate

infinite love ⴳ

in reply to Steve Bate • 2 mesi fa • •

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.

in reply to infinite love ⴳ

infinite love ⴳ

in reply to infinite love ⴳ • 2 mesi fa • •

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

in reply to infinite love ⴳ

Steve Bate

in reply to infinite love ⴳ • 2 mesi fa • •

@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 ⴳ

in reply to Steve Bate

just small circles 🕊

in reply to Steve Bate • 2 mesi fa • •

@trwnh

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

@infinite love ⴳ

in reply to Steve Bate

The Nexus of Privacy

in reply to Steve Bate • 2 mesi fa • •

very interesting thinking, thanks for writing it up in such detail!

in reply to The Nexus of Privacy

bengo

in reply to The Nexus of Privacy • 2 mesi fa • •

@thenexusofprivacy yes good write up Steve! Glad we’re aligned a bit.

bengo.is/blogging/2024-10-03-t…

@The Nexus of Privacy

⇧

Steve Bate 2 mesi fa • •

Steve Bate
2 mesi fa • •