> generic server needs to maintain collections.
If you are talking about "any arbitrary collection beyond followers/following/inbox/outbox/shares/likes". I'll disagree with you.
Discussion
Loading...
> But then you want to introduce context collection. And then 50 other extensions. How to do that without special-casing every one of them?
You don't! An extension is an extension. A Generic server only needs to support the base protocol. Extensions are optional, not a requirement.
@raphael @silverpill @julian @mariusor
I agree. Aboveall we need to know where protocol ends and 'app' begins. Be generally more deliberate in terminology use, and no longer talk in overloaded terms that have different unclear meanings to different people in different settings (to avoid using 'contexts' one of such overloaded words)
I've noticed for instance people having a very different notion of what a 'generic server' is, in definitions that are almost diametrical opposites.
My definition of generic is 'not specific' i.e. a generic server is a pure #ActivityPub protocol implementation (which is something to agree upon, what that exactly entails), having no knowledge of *any* app / solution built on top of it or 'passing through' its messaging architecture.
In the other meaning a generic server 'knows/does/has it all' i.e. it understands everything we comprise to be 'the fediverse' in a kind of hard-wired fashion based on the functionalities that (marginally) interoperate today.
@smallcircles @raphael @julian @mariusor I use the same definition of generic. With ActivityPub, it is not possible to have no knowledge at all, but we can try to minimize required knowledge and this is what my FEP is about.
@silverpill @raphael @julian @mariusor
Yes, I see you working hard in that quest.
But in the chaotic fediverse that evolved by post-facto interoperability that is a wicked challenge. Post-facto interop means "if I am first I can become law, and drag fediverse sideways in my image".
In another branch of this thread, there's another confusing thing. "how can a mastodon client ask the server .." and you respond with a possible URL pattern that may be defined.
> Maybe something like `/api/v1/timelines/tag/{tag}?only_media=true` ?
Perhaps Mastodon's non-generic server may have that, but not a generic server, but it is unclear which one is referred to.
Since microblogging nowhere aggregates comprehensive overview it is an echo chamber for confusion.
@smallcircles @raphael @julian @mariusor I was comparing Mastodon and a spec-compliant ActivityPub server, from a user perspective. My claim is that even the most advanced implementations of ActivityPub API are on the same level as Mastodon API.
If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.
@silverpill @raphael @julian @mariusor
Yes, I agree. Though I would rather see a generic server having much less functionality than a Mastodon API exposes, since much of that is app-specific, Microblogging domain already. The generic server should make Mastodon possible as a solution design modeled on top of its #ActivityPub networking layer.
In such a way where we can finally consider the protocol layer to be robust, and are able to treat it as a black box, and are not confronted with all its implementation details when we are doing a solution design.
I think we are probably on the same page, but..
> If you want to go beyond Mastodon API capabilities, you need a truly generic server. Something akin to Nostr relay.
This I would reformulate as:
"If you want to go beyond an app-centric fediverse bound to a Microblogging domain, then you need a generic server conformant to the ActivityPub specification."
Which also indicates I think we need to aggregate puzzle pieces into an AP 2.0
1 more replies (not shown)
@silverpill @raphael @julian @mariusor
I sometimes picture fediverse as one of these old horseracing toys from the 50s, where the horses represent all the various perspectives and expectations people have of the fediverse. There is no horse to bet on, positions change all the time, horses change tracks randomly. And furthermore there no finish line, the race is an endless slog. The prize of a robust #ActivityPub protocol forever out of reach, getting more elusive as time progresses.
Another example of the need for careful terminology use is in the post that @silverpill quoted above:
> prevent actors on the same server from deleting each other posts
"post"? There is no post in #ActivityPub, not as a verb and neither as a noun. While I am not worried that silverpill used the word in a wrong meaning here, the terminology easily leads to confusion where someone who interprets AS/AP to be equivalent to the fediverse we have today, pictures in their mind as Mastodon posts or toots in fedi slang, or elsewhere called statuses.
That is app terminology. AP only knows Actor, Activities, Objects, and perhaps Collections. Period. The rest is solution design.
Where they are transferred they can be said to be messages, and messaging happens.