I think the #ActivityPub client-to-server API is extremely important and underrated.
Fediverso
120
Posts
12
Posters
117
Views
-
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. 😅
-
@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
-
@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 ¯\_(ツ)_/¯
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
-
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).
-
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.
-
@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.
@smallcircles @steve So, I disagree that we have to exclusively adopt a message-passing paradigm for ActivityPub.
EDIT: note that it's exclusive.
-
@smallcircles @steve So, I disagree that we have to exclusively adopt a message-passing paradigm for ActivityPub.
EDIT: note that it's exclusive.
@evan @smallcircles @steve ActivityPub already is a message passing paradigm
-
@evan @smallcircles @steve ActivityPub already is a message passing paradigm
> it's ok if you haven't heard of a REST API.
Well, you be you. I consider this a 'typical Evan remark' by now, dripping with sarcasm. It is a weird fit for someone who want to lead the #SocialCG efforts, I'd say.
Ah well. What I am talking about is architecture and design, and all the things that allow people to easily form a clear mental picture on how things fit together, wrap their head around the fediverse.
A HTTP interface is a very low-level thing, and clearly but one of the many moving parts that play a role in #ActivityPub based solution development.
Never defining this well, and having the documentation be scattered all across the fediverse in 1,001 random locations doesn't help. Meanwhile the dev talk that is going on for years remains very inefficient due to endless Babylonian speech confusion.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@smallcircles that sounds cool!
-
So the area where my plans go I call "Residential social networking", geo-fenced but inter-connected social networking circles that cover a city, town, or rural area, and which enable their residents to not only create content on the network, but the dynamic apps and services based on local needs that exist in the area. The intent of a residential social network is to engage people *offline* and in activities that support the local economy. Or rather strengthens the Circles of Sustainability in SX terminology:
https://coding.social/blog/reimagine-social/#circles-of-sustainability
And all this should be a relatively low-code affair, directly accessible already for a first-time dev. This requires having a mature open standards based healthy technology foundation and thriving ecosystem.
I am a developer, though with rusty coding skills these days, and I might have started a fedi app design in 2018 or so. But this would not have led to the desired outcome, just throw one more app-centric software in the mix.
-
Some implementations skip some of these steps, because they are focused only on processing messages as they arrive. So, I am reluctant to overemphasize the message processing at the expense of the personal datastore functionality.
-
@smallcircles @cwebber @steve I'm fine with that.
However, I think ActivityPub builds up persistent state on the server side which can be read and used by other processors.
For example, when I `Like` something, it goes into my `liked` collection, and the activity goes into the `likes` for that object. The `Like` activity goes into my `outbox` and others' `inbox`. People can review that information and use it.
-
@smallcircles what do you have in mind, and how is the Fediverse trending in the wrong direction for it?
-
Thank you, that is nice to hear. I am however not an expert, am but a humble generalist and a person who'd love to be in that Solution developer stakeholder role. Who however does not see the fediverse trend in a direction where I'd adopt the technology for what I have in mind. Drifting away from "the promise" that I read in the #ActivityPub specs in 2017, and which at the time made me decide to lend a helping hand here and there as #SocialHub facilitator and tech advocate.
-
@smallcircles @cwebber @steve I would personally really appreciate that. I also think it'd be helpful for the ecosystem. I like that you combine a high-level social and technical approach to discussions of ActivityPub and the Social Web with an almost encyclopedic knowledge of the details. It's a rare combination and extremely valuable.
