FEP-c0d0: Context Locking

two new activity types, Lock and Unlock

Any relation to Lemmy's Lock activity?

@silverpill@mitra.social likely identical in form and function, will have to double check.

@silverpill@mitra.social it looks like Lemmy uses Lock in a similar manner, except that the object is a Note-like or similar, whereas this FEP points to a resolvable context.

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.

The FEP has been updated to remove references to an unneeded Unlock activity. Undo(Lock) is the preferred form.

@julian Why only have a boolean flag? I usually want something like “only people I follow can reply”, though ofc. it’s all a bit silly because replies themselves are not gated on their author approving of them, just a signal whether they would like there to be any.

@julian But also, why introduce a new state machine like that, why not have a single property on the original message that can be edited with a normal `Edit`. This way we can have more specific intent than “I’d like nobody to reply to this”

@julian@activitypub.space There is potential overlap with interaction policies here. Although GTS-style interaction policies make a few assumptions that might not apply to threadiverse contexts: https://docs.gotosocial.org/en/latest/federation/interaction_controls/#implicit-assumptions What do you think? Maybe FEP-c0d0 is a “harder” lock.

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.

I think there should be a "Prior art" or "History" section.

@profpatsch@mastodon.xyz good question! This FEP is specifically limited in scope for simplicity but does not preclude the use of additional mechanisms to allow for fine-grained privileges related to reply controls.

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.

@profpatsch@mastodon.xyz re: access control; a little bit of research also uncovered a couple items I forgot about.

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

@silverpill@mitra.social thanks for the early feedback:

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

@julian @Profpatsch Yes, we have a capabilities attribute, but it does appear to be rendering incorrectly, will fix that!

https://browser.pub/https://pixelfed.social/p/dansup/2

Context locking is exactly the kind of thing that makes me both excited and nervous. Excited because a topic that goes quiet should be allowed to rest — not endlessly reopened by bots who don't read the room. Nervous because whoever holds the key to unlocking decides what gets remembered and what gets forgotten. That's a lot of power for a protocol layer.

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.

@julian Should people be able to lock/unlock their own threads? Facebook supports this, and I've seen plenty of people ask for this on the Fediverse, too.

In my own notes I have separate "locked by moderator" and "locked by OP" properties, so that moderators and OPs can only undo their own locks, not each other's.

@julian@fietkau.social yes, I was aware of some overlap with GtS interaction policies/reply-controls, although this is less fine grained and isn't tied to the posting user — it's scope is actually larger!

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.

@julian@fietkau.social that context locking has a scope that expands past GtS interaction policies is distinction worth pointing out.

I'll update the FEP to note the difference.

@julian Parts of FEP-5219 are implemented in Mitra. You could be the next implementer

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

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