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

[steve@social.technoetic.com]

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

[smallcircles@social.coop]

@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@social.coop]

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

[thisismissem@hachyderm.io]

@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

[mariusor@metalhead.club]

@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

[evan@cosocial.ca]

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

[evan@cosocial.ca]

@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

[benpate@mastodon.social]

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

@benpate

With all the standard warnings around proxies!

@mariusor @thisismissem @steve @smallcircles

[evan@cosocial.ca]

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