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

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

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

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

@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

@smallcircles @steve one anti-pattern I dislike seeing in ActivityPub discussions is that only one interaction defined in the ActivityPub spec is valid: an HTTP POST to an actor's `inbox` for server-to-server interactions.

We can use HTTP GET to fetch additional data about objects, actors and collections.

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

EDIT: note that it's exclusive.

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

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

@evan @cwebber @steve

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

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

@evan @cwebber @steve

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