agnos.is Forums

How it works between forums, e.g. between Discourse and NodeBB?
Can a Discourse user create a topic in NodeBB category?
Who creates/owns the context collection in this case?

If I create a topic this way, I will be the owner of the context collection. But if the conversation is to be moderated, it should be owned by the group.

Am I correct?

(there is a parallel discussion happening at https://codeberg.org/streams/streams/issues/229)

@julian Does NodeBB support creating new topics by mentioning a group/category?

I wonder how context should be assigned in this case.

@julian @trwnh @mikedev

neither approach conflicts with the other

I don't fully agree with this statement, because these "threading paradigms" suggest two different solutions to the problem of moderation. If the OP is the single source of truth, they can moderate the entire conversation (represented by context collection: Streams). If not, then each reply is independent and authors moderate only the direct replies (represented by replies collections: GoToSocial).

In theory two solutions can be combined, but at the cost of significantly increased complexity.

I think it's important to get an Announce, because the actor who addressed the community might be blocked by that community, or might not be a member of it (if the community is private).
You can try to retrieve the outbox of the addressed community to verify that a post was actually Announce'd

@activitypub

@julian @activitypub Makes sense. Were NodeBB's own federated categories represented as users prior to this change? Do you assume that all groups are FEP-1b12 groups?
There was an interesting discussion on SocialHub on identifying FEP-1b12 groups and nutomic made a compelling argument that we should just assume that Group supports FEP-1b12 if there is no other indicator:

https://socialhub.activitypub.rocks/t/fep-1b12-group-federation/2724/96

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

@julian Consider adding .mention class to mentions in HTML content. Some clients transform such links into internal links.

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.

@julian

@scott

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.

#ActivityPub #FEP

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

@julian

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