Post · bonfire.cafe

@deadsuperhero@social.wedistribute.org · 2 months ago

I think the #ActivityPub client-to-server API is extremely important and underrated. I’m glad to see the SWF and W3C group prioritizing it, because I think it has the potential to fix something that’s kind of broken on the #Fediverse: too many accounts, on too many platforms that really ought to be clients.

Here’s the rub, though: you need the big players in the space to support it. Mastodon needs to support it. Pixelfed and PeerTube need to support it.

So, how do you get the big existing projects to all implement it? How do you justify it?

We Distribute

#activitypub #fediverse

django

@django@social.coop · 2 months ago

@deadsuperhero I don’t necessarily think we need the big players. Especially where those projects have stated their intent to stick to micro, or photo -blogging, with limited interop.

django

@django@social.coop · 2 months ago

@deadsuperhero I don’t necessarily think we need the big players. Especially where those projects have stated their intent to stick to micro, or photo -blogging, with limited interop.

django

@django@social.coop · 2 months ago

@deadsuperhero imho, building out c2s will allow new projects to bootstrap the front end, and focus on new application domains, or support multiple activity/object types.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

Here’s the thing: Mastodon already has a really good API. There’s a whole ecosystem of clients around it, to the point that many other Fediverse implementations adopted it, so that they can use the apps.

I don’t think this is a bad thing in and of itself. But, if we want projects like Mastodon to support it, the value proposition has to provide things that the Mastodon API does not.

I think a killer feature to focus on would be identity management.

Nik

@nikclayton@mastodon.social · 2 months ago

@deadsuperhero

"Mastodon already has a really good API".

Not really. It's inconsistent, incompletely documented, stringly typed, has a poor backward/forward compatibility story, and no clean way for other servers to extend the API without risking breakage.

E.g., https://github.com/pachli/pachli-android/issues/2043

All of these are fixable, but Mastodon GmbH has no incentive to fix them.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@deadsuperhero

Yes. Mastodon has always given their own product decisions precedence over healthy evolution of the ecosystem as a whole. And despite many people being very frustrated about that, I think this is perfectly valid decision. After all choosing to implement an open standard should not come with the obligation to maintain/evolve that standard. It is only smart to do so, and Mastodon did this with an eye on their own product development.

Imho it is really the broader dev ecosystem that is at fault in letting the fedi be taken hostage by past Mastodon decisions, making them the post-facto #interoperability leader. As for Mastodon API I'd argue that its users are not on the fediverse. They are on Mastodon.

Identity management may be killer feature, but only when first a sound #ActivityPub foundation is in place. AS/AP isn't as-yet robust enough to be the future of social networking. I'd say the extensibility mechanism is killer feature, and having SDK's and devtools for that.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@deadsuperhero

Right now extensibility of #ActivityPub shapes up as custom app-by-app app-centric development where individual devs just pragmatically throw new stuff on the wire, and when their app gains any popularity or other apps to integrate in a similarish application, things are bolted onto that in random ways. That whole story really constitutes a Big Ball of Mud anti-pattern that only introduces protocol decay, tech debt, and whack-a-mole programming, that is very hard to get rid of once there exists an installed base.

The reason that we do things that way is very understandable. It works in a grassroots environment where indivualist devs find it very hard and not valuable to collaborate at scale in what amounts to a kind of design-by-consensus process. But it comes at a high cost, where interoperability is basically out the door and any app has to be shaped as a pretzel and adopt all the quirks introduced by predecessors in a particular app domain to fit itself on the wire.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@deadsuperhero

It does not need to be that way. I am quite happy after all (after being initially frustrated) by how #ATProto has disrupted things, and opened the eyes of devs in the #ActivityPub ecosystem that we must act or lose out (stay niche, which may be fine too) to the Atmoshpere and how it enables devs to focus on service and product delivery instead of low-level wire plumbing and continuous breakages.

ATProto also shows the way that we can now follow on the #fediverse to catch up again: cocreate a similar robust basis for people to build on. #Bluesky had the advantage of a greenfield start and dedicated team unburdened by past decisions. And they build this whole Lexicon system and ways to introspect functionality.

We can do that too, solve the #LinkedData conundrum, and create an extensibility mechanism that allows devs to focus on service modeling. The more introspection this mechanism allows for, the less design-by-consensus is required, easing expansion to new domains.

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@smallcircles @deadsuperhero I've quietly been borrowing ideas from AT Protocol for ActivityPub:
- declaring moderation actors
- supporting content labels (first party abd third party)
- looking at how custom feeds, DIDs and other tech may translate across

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@thisismissem @deadsuperhero

I was looking at #ForgeFed which is a very sizable #ActivityPub extension (constituting the "Code forge" app domain in app-centric view, but arguably "Software development" top-level business domain in a service-oriented fedi).

The way that things are modeled here adheres more to the actor model where there's a Factory actor, which in turn creates resource actors that expose various sub-domains. For instance for the management of Issues and PR's there's a TicketTracker actor to obtain via a Factory actor on a forge instance. Though I'm not sure whether I'd modeled that in similar fashion, it is a fascinating direction where we focus much more on good protocol extension design.

All in all AS/AP offers a very granular foundation that allows for very interesting architectures, if only we dare explore them and do not dogmatically stick to some engrained notion how "social media" ought to be. I see #SocialMedia as but a small subset of #SocialNetworking.

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@smallcircles @deadsuperhero not just that, but if we evolve our understanding of what AP *could* be beyond what Mastodon *needs* AP to be.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

Bluesky absolutely got it right with ATproto: you can make any kind of client, not just microblogging, and it will seamlessly work with your Bluesky identity. Everything you post goes into your personal storage, and the clients that know how to interpret special data types are able to reach into your PDS and the timelines you’re following to present that stuff.

ActivityPub API needs to follow a similar story.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

Why do I care so much about this? A few reasons.

One, I don’t want to have a dozen different accounts across separate types of applications on the same network. I really hate that, it’s messy and does nothing to unify my identity across all the spaces I’m active on.

Two, a seamless login across the entire network could be very powerful for discovery. Instead of having to find people to follow on Pixelfed and PeerTube, the folks I’m already connected to would already be there, right when I sign in.

Three, we could develop a new generation of rich clients that all do really different things, but all tie back to a singular identity. “Sign In With ActivityPub” could work for the entire network, and it wouldn’t have to be a hack using Mastodon’s API.

Brendan Jones

@Brendanjones@fosstodon.org · 2 months ago

@deadsuperhero I don’t want a unified experience across services. I use Mastodon, Loops, Pixelfed etc for completely different things. I follow different people. Different topics (hashtags).

My point being, there has to be a layer to separate the services somewhere. Right now it’s at the account level, which honestly is fine for me because hey I’m used to signing in separately to Twitter, Instagram, etc.

But if accounts are unified, at what level do you separate the services?

Brendan Jones

@Brendanjones@fosstodon.org · 2 months ago

@deadsuperhero Is your idea that you have one unified account with one list of follows? Because then for each service I’d want to select a subset of follows from whom I’d like to see posts.

For example, imagine I used Friendica or another Facebook-analogous service, and Mastodon. If I had a unified Fediverse account I’d only want to follow some of my friends and family on Mastodon, and I’d want to see almost zero of the Mastodon people on Friendica.

flpvsk

@flpvsk@mastodon.social · 2 months ago

@Brendanjones

The unified account covers both cases. The current system does not.

With a unified route you can still have multiple accounts. If you prefer to keep things separate — you can.

If the unified account is not supported, not you'd prefer that, there's no way unfortunately.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

Finally, I think there are some serious improvements we can bring to fill the gaps that the current spec is missing. What if we had a standard endpoint for notifications?

Suppose we also developed a standard way of doing timelines as well, and used it as a springboard for custom feeds that could work with any app, any client, and any server?

There’s a lot of useful stuff we could do here to make the whole thing extremely compelling for anyone building on this network.

julian

@julian@activitypub.space · 2 months ago

@deadsuperhero@social.wedistribute.org thanks for posting.

I think what makes it hard for existing implementations to support it is that if you're not AS-native (that is, consuming ActivityStreams activities directly without converting to some normalized form for your software), then it's possibly a big lift to "level up" your code to do it that way.

Like Mastodon, NodeBB ingests the activity, extracts the juicy bits, and discards the rest. It makes it hard to later on recall an activity because they were ephemeral (at least in our chain of custody).

So an entire new middleware layer needs to be built for NodeBB to catalog and store (and later, recall) these activities for ActivityPub API support.

Correct me if I'm wrong @evan@cosocial.ca!

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

@julian @general @evan Yeah, this is a really good point. It’s not currently super straightforward to implement, and as you’ve rightly pointed out, there’s a bunch of extra things that need to be built to support such a thing.

I almost wonder whether there’s a “minimum viable implementation”, like something that just handles authentication and low-level posting to the outbox / fetching from the inbox that might work as a starting point?

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

Would love to hear what @evan thinks about this.

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@deadsuperhero

I am heart to heart with you on this, friend.

GIF

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@deadsuperhero so, here's my best bet. I can be wrong!

1. Get some servers to implement the API well.
2. Get some must-have clients that run on those servers. This shows the value of the API.
3. Our leading servers shift to supporting it.

That may work; I don't know. It's my best bet right now!

I want to note that WordPress is working on the API!

django

@django@social.coop · 2 months ago

@evan @deadsuperhero there are also a number of frameworks that have already signalled interest or intent in supporting the API:
#Bonfire #FedBox #Fedify #Emissary

marius

@mariusor@metalhead.club · 2 months ago

@django I would object to FedBOX having "signaled interest or intenent".

FedBOX, and the GoActivityPub library that's been built upon, simply "support" client to server and have been since it's inception 7-8 years ago.

@evan @deadsuperhero

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

@django @evan Yep, I’m a big fan of all of these! I’m particularly interested in Bonfire and Emissary, but thrilled to hear about Fedify.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

julian

@julian@activitypub.space · 2 months ago

Does the inbox have to map to a timeline, specifically? Mastodon called this out as being difficult to do because you would have to real-time parse the inbox every time you wanted to load the timeline.

Of course one could always reduce the inbox into a single timeline and serve that instead, but then we're braching out with our own proprietary APIs again.

Is that ok?

@deadsuperhero@social.wedistribute.org @evan@cosocial.ca

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@julian @deadsuperhero We actually have a meeting tomorrow if either of you wants to come.

https://www.w3.org/events/meetings/3432cf4c-a9fe-4f72-8de5-fa6809b57767/20260219T110000/

W3C

19 February 2026 | ActivityPub API Task Force Meeting | Calendar

The World Wide Web Consortium (W3C) is an international community where Member organizations, a full-time staff, and the public work together to develop Web standards.

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

@evan @julian Dang, that’s right when I have class. I’ll probably be home like 20 minutes after it ends. 😅

julian

@julian@activitypub.space · 2 months ago

@evan@cosocial.ca okay, I'll see you there!

Sean Tilley

@deadsuperhero@social.wedistribute.org · 2 months ago

@julian @general @evan Again, this is sort of why I’m advocating for supporting timelines as a concept in the ActivityPub API. Instead of repeatedly parsing the inbox, we could do exactly what you’re saying with some kind of representation of a timeline. Even if it’s just plain old algorithmic time-sort.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@deadsuperhero @general @julian @evan concept: attaching Applications to your inbox, each of which do their own thing. right now we have effectively monolithic apps that have exactly one "internal AP client" attached to the inbox.

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@deadsuperhero @general @julian yeah, I think custom timelines are great. Some good issues in here on the topic:

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

julian

@julian@activitypub.space · 2 months ago

On the other hand, however... If the ActivityPub API were used in an S2S context, enabling something like NodeBB to send activities on behalf of a Mastodon user, then it wouldn't matter that there is no GET /timeline, because all you need is POST /outbox and the Mastodon API handles their end.

Vice versa, NodeBB would use its own API to render a /world feed.

@deadsuperhero@social.wedistribute.org @evan@cosocial.ca

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian @deadsuperhero @evan POST outbox is the vision of C2S btw -- nodebb is a client in that regard, letting users publish activities of whatever they did on nodebb, to their activity stream.

i recently filed an issue on ap-api for "suggested activities" to improve the security issues with letting others POST to your outbox directly: https://github.com/swicg/activitypub-api/issues/53

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@smallcircles @julian @deadsuperhero we call them collections.

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

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

julian

@julian@activitypub.space · 2 months ago

@evan@cosocial.ca gosh I can't imagine assigning Add and Remove activities for a "popular" collection. It changes so often that it seems a waste of resources to try to track it.

Dynamic Collection?

Or as @smallcircles@social.coop said, even just light algorithmic ordering in a timeline makes stuffing it into a collection unwieldy.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian @evan @smallcircles

> it seems a waste of resources to try to track it.

is it? did someone ask to receive updates of every single change? if not, then maybe. the level of detail is an open parameter here...

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@julian

I might not understand what we're talking about.

@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@julian

I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.

I've done it for other feeds, like `replies` or `followers`, and it works pretty well.

@smallcircles

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian @smallcircles

> use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.

i'm tracking inbox items and outbox items as separate from the activity content/payload. no source release yet but the idea is that inboxes receive "notifications" instead of "activities". notifications have their own timestamps so receiving a notification whose activity content claims to be in the future/past won't cause any confusion for readers.

Julian Fietkau

@julian@fietkau.social · 2 months ago

@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.

GoToSocial currently broadcasts an `Accept(Note)` to let followers know a reply has been accepted (see https://docs.gotosocial.org/en/latest/federation/interaction_controls/#broadcasting-accepts-for-the-benefit-of-third-servers). We'd want to add an inverse for revocation, which would be `Undo(Accept(Note))` imo.

I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?

Interaction Controls - GoToSocial Documentation

None

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@julian@fietkau.social @julian@activitypub.space @smallcircles I like Accept and Reject but @trwnh is pretty insistent on Add and Remove so I defer to them.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles personally i think three things happen generally, which could each be described by their own activity in succession:

1) the original Activity is posted.
2) you can Accept or Reject the Activity.
3) as a result, you can Add or Remove the Activity to the corresponding AP collection.

this holds for Like and Announce 1:1. Follow we currently Add the Follow.object instead, but i think we ought to store the actual Follow activity in a follows collection.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles of course follows are a bit more stateful and complex, so it can be argued that we should actually allow for richer subscription management, similar to when you open a dashboard and manage which email notifications you want to receive. the subscription could be reified as a Follow activity, but the side effects and semantics are not exactly the same with what's in AP right now. (AP doesn't have a way to remove a follower; masto uses Reject without Undo Accept)

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles and then there are replies, which in fedi currently require deep introspection of a Create.object.inReplyTo, which is information that may not be immediately available to you. so it leads to the unfortunately complicated situation where you don't actually know when you received a reply, because there is no Reply activity to be used as a notification -- you have the side effect without the activity.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles re: the Undo Accept thing vs Reject thing, using a Reject is prone to issues with out-of-order deliveries. if you send a Follow and get back an Accept and a Reject with the same published datetime, then are you currently a follower? what if the Reject came first but then you receive a later Accept? it makes it incredibly hard to reason about the distributed state machine, and leads to terrible desyncs when one side thinks you follow them and the other doesn't.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i think there needs to be a way to get a consistent event log in-order from the canonical/authoritative source. failing that, though, the least you could do is have your activities refer to each other in an obvious way. Undo(Accept(Follow)) lets you reverse-reconstruct what happened because all 3 activities are right there (hopefully fetchable!). so maybe Undo(Add) makes more sense than Remove; perhaps we say that the Remove is the result of the Undo?

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles i guess you could hack it with inReplyTo on the Activity, if you assume responses always come after the thing they are responding to (although i could make a famous joke here about answering a question before it is asked).

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@evan @julian@fietkau.social @julian@activitypub.space @smallcircles anyway, to address julian (not lam)'s question: what does Accept(Note) even mean? what does it entail? can you always assume it has to do something with a replies collection that may or may not be there?

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh That's kinda what I'm getting at, yeah. The goal is to express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view. Followers and other observers are made aware this reply is accepted and can be shown similarly in other places that want to honor the poster's reply filters, so observers don't need to iterate over the replies collection all the time.

@evan @julian@activitypub.space @smallcircles

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh The GTS interaction controls docs mention the replies collection, but only tangentially. For the purpose of conversation backfilling (which GTS doesn't do yet) I'm wanting to emphasize that the replies collection is the source of truth for replies curated by the object owner.

The Accept(Note) is essentially a hack to allow interactions from servers that don't implement GTS's ReplyRequest activity. I'll discuss with them how best to signal reply acceptance.

@evan @julian@activitypub.space @smallcircles

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

> express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view

i get that, but the question is whether you can claim this understanding universally for all peers. as it stands, Accept is very vague wrt this. Accept(Note) meaning "Add to replies collection" might be a thing gts does, but that's their interpretation of Accept, not the definition.

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh This is in the context of a FEP draft which prescribes a meaning (including desired side effects) for compliant implementations.

Hence my fidgeting with the vocabulary. The effects are the goal, the question is how they should be expressed and broadcasted. (Principle of least surprise, potential compatibility with existing implementations that look at the replies collection, concerns around server traffic...)

@evan @julian@activitypub.space @smallcircles

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

> replies collection is the source of truth for replies curated by the object owner.

this is fine i think, but the way to do this usually is HTTP GET. you could notify of changes to the replies collection, or you could reify the Reply and then Accept that?

the Reply has an instrument which is the Note. it has clear side effects to Add the instrument to the object.replies. the side effects can be gated behind Accept/Reject like following currently works.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles alternatively add the Reply itself, parallel to likes/shares collections. it depends on whether you think the replies collection should always contain a specific type of object, which i don't think is something you can guarantee because publishers can do anything with it. similar to how some publishers include activities in threads and some include notes.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles i think the issue here is that projects are doing things that may or may not get widely adopted, then if the proposals ever change, they have to deal with older software only understanding the old thing they tried. (this is where i would say something about protocol capability negotiation)

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh There's also this, yeah. GTS interaction controls have already gone through one breaking schema revision from version 0.19 to 0.21 (with 0.20 trying to manage both), and a core goal of the FEP I'm working on is to not break compatibility again.

Sending out an Add in addition to the Accept(Note) that's already happening should be non-breaking for existing implementations, I'm pretty sure. What's left to decide is whether it's a good idea.

@evan @julian@activitypub.space @smallcircles

julian

@julian@activitypub.space · 2 months ago

@julian@fietkau.social in a parallel conversation not about interaction controls, @rimu@piefed.social made the case for batching events, which I'm going to repurpose as an argument against sending additional activities for backward compatibility (unless absolutely necessary.)

As a user can do a great number of notable things (posting content, liking content, following others) each minute and there can be thousands of instances to send to, a great many POST requests can be sent in a short amount of time.

For example if 5 people cast 20 votes and there are 500 instances, the instance hosting the community containing the posts being voted on must send 5 * 20 * 500 = 50,000 HTTP POSTs.

Julian Fietkau

@julian@fietkau.social · 2 months ago

@julian@activitypub.space I'm doing my best to realistically prioritize traffic load as well, yeah. The case of accepting an incoming reply will be frequent, whereas the one where you first accept a reply, then change your mind and revoke the acceptance, would be expected to be relatively rare.

The easy way out for me would be to just not touch that part of the spec, leave it as Accept(Note), and see what implementers do with it.

@rimu

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles this makes me really wish people didn't overload the AS2 vocab so much, and were less afraid of defining their own extensions. you could swing it so that the same activity is an Add, Accept, and ReplyAck. it sucks that we have to pick one instead of using whatever makes sense. (developers: please support multityping and/or duck typing! composability is the only true path to extensibility, and one size never fits all...)

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

actor: alice
type: as:Accept, as:Add, _:ReplyAck
object: <the reply>
target: <the replies collection>
_:postRepliedTo: <op>

for the Accept, you need to understand it as "accepting the object into the target", which is apparently a thing in AS2-Vocab.

for the Add, you need to understand it as Add is defined -- no surprises there, i think?

for the ReplyAck, it can be whatever you define. here i've used an extension postRepliedTo property.

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh The GTS implementation comes with a vocabulary extension, so adding another activity type would be an option.

I guess the reason they didn't do that for this case (I wasn't around for the decision) is that the Accept(Note) thing is itself a backward compatibility hack that they hoped to be able to drop eventually, when more servers would send ReplyRequests (which can be Accept-ed directly), and adding a new type would have felt too much like “enshrining” it.

@evan @julian@activitypub.space @smallcircles

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian i think mastodon handles multityping in certain code paths but most other projects don't. it could have been a compatibility thing?

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian i think mastodon handles multityping in certain code paths but most other projects don't. it could have been a compatibility thing?

Julian Fietkau

@julian@fietkau.social · 2 months ago

@trwnh Maybe. I have no idea if GTS itself can handle activities with multiple types.

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@julian@fietkau.social @evan @julian@activitypub.space @smallcircles

> express that the owner of the replied-to object has accepted a reply, i.e. that the reply is added to the post's replies collection and shown under it in the web view

Julian Fietkau

@julian@fietkau.social · 2 months ago

@evan @julian@activitypub.space @smallcircles Mind if I butt in here with a question about management of the `replies` collection? I'm looking at this for the interaction controls FEP draft.

I feel `Add` and `Remove` on the `replies` collection may be more idiomatic and, in a sense, easier. Opinions?

Interaction Controls - GoToSocial Documentation

None

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@evan @julian

#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?

A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.

I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.

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

infinite love ⴳ

@trwnh@mastodon.social · 2 months ago

@smallcircles @evan @julian if only the application domain of activitystreams was activities and streams... ;)

i do think it causes a lot of confusion to stray away from activities as content, instead using them as vehicles for state changes (which will never be consistent, not even eventually consistent).

back when atompub and atom+as1 were a thing, the "feed entry" was atom semantics and the "activity stream" was as1 semantics. they coexisted in the same xml file. it worked well enough.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@trwnh @evan @julian

Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how we do CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.

Then Protosocial library and SDK implementers would need to deal with #ActivityStreams at a low-level plumbing impl detail, while solution developers would have a higher-level API to invoke these patterns. And other than that would not need to touch #ActivityStreams which is now entirely reserved to making AP work on the wire.

A combination of linked data practices and schema-based design would be used for both open-world and closed-world extension modeling. But here too the solution developer should be shield from the nitty gritty internal mechanics.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@trwnh @evan @julian

Yes, for the ideation on Protosocial as an #ActivityPub compliant extension (going back to the roots with blank slate W3C specs) I imagined mapping the AS primitives to consistent protocol capabilities and thereby define a set of normative architecture patterns, like "this is how CRUD, this is Publish/Subscribe, this is an Event stream and this a Collection", etc.

julian

@julian@activitypub.space · 2 months ago

@smallcircles@social.coop I feel personally called out for this 😛

cc @evan@cosocial.ca

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@julian @evan

No need to, I didn't call you out :)

I think the fediverse-we-have has become a very different one than the fediverse-promised based on the initial specs when there weren't implementations and an installed base making numerous design decisions in a very ad-hoc pragmatic fashion. Which is in itself fine, and a very good approach to get an ecosystem off the ground. But having the app-centric, app-first evolution be the primary evolution process, brought us to a different space than the ubiquitous, heterogeneous social networking environment we might all be working in, focused on exciting solution designs and less in all the plumbing and impl details.

No one is really to blame I guess. This is where laissez-faire in grassroots environments leads us, following the social dynamics that exist.

We can do better, but it is very hard in our individualist, FOSS-project-oriented herding of cats chaotic environment. The challenges are social in nature..

https://discuss.coding.social/t/major-challenges-for-the-fediverse/67

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@julian @evan

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/

Diagram showing the concept of an actor communicating to a remote actor, where there is a schema-based closed-world communication bus, and an open-world semantic web interface.

EventCatalog

Visualize Your Architecture - EventCatalog

See how your services connect, how data flows, and how messages move through your system. Generated from your docs, always accurate.

damon

@damon@social.wedistribute.org · 2 months ago

@smallcircles unless I’m mistaken there’s aspects of what you’re search for that are the basis for ActivityPods, which also allows for bolting on additional where needed. I don’t think what you’re looking for is that far from reality https://docs.activitypods.org/guides/create-your-first-social-app/

Docs

Create your first social app

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@damon

Thank you. Yes, indeed. As it happens I was just in chat with Sébastien yesterday. They'll give a presentation at the #Solid Practitioners Meetings on the 5th of March.

#ActivityPods is positioned to bring "app development" to the intersection of the #ActivityPub and #SolidProject ecosystems, and that is very valuable. And also an #OpenStandards focused initiative.

I have revamped the #fediverse delightful lists to de-emphasize app domains and apps that have already established themselves, to highlight the innovative projects that can bring fedi to higher levels. @activitypods is on the developer list.. https://delightful.coding.social/delightful-fediverse-development/#application-development

They are well positioned to offer the 'Solution developer' stakeholders an attractive set of tools. And the opportunity is to marriage the best of 2 worlds. Which is at the same time the big challenge, coping with the worst of 2 worlds. The other day I tooted about this here: https://social.coop/@smallcircles/116113963712755122

delightful fediverse development

Delightful curated lists of free software, open science and information sources.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

Steve Bate

@steve@social.technoetic.com · 2 months ago

@smallcircles To follow up on the discussion from yesterday, @evan has created a proposal for another kind of “event stream” that is not necessarily associated with *any* AP collection type (see Example 1). This is more aligned with my mental model of an event feed/stream, where a timeline^1 is the history of the feed after optional filtering and content materialization. (^1 However, the terms are often used interchangeably in the Fedi.)

https://swicg.github.io/activitypub-api/sse

Server-Sent Events For the ActivityPub API

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

Oh, that is very interesting. I will queue this up for inclusion in the delightful fediverse development curated list.

#Datastar may be a great library to check out here, and goes further in #hypermedia approach, where #HTMX considers itself feature-complete. Datastar uses #SSE to keep the connection to the client open. The client-side JS lib that is needed is super small. In datastar apps most of the business logic lives in the backend, and it lends itself very well for #EventSourcing. The original author/co-maintainer uses it with #NATS which also serves as the event store.

https://data-star.dev

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

This is a nice video that demonstrates #EventSourcing with #Datastar + #SSE in a #Python context for the backend..

https://pyvideo.org/flaskcon-2025/death-to-the-spinner-event-sourcing-for-reactive-web-apps.html

Death to the spinner: event sourcing for reactive web apps

PyVideo.org

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

Note that there is an accompanying issue in the #ActivityPub API repository, where I transferred my reply to in the following comment:

https://github.com/swicg/activitypub-api/issues/9#issuecomment-3938841868

I also added a very nice demonstration that is interesting for the #Mastodon folks, as it is using #Ruby in the event-sourced set up.

https://github.com/ismasan/sourced_todo

GitHub

GitHub - ismasan/sourced_todo: Demo TODO list app for Event Sourcing and reactive UIs with Sourced and Datastar

Demo TODO list app for Event Sourcing and reactive UIs with Sourced and Datastar - ismasan/sourced_todo

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

Oh, that is very interesting. I will queue this up for inclusion in the delightful fediverse development curated list.

https://datastar.dev

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@smallcircles @steve please comment on the issue!

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

I think it's fair to say that activities are like events.

I also like the use cases and primer.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@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

REST - Wikipedia

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

EDIT: note that it's exclusive.

Christine Lemmer-Webber

@cwebber@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

It does use message-passing, but not exclusively. I'll update my reply.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@evan @cwebber @steve

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@evan @cwebber @steve

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Social coding commons

How We Reimagine the Social Web

We find novel ways to collaborate and create value together.

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@smallcircles that sounds cool!

Dr Kim Foale

@kim@social.gfsc.studio · 2 months ago

@evan @smallcircles just to note this is the ballpark i've been working in for a little while now

https://gfsc.community/whats-happening-where-you-live-re-introducing-placecal/

Geeks for Social Change

What's happening where you live? Re-introducing PlaceCal

If you've hung around us the last few years you undoubtedly will have heard us go on about PlaceCal. But what is it, why does it matter, how can you and your community benefit, and why has it taken us so long? Kim takes it from the top and outlines our ambitions for community technology in 2026.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@kim @evan

Thank you, Kim! I enjoyed our chat, and really like your paper outlining Community Technology Partnership formal methodology, so lemme include the direct link below:

https://www.tandfonline.com/doi/full/10.1080/1369118X.2020.1767173#d1e470

naturzukunft

@naturzukunft2026@mastodon.social · 2 months ago

@fredy

naturzukunft

@naturzukunft2026@mastodon.social · 2 months ago

@fredy

Evan Prodromou

@evan@cosocial.ca · 2 months ago

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

naturzukunft

@naturzukunft2026@mastodon.social · 2 months ago

@fredy

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@evan @steve

No, it is more than just metaphors. It is that both domain/scope and architecture patterns aren't clearly defined, while the terminology is borrowed from a whole range of them. This makes one person think that AP is for whole different purposes than the next person.

Is AP for modeling existing social media or for social networking, encompassing many more domains? For content publishing or also for distributed services? Linked data hypermedia or message oriented architecture. Problem is, it is all of that, depending on who you ask.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@evan @steve

Perhaps - you are best to know - you also started in AP with a different notion of the network than @cwebber for instance, coming from AS perspective which looks to me very much modeled to facilitate common social media functionality. While, when I look at Spritely Fantasary, I read - what I perceived to be at the time - The Original Promise™ that lured me to fediverse in 2017, after reading the specs. Ubiquitous, versatile, and heterogenous social networking: addressable actors exchanging messages with an object payload. And solution development on top of that. I think this may be where you are today with Social API a renewed opportunity to get there.

Steve Bate

@steve@social.technoetic.com · 2 months ago

@smallcircles @evan To me, it appears that Mastodon has content timelines (home, local, federated, account list, hashtag) that are materialized views of streams of content-related activities (Create, Update, Delete) and a notification timeline (a kind of *filtered* inbox activity stream) representing likes, follows, boosts, mentions, and so on. Empirically, users seem to like this model, at least for short content messaging, including microblogging and content comments.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

I agree with what you say.

On the use of "stream(s)" I did a search in both specs, and it is only very sparsely used in the meaning of a stream rather than an Activity Streams document or object.

One time mentioned as "Activity Streams consumer" in #ActivityStreams core and another mention in the Security considerations section.

> Publishers or Consumers implementing Activity Streams as a stream of public data ..

And twice in #ActivityPub where it says both inbox and outbox where it mentions "the outbox stream", "the inbox stream", and one other mention in definition of "Social API" where it is said to provide a "social stream of the user's actor".

So I would not consider this formal language terminology right now. That said, it would be good to further formalize the concept of a Stream, as it is a higher-order concept that'll help lift discussions out of nitty gritty impl detail territory.

Steve Bate

@steve@social.technoetic.com · 2 months ago

@smallcircles @evan I agree. It’s not formal at all. There’s also the “streams” property associated with AP actors.

streams: A list of supplementary Collections which may be of interest.

Also, not formal. I’d also think they’d need to be OrderedCollections to be considered a stream.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

Yes, OrderedCollections.

I wonder what you think about what I wrote in another toot, to define normative architecture patterns as building blocks, instead of having the most granular social primitives being the puzzle pieces that everyone shuffles together in their own unique ways causing endless confusions..

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @evan

If we have those #ActivityPub patterns we can speak together in a higher-order domain language that is closer to actual solution design, and that will make ecosystem participants happy (as happy or happier than our friends in the #ATProto atmosphere).

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

@steve@social.technoetic.com · 2 months ago

@evan @mariusor @smallcircles Yes, I think that could be possible. I have a rough idea of a “timeline definition language” that could represent all the existing Mastodon timelines (other than “link timelines”?) and also user-defined custom timelines.

marius

@mariusor@metalhead.club · 2 months ago

@steve I've just seen a FEP-34c1 today which uses the TREE hypermedia vocabulary (which I wasn't familiar with) to ask from servers a particular representation of existing collections. Have a look if it's similar to your ideas.

https://codeberg.org/fediverse/fep/src/branch/main/fep/34c1/fep-34c1.md

@evan @smallcircles

Codeberg.org

fep/fep/34c1/fep-34c1.md at main

fep - Fediverse Enhancement Proposals

marius

@mariusor@metalhead.club · 2 months ago

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

@smallcircles @evan

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@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

Ben Pate 🤘🏻

@benpate@mastodon.social · 2 months ago

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

ActivityPub/Primer/proxyUrl endpoint - W3C Wiki

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@benpate @steve @mariusor @smallcircles @evan i'm not sure proxyUrl does what I'm thinking of here

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@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

marius

@mariusor@metalhead.club · 2 months ago

@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

https://w3c.github.io/activitypub/#proxyUrl

@evan @benpate @steve @smallcircles

ActivityPub

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@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 ¯\_(ツ)_/¯

@thisismissem @benpate @steve @smallcircles

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

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

Ben Pate 🤘🏻

@benpate@mastodon.social · 2 months ago

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 @mariusor @thisismissem @steve @smallcircles

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@benpate

With all the standard warnings around proxies!

@mariusor @thisismissem @steve @smallcircles

marius

@mariusor@metalhead.club · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

@benpate @thisismissem @steve @mariusor @smallcircles

Yes, proxyUrl already exists. There's a use case here:

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

marius

@mariusor@metalhead.club · 2 months ago

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

@steve @smallcircles @evan

Emelia 👸🏻

@thisismissem@hachyderm.io · 2 months ago

@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

marius

@mariusor@metalhead.club · 2 months ago

@thisismissem which is what proxyUrl is supposed to do, right?

Did you mean it in a different way?

@steve @smallcircles @evan

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

marius

@mariusor@metalhead.club · 2 months ago

@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

Steve Bate

@steve@social.technoetic.com · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

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

Evan Prodromou

@evan@cosocial.ca · 2 months ago

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

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @mariusor @evan

Yes. And again same here :)

Just pointing out the Babylonian speech confusion that we haven't overcome yet.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @mariusor @evan

Yes, same here. This was the confusion I addressed in the other thread, where we sometimes talk protocol capabilities and other times in 'solution space' about user/app-specific activities. Yet using the same language for both.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@mariusor @steve @evan

I think it depends on the use case. It would be good or best practice to model things on the client that can be on the client, and not have them on a hosted platform that may become a new point of centralization and/or FOSS/vendor lock-in.

But there may also be legit use case for server applications that require a timeline. Perhaps a service that exposes a huge dataset to the fedi, archives, knowledge bases, etc.

🫧 socialcoding..

@smallcircles@social.coop · 2 months ago

@steve @mariusor @evan

Not bound by Mastodon on-the-wire compliance, thinking of such rich timeline functionalities, I would consider my approach to constitute a "Timeline service", and may well be modeled as an actor with a full-blown extension behind its facade.