S
@julian The problem with mainstreaming is that everyone wants a piece of cake. Some people come to build, and I think that's fine, even if they take away something from existing projects. But there are also charlatans and scammers, and unfortunately faking achievements is very easy in Fediverse.
The good thing about grassroots / DIY spaces is that the latter category is non existent.
@julian @johnonolan @angus @evan
Why 301 and not 302?
I am using 302. Probably chose it because everyone else was using it.
1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.
2. I think observers (and other Application actors on the server) should use a shared key.
@trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal Application actor is recommended, which is not a "user".
The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.
Yes, I'd like to subscribe to arbitrary threads. For example, I often subscribe to issues on Github/Codeberg, or watch selected topics on SocialHub.
Another reason is client to server ActivityPub. Even if we implement thread subscriptions in a non-federated way, clients still need to tell servers about subscriptions somehow.
@julian If these limitations don't prevent us from implementing any features, why they should be addressed?
The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.
How to subscribe to a thread?
Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.
So here is an alternative: FEP-f06f: Object observers.
Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.
@julian FEP-1b12 only works with activities,
but Lemmy also announces Page objects for (micro)blogs.
https://socialhub.activitypub.rocks/ap/object/443fb143373ebc5a4df190cddcd2da1f
@julian FEP-171b has its own way to backfill, also via context, but it is a collection of activities (such as Create).
I am currently trying to figure out how to make Containers compatible with NodeBB and others.
>Contexts can provide a thorough, comprehensive way to backfill an entire conversation. This is the biggest step we can take towards tackling the “fediverse is quiet” problem.
Sure, context is useful for backfilling, but is it the biggest step? I don't think so.
With FEP-1b12 or Containers, conversations are synced by default, so there is no need for backfilling. This is more efficient too: you don't need to retrieve context periodically to get an up-to-date view.