@deadsuperhero

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

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

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

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?

@[email protected] @[email protected]

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.

@[email protected] @[email protected]

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

@smallcircles @julian @deadsuperhero we call them collections.

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

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

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