I think the #ActivityPub client-to-server API is extremely important and underrated.
-
@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.
-
@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 ¯\_(ツ)_/¯
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@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.
@deadsuperhero so, it's a two-sided market -- clients and servers. The traditional mechanism is a "ratchet" -- build up one side, then build up the other, and then build up the first.
So, yes, servers first, then clients, then more servers, more clients, and so on back and forth.
-
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
-
@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).
-
@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 @mariusor @benpate @steve @smallcircles yeah, it's the only way to do it.
But this infrastructure actually is what enables things like the AT Protocol "proxy through my PDS to the bluesky app view" or "proxy through my PDS to a custom feed generator" functionality.
That's how that all works.
-
It is both, like in that diagram draft.. or at least could be considered such (the notes apply to Protosocial musings).
Another issue: Unclear protocol layers.
> I am not a fan of the idea that #ActivityPub is a message-passing system; it's a read-write API.
I'm not sure what a "read-write API" is, really. It 's a fuzzy term, whereas message based systems have well-defined architecture patterns and a body of IT knowledge and practice to apply them in robust communication systems. A 'Message API' has a generic, consistent interface.
The overarching goal of AS/AP should be empowerment of the Solution developer so they can directly focus on building use cases for their application or business domain. They should not have to think about any of the intrinsics of the protocol, like particular GETs and POSTs used to model protocol capabilities in the HTTP transport layer.
Solution design then involves:
0. Model the domain
1. Data modeling, msg formats + validation
2. Define actor msg exchange patterns
3. Document design
--
4. Improve these steps. Add native protocol + tool support over time. -
Another issue: Unclear protocol layers.
> I am not a fan of the idea that #ActivityPub is a message-passing system; it's a read-write API.
I'm not sure what a "read-write API" is, really. It 's a fuzzy term, whereas message based systems have well-defined architecture patterns and a body of IT knowledge and practice to apply them in robust communication systems. A 'Message API' has a generic, consistent interface.
The overarching goal of AS/AP should be empowerment of the Solution developer so they can directly focus on building use cases for their application or business domain. They should not have to think about any of the intrinsics of the protocol, like particular GETs and POSTs used to model protocol capabilities in the HTTP transport layer.
Solution design then involves:
0. Model the domain
1. Data modeling, msg formats + validation
2. Define actor msg exchange patterns
3. Document design
--
4. Improve these steps. Add native protocol + tool support over time.@smallcircles @steve it's ok if you haven't heard of a REST API. It's an API that uses HTTP for reading and writing data. Wikipedia has a good
article about it: -
@smallcircles @steve it's ok if you haven't heard of a REST API. It's an API that uses HTTP for reading and writing data. Wikipedia has a good
article about it:@smallcircles @steve one anti-pattern I dislike seeing in ActivityPub discussions is that only one interaction defined in the ActivityPub spec is valid: an HTTP POST to an actor's `inbox` for server-to-server interactions.
We can use HTTP GET to fetch additional data about objects, actors and collections.
