I think the #ActivityPub client-to-server API is extremely important and underrated.

@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

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

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

@evan @steve

Well, but a part of the specs can certainly be considered a message bus with channels conceptually.

Channel is the name that AsyncAPI uses, which maps to domain aggregates and actor streams.

But considering things purely event-based is stretching it, and may be better to discern between commands and events.

@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

@smallcircles @steve maybe? I guess you could consider the `sharedInbox` to be like that.

I think that activities sent to the API by a client are kind of like commands, but they can also be events that happened on a different system.

If I got an achievement in a game, and that was sent as an activity to the API, it's more like an event notification than a command.

@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).

@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

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

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

@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

@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

@evan @steve

Rather than sharedInbox I was more thinking that by implementing the HTTP API and msg exchanges in a well-prescribed manner, these would effectively model an event bus conceptually. After which you can talk about it as a higher abstraction that exists, and not get lost in the reeds of the impl details anymore.

@smallcircles @steve sure. I am not a fan of the idea that AP is a message-passing system; it's a read-write API.

@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

@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

@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@cosocial.ca 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.

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

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