I think the #ActivityPub client-to-server API is extremely important and underrated.
-
@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?
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. -
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.
Btw, wrt fediverse we really live in a multiverse by all the different perspectives people have towards what the network should or should not provide. All having different physics.
Where ActivityPub is gravity, and fediverse is entropy and chaos, and universes have become inaccessible over time, past stations.
-
@thisismissem @steve @mariusor @smallcircles @evan
Just checking my memory.. this concept exists already, yes?
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:
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 (github.com)
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.
-
Btw, wrt fediverse we really live in a multiverse by all the different perspectives people have towards what the network should or should not provide. All having different physics.
Where ActivityPub is gravity, and fediverse is entropy and chaos, and universes have become inaccessible over time, past stations.
@smallcircles @steve I understand that people make their own metaphors for how AP works.
-
@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 @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 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?
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:
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 (github.com)
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).
🫧 socialcoding.. (@smallcircles@social.coop)
Attached: 1 image @julian@activitypub.space @evan@cosocial.ca Btw, some time ago in a matrix discussion I sketched how I'd like to conceptually 'see' the social network. Not Mastodon-compliant per se (though it might be via a Profile or Bridge) but back to "promised land". Where the protocol is expressed in familiar architecture patterns and borrows concepts from message queuing, actor model, event-driven architecture, etc. Then as a "Solution designer" I am a stakeholder that wants to be completely shielded from all that jazz. That should all be encapsulated by the protocol libraries and SDK's that are offered in language variants across the ecosystem. #ActivityPub et al is a black box. I can directly start modeling what should be exchanged on the bus, and I can apply domain driven design here. And if I have a semantic web part of my app I'd use linked data modeling best-practices. I would have power tools like #EventCatalog and methods like #EventModeling. https://www.eventcatalog.dev/features/visualization https://eventmodeling.org/
social.coop (social.coop)
