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

[evan@cosocial.ca]

@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@metalhead.club]

@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

[evan@cosocial.ca]

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

[evan@cosocial.ca]

@smallcircles @steve I understand that people make their own metaphors for how AP works.

[evan@cosocial.ca]

@steve @mariusor @smallcircles so, a client could send some kind of definition for the timeline ("only Create/Image or Create/Video activities from the inbox where the image is tagged 'caturday'") and then the server sorts data into that timeline? That sounds like a neat feature.

However, I think there might be some definitions that are so common that we could just define them in a spec, like `notifications`.

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