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

the context-level interaction controls

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

@technical-discussion

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

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.

Interaction Controls - GoToSocial Documentation

None

(docs.gotosocial.org)

It's not really ready though, I am still collecting feedback from developers that need fine-grained permissions. We need a system that works for them as well as for simple forums where two roles is enough (user and admin).

@Profpatsch

I'll update the FEP to note the difference.

This might be done at the moderator/admin level, and would be functionally equivalent to:

[... rest of the interaction policy ...],
"canReply": {
  "automaticApproval": [],
  "manualApproval": []
},
[... rest of the interaction policy ...]

or whatever shorthand is available (canReply: false?)

This FEP is also part of the resolvable contexts tree of FEPs, so they don't refer to post objects themselves, but the entire comment tree. That means if a topic is locked, you can't reply to any of its children either, at least relative to the context/OP's POV.

How do you see the balance between 'the community decides this thread is done' versus 'an admin or the original poster can silence it'? I keep thinking the answer should live with the people who were actually in the conversation.

1. Undo(Like) is the inverse of the Lock activity now
2. A prior art section has been added to address the conflict between this FEP and Lemmy's implementation

Friendica reads postingRestrictedToMods but has their own restrictions object (so it's subtractive): CANT_REPLY, CANT_LIKE, CANT_ANNOUNCE, CANT_QUOTE. These are internal, I think, so am not sure what is federated out.

PixelFed uses an additive approach canReply, canLike, canAnnounce, and I think they expose these on the federated object. @dansup@mastodon.social if you wouldn't mind confirming?

Either way, the landscape for access control is varied and the only one with multiple implementations (Lemmy, NodeBB, Takahe, PeerTube, WordPress) is just the simple postingRestrictedToMods

Reply controls are a whole 'nother ball game which is deserving of its own FEP. This deals with binary moderator/admin level locking of a topic for arbitrary reasons (spam, off-topic, inflammatory, etc.)

For example, postingRestrictedToMods is something Lemmy, NodeBB, and Wordpress (among others) use to signal that a category can not be posted to freely.

@silverpill@mitra.social's FEP-5219: Groups and permissions attempts to put together something similar, although I don't know if there has been any adoption.

I'm not entirely happy with postingRestrictedToMods either, but it is what we have currently.

People can still like and share locked threads, yes?

Off topic: My outline for the interaction controls work in the T&S task force mentions context-aware policies as a tentative non-goal. https://github.com/swicg/activitypub-trust-and-safety/issues/159#issuecomment-5348012095 NodeBB gets a shoutout.

Interaction Controls - GoToSocial Documentation

None

(docs.gotosocial.org)

This continues to be a point of contention between NodeBB and Lemmy/Piefed <img class="not-responsive emoji" src="https://activitypub.space/assets/plugins/nodebb-plugin-emoji/emoji/android/1f605.png?v=5a9b4bf9c7f" title="" />

I will update the FEP to adopt Undo(Lock) instead of Unlock. This follows established patterns more closely.

If there is an existing JSON-LD context URL for Lemmy's then this FEP will inherit it.

two new activity types, Lock and Unlock

Any relation to Lemmy's Lock activity?