Conversation

Notices

1. Embed this notice
   🫧 socialcoding.. (smallcircles@social.coop)'s status on Friday, 20-Feb-2026 06:09:00 JST 🫧 socialcoding..

   • Evan Prodromou
   • Sean Tilley

   @julian @deadsuperhero @evan

   Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).

   I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.

   If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.

   There's so much confusion on "where does the protocol end vs. where does my app design start".

   SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 20-Feb-2026 06:08:58 JST Evan Prodromou

     in reply to

     • Sean Tilley

     @smallcircles @julian @deadsuperhero we call them collections.

     https://www.w3.org/TR/activitypub/#collections

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 20-Feb-2026 23:37:04 JST Evan Prodromou

     in reply to

     • Steve Bate

     @steve @smallcircles The `inbox` and `outbox` are both sequences ordered by time. I think that should meet your requirements for a 'timeline'?

     I think it's fair to call the outbox the actor's 'feed'? It is a feed of all their activities.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Friday, 20-Feb-2026 23:37:05 JST Steve Bate

     in reply to

     • Evan Prodromou

     @smallcircles @evan An AS2 Collection cannot be a timeline (in general). It’s not even ordered. An AS2 OrderedCollection (a subtype of Collection) might be ordered by time or not, so it’s also not a timeline (in general). When they are ordered by some time value (unspecified in AP) they are often called “streams” in the spec. The Mastodon content timelines are not the same as AP activity streams although a filtered AP stream can be transformed to a content timeline.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Friday, 20-Feb-2026 23:37:06 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Sean Tilley

     @evan @julian @deadsuperhero

     Except when they are called other names instead ;p

     A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).

     Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.

     For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 20-Feb-2026 23:42:17 JST Evan Prodromou

     in reply to

     • Steve Bate

     @steve @smallcircles I also agree that activities are more primary than content objects like notes and images in ActivityPub. That is by design and reflected in the name of the data format, API and federation protocol.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 20-Feb-2026 23:51:33 JST Evan Prodromou

     in reply to

     • Steve Bate

     @steve @smallcircles

     That said, I think it would be great to have reverse chronological ordered collections of objects created by the actor.

     It would be nice to use `streams` like `endpoints`, as an object, and define properties like `notes`, `images`, `places` and so on off of it.

     Unfortunately the loose definition and lack of examples for `streams` makes it hard to use. It's probably better just to define them as top-level properties of the actor.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Friday, 20-Feb-2026 23:56:04 JST Evan Prodromou

     in reply to

     • Steve Bate

     @steve @smallcircles I also agree that having a separate "home timeline" and "notifications timeline" makes sense. There's an open user story for that:

     https://github.com/swicg/activitypub-api/issues/21

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 00:03:24 JST Evan Prodromou

     in reply to

     • Steve Bate

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 00:03:26 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     > I think it's fair to call the outbox the actor's 'feed'?

     The actor's event bus in a pure event based approach. 😃

     Does that break AP? Current fediverse?
     Can AP be considered an event-driven architecture of sorts (or restrained as such in a solution design)?

     I really like the Motivating use cases section of the AS specs, and the primer that sits on the W3C wiki to that. Those might be further formalized so they are applied consistently.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 00:04:28 JST Evan Prodromou

     in reply to

     • Steve Bate

     @smallcircles @steve please comment on the issue!

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 00:04:30 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     The way I see it, this has the wrong stakeholder name of "ActivityPub API client developer" i.e. spec implementer, and a Home Feed is something I may want as a "Solution developer" stakeholder. In other words that library or SDK that offers me the Social API should allow me to model that.

     The user story was also brought up by Mastodon, a Microblogging solution built on top of AP (ideally).

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 00:50:27 JST Evan Prodromou

     in reply to

     • Steve Bate

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 00:50:28 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 00:54:41 JST Evan Prodromou

     in reply to

     • marius
     • Steve Bate

     @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`.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 00:54:42 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @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.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 00:54:43 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @steve frankly I disagree with this point. Servers should be simple. We need to move away from the paradigm of custom purpose ActivityPub servers that Mastodon pushed where the client and server are the same service.

     Timelines should be orthogonal to the ActivityPub specification and, in my opinion, kept well away from it.

     What's the benefit for my client application to know what your server's preferred timeline representation is?

     Let's not go down the path where everything looks like a nail because we really like hammers.

     @smallcircles @evan

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 00:54:44 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @mariusor @smallcircles @evan Yes, it can be done in the client or the server, or both. I’d like to see an interoperable way to define custom timelines (a kind of user-defined timeline algo) that the server maintains. A Mastodon account list timeline is a super simple version of it, but AP could provide something much more powerful (advanced filtering, merging, ranking, …). Ideally, these could be shared and customized further on the client side.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 00:54:46 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @mariusor @smallcircles @evan I’m not sure I completely follow. A timeline is ordered by time. I agree that an unordered collection could be sorted by time to create a timeline. The AP OrderedCollection “stream” is a kind of rigid presorting that anticipates what an AP client would want. However, I also agree that even those could be reordered (by time or otherwise) and/or filtered in the client to provide custom views of the activity stream.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 00:54:46 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @steve yes, that's how I meant it. A client fetches as much of the collection as it can, then applies whatever rules it wants to transform the result into a "timeline" when the user asks for it.

     This however most likely requires local caching of the collection to have decent latency.

     @smallcircles @evan

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 00:54:48 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @steve I think
     we need to emphasize that timelines can be built from regular collections, even unordered ones, by using some intermediate representations specific to the type of timeline that a client wants to render.

     The fact that the specification does not directly support a mapping between a collection and a responsive timeline, *DOES NOT MEAN* one can't be built from it, only that it requires a little more effort on the client side.

     My goto example is how rich mail clients allow responsive mailbox representations on top of a much less expressive collection method that IMAP provides compared to ActivityPub.

     @smallcircles @evan

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 01:13:30 JST Evan Prodromou

     in reply to

     • Steve Bate

     @smallcircles @steve I understand that people make their own metaphors for how AP works.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 01:13:31 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 03:46:21 JST Evan Prodromou

     in reply to

     • Steve Bate

     @smallcircles @steve sure. I am not a fan of the idea that AP is a message-passing system; it's a read-write API.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 03:46:23 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Saturday, 21-Feb-2026 05:09:28 JST Evan Prodromou

     in reply to

     • marius
     • Steve Bate

     @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).

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 05:09:30 JST 🫧 socialcoding..

     in reply to

     • marius
     • Evan Prodromou
     • Steve Bate

     @steve @mariusor @evan

     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. 😅

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 05:09:31 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @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).

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 05:09:32 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @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.

     @smallcircles @evan

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 05:09:33 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @mariusor @smallcircles @evan I *think* it’s
     clear. I agree it’s a kind of “client”, just not necessarily a C2S client.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 05:09:35 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @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.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 05:09:35 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @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?

     @smallcircles @evan

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 05:09:36 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @steve out of curiousity why do you make a difference between a consumer of AcitvityPub (assumedly you mean something that fetches ActivityPub using HTTP GET) and a C2S client?

     My assumption is that if something fetches ActivityPub objects and is capable of rendering it to another representation for its users, that's a client to server client.

     Client to server has two sections: consumer and producer and I think anything that fulfills any of those can be called a C2S client...

     @smallcircles @evan

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Saturday, 21-Feb-2026 05:09:37 JST Steve Bate

     in reply to

     • marius
     • Evan Prodromou

     @smallcircles @mariusor @evan C2S is described (too loosely, but…) in the ActivityPub spec. There is a client and server aspect to C2S. A C2S client is software that uses that protocol/API to interact with an ActivityPub C2S-capable server (general or domain-specific). When I refer to an ActivityPub Client, I mean software using C2S rather than consumers of ActivityPub-related data in general.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Saturday, 21-Feb-2026 05:09:38 JST 🫧 socialcoding..

     in reply to

     • marius
     • Evan Prodromou
     • Steve Bate

     @mariusor @steve @evan

     > And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

     Indeed. Another term that I see people use in different meaning, also when talking about C2S.

     In one meaning the user device is referred to, that you might need to hole-punch with to have a full AP server, or which depends on a server relay.

     And the other meaning as role. As in client/server roles, pure conceptual, and which might swap too.

   • Embed this notice
     marius (mariusor@metalhead.club)'s status on Saturday, 21-Feb-2026 05:09:39 JST marius

     in reply to

     • Evan Prodromou
     • Steve Bate

     @steve apologies, I take "server" in the context of ActivityPub discussion to be an "ActivityPub server", not all the other web-servers involved in the process.

     And when I say "client", I mean a "consumer of ActivityPub", which as you say, many times is also a web server.

     @smallcircles @evan

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 00:43:01 JST Evan Prodromou

     in reply to

     • Steve Bate

     @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:

     https://en.wikipedia.org/wiki/REST

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 00:43:02 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 00:43:03 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @steve

     It is both, like in that diagram draft.. or at least could be considered such (the notes apply to Protosocial musings).

     https://social.coop/@smallcircles/116099511464629495

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 00:46:55 JST Evan Prodromou

     in reply to

     • Steve Bate

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 01:11:52 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate
     • Christine Lemmer-Webber

     @evan

     > 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.

     https://social.coop/@smallcircles/116109447243110037

     @cwebber @steve

   • Embed this notice
     Christine Lemmer-Webber (cwebber@social.coop)'s status on Sunday, 22-Feb-2026 01:11:53 JST Christine Lemmer-Webber

     in reply to

     • Evan Prodromou
     • Steve Bate

     @evan @smallcircles @steve ActivityPub already is a message passing paradigm

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 01:11:54 JST Evan Prodromou

     in reply to

     • Steve Bate

     @smallcircles @steve So, I disagree that we have to adopt a message-passing paradigm for ActivityPub.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 01:36:06 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @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?

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 01:38:46 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @cwebber @smallcircles @steve thanks for that important clarification.

     It does use message-passing, but not exclusively.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 01:49:31 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 01:49:32 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate
     • Christine Lemmer-Webber

     @evan @cwebber @steve

     Which was exactly what I also indicated above, and which aligns to that diagram as well.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 02:14:48 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 02:14:49 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate
     • Christine Lemmer-Webber

     @evan @cwebber @steve

     Not needed. I hope to be able to add some feedback to the AP API repo.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 02:58:55 JST Evan Prodromou

     in reply to

     @smallcircles what do you have in mind, and how is the Fediverse trending in the wrong direction for it?

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 02:58:56 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate
     • Christine Lemmer-Webber

     @evan @cwebber @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 03:08:39 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @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.

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 03:08:41 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou
     • Steve Bate
     • Christine Lemmer-Webber

     @evan @cwebber @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 03:10:25 JST Evan Prodromou

     in reply to

     • Steve Bate
     • Christine Lemmer-Webber

     @smallcircles @cwebber @steve

     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.

   • Embed this notice
     Evan Prodromou (evan@cosocial.ca)'s status on Sunday, 22-Feb-2026 04:05:38 JST Evan Prodromou

     in reply to

     @smallcircles that sounds cool!

   • Embed this notice
     🫧 socialcoding.. (smallcircles@social.coop)'s status on Sunday, 22-Feb-2026 04:05:40 JST 🫧 socialcoding..

     in reply to

     • Evan Prodromou

     @evan

     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.