I think the #ActivityPub client-to-server API is extremely important and underrated.
-
@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).
🫧 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)
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.
🫧 socialcoding.. (@smallcircles@social.coop)
#ThoughtProvoker :blobhyperthink: The current fediverse is an evolutionary dead-end for 2 reasons: 1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay. 2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out. Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with. To avoid fedi to become less and less attractive to newcomers, we must now consider: “Why do we want to grow the open social web, and for whom?” -- @ben@werd.social http://coding.social/blog/shared-ownership/
social.coop (social.coop)
-
> 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.
🫧 socialcoding.. (@smallcircles@social.coop)
#ThoughtProvoker :blobhyperthink: The current fediverse is an evolutionary dead-end for 2 reasons: 1. It has painted itself in a small niche of decentralizing typical social media use cases, by means of post-facto interop and the introduction of protocol decay. 2. Lacking a proper grassroots standardization process, and with the primary mechanism for fediverse extension being only post-facto interoperability, there is no way out. Congratulations to the early adopters, who managed to "cross the chasm" with their own app platforms. It took true grit to become deep #ActivityPub experts, and plug holes needed for your app, but you have made it. Post-facto interop works in your favor now. You are unrestrained to productively add more features in your app, and put them on the fedi wire for others to deal with. To avoid fedi to become less and less attractive to newcomers, we must now consider: “Why do we want to grow the open social web, and for whom?” -- @ben@werd.social http://coding.social/blog/shared-ownership/
social.coop (social.coop)
@smallcircles @cwebber @steve hey, Arnold.
I don't think argument from ignorance is a good way to have a discussion.
I chose to take you at your word that you didn't know what a "read-write API" is, and that you couldn't figure it out from context clues, so I dropped a link to Wikipedia.
What would you have done, if you were me?
-
@evan @smallcircles @steve ActivityPub already is a message passing paradigm
@cwebber @smallcircles @steve thanks for that important clarification.
It does use message-passing, but not exclusively. I'll update my reply.
-
@cwebber @smallcircles @steve thanks for that important clarification.
It does use message-passing, but not exclusively. I'll update my reply.
Which was exactly what I also indicated above, and which aligns to that diagram as well.
-
@smallcircles @cwebber @steve hey, Arnold.
I don't think argument from ignorance is a good way to have a discussion.
I chose to take you at your word that you didn't know what a "read-write API" is, and that you couldn't figure it out from context clues, so I dropped a link to Wikipedia.
What would you have done, if you were me?
So why don't you use the word REST? I never encountered "read-write API". It is an informal term.
But that is not the point. You can have a REST API, fine. But that says nothing in itself. What does it expose? You might say "Duh.. ActivityPub!" but that is not very informative either. There is the notion of message exchange, and of an addressing mechanism, indicating higher level abstractions that conform to well-known architecture patterns, and would allow us to have more productive communication, delve less in implementation details and confusions of protocol behavior with solution design functionality, for starters.
-
@smallcircles @cwebber @steve awesome.
So, would you like me to review your diagram and give comments? I don't know what you're looking for from me in this conversation.
-
@smallcircles @cwebber @steve awesome.
So, would you like me to review your diagram and give comments? I don't know what you're looking for from me in this conversation.
-
@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.
-
@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.
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.
-
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 what do you have in mind, and how is the Fediverse trending in the wrong direction for it?
-
So why don't you use the word REST? I never encountered "read-write API". It is an informal term.
But that is not the point. You can have a REST API, fine. But that says nothing in itself. What does it expose? You might say "Duh.. ActivityPub!" but that is not very informative either. There is the notion of message exchange, and of an addressing mechanism, indicating higher level abstractions that conform to well-known architecture patterns, and would allow us to have more productive communication, delve less in implementation details and confusions of protocol behavior with solution design functionality, for starters.
@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.
