@julian@activitypub.space Thank you! Yes, the context-level interaction controls (we talked about them briefly near the start of the year) will most likely not be part of v1 of my document.

I am still curious whether a FEP-c0d0 lock and the interaction policy you posted are indeed equivalent given these conditions: https://docs.gotosocial.org/en/latest/federation/interaction_controls/#implicit-assumptions I'm assuming no.

In my draft text I leave it open whether an interaction constraint is imposed by the post author or a moderator. Maybe this distinction should be explicit.

@julian@fietkau.social the implicit assumptions AIUI:

• OP always has ability to modify
• mentioned and inReplyTo are always able to reply

These are implicit to microblog style interactions and would not apply in a threaded context.

It's a difference in delegation of moderation power to category/forum level moderators and admins.

Likely worth noting in the FEP as well.

@julian@activitypub.space Perfect, that's what I figured. Thanks again, and let's keep in touch about the topic.

@julian @julian

the context-level interaction controls

This is documented in FEP-171b: Conversation Containers.

@technical-discussion

@silverpill Yes, FEP-171b is very important related work which could be usefully combined with interaction policies, I think. But the document I'm working on will provide at most a rough, non-normative outline of what that combination could look like.

@julian@activitypub.space @technical-discussion

I don't see much in 171b re: access/reply controls.

That said 171b also is an opinionated departure from 1b12 so might be we'd want access controls split off from 171b perhaps, so they can be shared?

cc @julian@fietkau.social

@julian@activitypub.space @silverpill I believe it's mainly this: https://codeberg.org/fediverse/fep/src/branch/main/fep/171b/fep-171b.md#moderation

If the context owner refuses to acknowledge any and all incoming replies, the thread is effectively locked.

The approach seems like it would pair well with either interaction policies on the context object and/or a FEP-c0d0-like flag, so actors can know in advance which kinds of activities are likely to succeed or fail, i.e. so UI hints can be provided (grayed out buttons etc).

If the context owner refuses to acknowledge any and all incoming replies, the thread is effectively locked.

@julian That's correct. Context owner distributes approved activities to participants and also maintains a collection containing only approved activities. Replies (or reactions) that have not been approved are considered rejected.

A similar mechanism exists in Interaction Policies but it is post-based rather than conversation-based, and with Accept activity instead of Add.

Some FEP-171b implementations add canReply flag. I should probably mention it in the FEP but it is basically the color of the bike shed. The actual control mechanism is much more important.

@technical-discussion @julian

In Lemmy, object is the post itself — a Page (Note-like) object. Lemmy has no separate context abstraction: the top-level post is both the root object and, implicitly, the thread, so pointing object at the post is sufficient to identify the thread being locked.

I'd just like to point out that in Lemmy 1.0 a Lock can also point to a Note (comment under a post in Lemmy lingo) so that only that comment and all its children are locked, while the rest of the thread remains unlocked. I believe Piefed already works like this as well.

Thanks for sharing that! I did not know that the Lock activity could be applied to children, although it makes sense logically.

This FEP only deals with topic/context-level locking, so Lemmy and Piefed's implementation would go further than this. It's definitely worth mentioning within as well.

FWIW both Lemmy and Piefed have the concept of contexts, it's just not exposed in the UI. It's pretty trivial to support this FEP with little to no new logic.