I think the #ActivityPub client-to-server API is extremely important and underrated.
-
@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 @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
-
@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...
-
@smallcircles @steve I know what an "event bus" is but I don't think it applies here. Usually it means a global data structure that attached processes can add events to and read events from. We don't have that in ActivityPub.
I think it's fair to say that activities are like events.
I also like the use cases and primer.
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 @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 @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?
-
@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?
@mariusor @smallcircles @evan I *think* itβs
clear. I agree itβs a kind of βclientβ, just not necessarily a C2S client. -
@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 @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.
-
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.
@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.
-
@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.
@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 @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.
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.
-
@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).
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 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...
@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 @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 @steve @mariusor @smallcircles @evan i'm not sure proxyUrl does what I'm thinking of here
-
@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.
@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 @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?
-
@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
-
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.
-
@smallcircles @steve sure. I am not a fan of the idea that AP is a message-passing system; it's a read-write API.
It is both, like in that diagram draft.. or at least could be considered such (the notes apply to Protosocial musings).
-
@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
@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 Β―\_(γ)_/Β―
-
@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 Β―\_(γ)_/Β―
@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.
