Mastodawn

Sean Tilley Feb 18

I think the #ActivityPub client-to-server API is extremely important and underrated. I’m glad to see the SWF and W3C group prioritizing it, because I think it has the potential to fix something that’s kind of broken on the #Fediverse: too many accounts, on too many platforms that really ought to be clients.

Here’s the rub, though: you need the big players in the space to support it. Mastodon needs to support it. Pixelfed and PeerTube need to support it.

So, how do you get the big existing projects to all implement it? How do you justify it?

Sean Tilley Feb 18

Would love to hear what @evan thinks about this.

Evan Prodromou Feb 19

I am heart to heart with you on this, friend.

Evan Prodromou Feb 19

@deadsuperhero so, here's my best bet. I can be wrong!

1. Get some servers to implement the API well.
2. Get some must-have clients that run on those servers. This shows the value of the API.
3. Our leading servers shift to supporting it.

That may work; I don't know. It's my best bet right now!

I want to note that WordPress is working on the API!

Sean Tilley Feb 19

@evan Yeah, I mostly agree with this. It’s just that the buy-in is a little bit of a chicken and egg problem. You need servers to adopt it, but you need a compelling first mover. Bonfire, maybe?

The spec definitely needs love, too. I think one of the harder things is building a timeline out of inbox activities. I feel like maybe a future version of the API could specify timelines somehow, whether it’s an endpoint or some kind of basic query? Maybe there’s even a way to implement alternative timelines at that level?

These are all just guesses on my part, but I feel like this could be a gateway to universal custom feeds.

Does the inbox have to map to a timeline, specifically? Mastodon called this out as being difficult to do because you would have to real-time parse the inbox every time you wanted to load the timeline.

Of course one could always reduce the inbox into a single timeline and serve that instead, but then we're braching out with our own proprietary APIs again.

Is that ok?

@[email protected] @[email protected]

Sean Tilley Feb 19

@julian @general @evan Again, this is sort of why I’m advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you’re saying with some kind of representation of a timeline. Even if it’s just plain old algorithmic time-sort.

On the other hand, however... If the ActivityPub API were used in an S2S context, enabling something like NodeBB to send activities on behalf of a Mastodon user, then it wouldn't matter that there is no GET /timeline, because all you need is POST /outbox and the Mastodon API handles their end.

Vice versa, NodeBB would use its own API to render a /world feed.

@[email protected] @[email protected]

🫧 socialcoding..Feb 19

@julian @deadsuperhero @evan

Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).

I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.

If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.

There's so much confusion on "where does the protocol end vs. where does my app design start".

SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.

Evan Prodromou Feb 19

@smallcircles @julian @deadsuperhero we call them collections.

https://www.w3.org/TR/activitypub/#collections

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

🫧 socialcoding..Feb 19

@evan @julian @deadsuperhero

Except when they are called other names instead ;p

A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).

Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.

For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.

Steve Bate Feb 20

@smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.

@steve I think
we need to emphasize that timelines can be built from regular collections, even unordered ones, by using some intermediate representations specific to the type of timeline that a client wants to render.

The fact that the specification does not directly support a mapping between a collection and a responsive timeline, *DOES NOT MEAN* one can't be built from it, only that it requires a little more effort on the client side.

My goto example is how rich mail clients allow responsive mailbox representations on top of a much less expressive collection method that IMAP provides compared to ActivityPub.

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan I’m not sure I completely follow. A timeline is ordered by time. I agree that an unordered collection could be sorted by time to create a timeline. The AP OrderedCollection “stream” is a kind of rigid presorting that anticipates what an AP client would want. However, I also agree that even those could be reordered (by time or otherwise) and/or filtered in the client to provide custom views of the activity stream.

@steve yes, that's how I meant it. A client fetches as much of the collection as it can, then applies whatever rules it wants to transform the result into a "timeline" when the user asks for it.

This however most likely requires local caching of the collection to have decent latency.

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan Yes, it can be done in the client or the server, or both. I’d like to see an interoperable way to define custom timelines (a kind of user-defined timeline algo) that the server maintains. A Mastodon account list timeline is a super simple version of it, but AP could provide something much more powerful (advanced filtering, merging, ranking, …). Ideally, these could be shared and customized further on the client side.

@steve frankly I disagree with this point. Servers should be simple. We need to move away from the paradigm of custom purpose ActivityPub servers that Mastodon pushed where the client and server are the same service.

Timelines should be orthogonal to the ActivityPub specification and, in my opinion, kept well away from it.

What's the benefit for my client application to know what your server's preferred timeline representation is?

Let's not go down the path where everything looks like a nail because we really like hammers.

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan I think you read something other than what I wrote. 😀. I’m describing *user-defined* timelines where the heavy lifting is done in a server. That server would be (or could be) *general purpose* and not specific to an activity domain. I definitely wasn’t suggesting a monolithic, tightly-coupled client/server architecture. I want my timeline definitions to be portable and interoperable.

@steve apologies, I take "server" in the context of ActivityPub discussion to be an "ActivityPub server", not all the other web-servers involved in the process.

And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

@smallcircles @evan

🫧 socialcoding..Feb 20

@mariusor @steve @evan

> And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

Indeed. Another term that I see people use in different meaning, also when talking about C2S.

In one meaning the user device is referred to, that you might need to hole-punch with to have a full AP server, or which depends on a server relay.

And the other meaning as role. As in client/server roles, pure conceptual, and which might swap too.

Steve Bate Feb 20

@smallcircles @mariusor @evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.

🫧 socialcoding..Feb 20

@steve @mariusor @evan

Yes. And again same here :)

Just pointing out the Babylonian speech confusion that we haven't overcome yet.

@steve out of curiousity why do you make a difference between a consumer of AcitvityPub (assumedly you mean something that fetches ActivityPub using HTTP GET) and a C2S client?

My assumption is that if something fetches ActivityPub objects and is capable of rendering it to another representation for its users, that's a client to server client.

Client to server has two sections: consumer and producer and I think anything that fulfills any of those can be called a C2S client...

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan C2S has client-side and server-side aspects (different, but overlapping, behavioral requirements, etc.). Both sides consume *and* produce AP data (pull and push for S2S, currently only pull for C2S). Fetching AP data (URI dereferencing) is common to both C2S and S2S.

@steve yes, but something dumb that only fetches a URL and converts the resulting ActivityPub into a valid other type of representation is a valid client in my opinion. That's what I mean, was that unclear?

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan I *think* it’s
clear. I agree it’s a kind of “client”, just not necessarily a C2S client.

@steve OK, but why?

I feel like I explained my position relatively clearly, I would like to understand yours, even though I feel some animosity has started to crop up.

@smallcircles @evan

Steve Bate Feb 20

@mariusor @smallcircles @evan No animosity here. However, I’m not sure how to explain it more clearly. I’m referring to C2S as described in chapter 6 of the ActivityPub specification (and the conformance profiles in Section 2.1). It sounded to me like you’re using a more general definition of “client”, which is fine, just different in significant ways (if it only dereferences and renders AP data).

🫧 socialcoding..Feb 20

@steve @mariusor @evan

He he, language is hard. A case of terminology overload and clashing terms. Domain driven design has the clearly defined bounded context here which is the scope within which terms are valid. Forming a consistency boundary. These context lines are blurred in fediverse talk. 😅

Evan Prodromou Feb 20

@smallcircles @steve @mariusor

I think in particular the terms "publisher" and "consumer" from AS2 and "client" and "server" from AP don't always map cleanly, especially with HTTP POST requests.

When a client delivers an activity to the actor's outbox, the client is the publisher of that activity, and the server is the consumer.

Same when a sending server (publisher) delivers an activity to a receiving server (consumer).

Emelia 👸🏻Feb 20

@steve @mariusor @smallcircles @evan this is a huge thread, but off-cuff comment: C2S will need a "proxy" where you can fetch a remote object **with** identity/authentication

@thisismissem I have just implemented that for the GoActivityPub servers and it's easier than it sounds.

The only important step required is to convert the client authorization token (presumably an OAuth2 bearer token) to a valid actor and then further to a valid Private Key with which to sign the remote request. After that the only thing remaining is to pipe verbatim the received response to the client...

@steve @smallcircles @evan

Emelia 👸🏻Feb 20

@mariusor @steve @smallcircles @evan well, your server *knows* it's access token to user mapping, so then you're just doing authorised fetch as that actor from server side

@thisismissem which is what proxyUrl is supposed to do, right?

Did you mean it in a different way?

@steve @smallcircles @evan

Ben Pate 🤘🏻Feb 20

@thisismissem @steve @mariusor @smallcircles @evan

Just checking my memory.. this concept exists already, yes?

https://www.w3.org/wiki/ActivityPub/Primer/proxyUrl_endpoint

Are you just saying that the new API spec should include this? Or am I missing something?

ActivityPub/Primer/proxyUrl endpoint - W3C Wiki

Evan Prodromou Feb 20

@benpate @thisismissem @steve @mariusor @smallcircles

Yes, proxyUrl already exists. There's a use case here:

https://github.com/swicg/activitypub-api/issues/10

The only other way I've seen this use case discussed is with client-side HTTP Signature keys. There's some kind of negotiation between the server and the client, and then the client can make requests to remote servers using HTTP Signature and a key it controls.

Remote object access · Issue #10 · swicg/activitypub-api

"As an ActivityPub client developer, I want a reliable method for accessing objects on remote servers with the user's authorization, so I can read private or followers-only data."

GitHub

Emelia 👸🏻Feb 20

@evan @benpate @steve @mariusor @smallcircles my understanding of proxyUrl is that it's just fetching a remote object, but without forwarding authorization

For many cases you want to forward the request as the authenticated user to the remote server, not doing the request anonymously

@thisismissem it's not explicitly saying to forward authorization, but to me that's implied from "require authentication":

proxyUrl: Endpoint URI so this actor's clients may access remote ActivityStreams objects which require authentication to access

https://w3c.github.io/activitypub/#proxyUrl

@evan @benpate @steve @smallcircles

ActivityPub

Evan Prodromou Feb 20

@mariusor I have implemented it requiring OAuth on one side and using HTTP Signature on the other. I think you need to use the user's authorization for private content or to respect personal blocks. It sucks for caching but ¯\_(ツ)_/¯

@thisismissem @benpate @steve @smallcircles

@evan yes, that's how I did it too, only in my case the private key of the actor that is authorized by OAuth2 token is used to generate the signature for the proxy fetch. This makes it that servers that implement object ACLs based on the recipients list (which GoActivityPub servers are) are not serving 403s for fetches.

Ben Pate 🤘🏻Feb 20

Yeah, this is how I'd expect it to work (with the possible addition of *also* allowing cookie auth on the client side)

But yeah. Locally authenticated user from my client -> my server, then HTTP signature from my server -> your server

@evan @mariusor @thisismissem @steve @smallcircles

Evan Prodromou Feb 20

With all the standard warnings around proxies!

@mariusor @thisismissem @steve @smallcircles

Emelia 👸🏻Feb 20

@evan @mariusor @benpate @steve @smallcircles yeah, it's the only way to do it.

But this infrastructure actually is what enables things like the AT Protocol "proxy through my PDS to the bluesky app view" or "proxy through my PDS to a custom feed generator" functionality.

That's how that all works.

Emelia 👸🏻Feb 20

@benpate @steve @mariusor @smallcircles @evan i'm not sure proxyUrl does what I'm thinking of here