Crumb
c/technical-discussion · by julian@activitypub.space · 6d

FEP-c0d0: Context Locking

This is the main discussion thread for the draft FEP-c0d0: Context Locking

Summary

Context locking (and its inverse, unlocking) refer to the action whereby a topic no longer accepts new replies.

This proposal introduces a locked property on the context object, and a new activity type, Lock, to signal changes to a topic's locked state across the fediverse. Unlocking is expressed with the standard ActivityStreams Undo activity, applied to the original Lock. It builds on FEP 1b12: Group federation for audience identification (the audience property) and the Announce wrapping pattern, and on FEP fe34: Origin-based security model for authorization.

This FEP is a sibling of FEP f15d: Context Relocation and Removal, which covers the Move and Remove moderation actions.

The full FEP text can be found at https://w3id.org/fep/c0d0

1 points · 21 comments · view on lemmy.world

21 Comments

julian@activitypub.space · 1 pts · 6d

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

Profpatsch@mastodon.xyz · 1 pts · 6d (3 replies)

@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@activitypub.space · 1 pts · 6d (2 replies)

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

silverpill@mitra.social · 2 pts · 5d

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

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 · 1 pts · 6d

@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

pip@tinymind.eu · 1 pts · 5d

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.

silverpill@mitra.social · 1 pts · 6d (4 replies)

two new activity types, Lock and Unlock

Any relation to Lemmy's Lock activity?

julian@activitypub.space · 1 pts · 6d (3 replies)

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

julian@activitypub.space · 1 pts · 6d (2 replies)

@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 :sweat_smile:

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

silverpill@mitra.social · 1 pts · 6d (1 reply)

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

julian@activitypub.space · 1 pts · 6d

@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@fietkau.social · 0 pts · 6d (9 replies)

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

https://docs.gotosocial.org/en/latest/federation/interaction_controls/#implicit-assumptions

julian@activitypub.space · 1 pts · 5d (8 replies)

@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@activitypub.space · 1 pts · 5d (7 replies)

@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@fietkau.social · 1 pts · 5d (6 replies)

@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@activitypub.space · 1 pts · 5d (1 reply)

@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@fietkau.social · 2 pts · 5d

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

silverpill@mitra.social · 0 pts · 4d (3 replies)

@julian @julian

the context-level interaction controls

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

@technical-discussion

julian@activitypub.space · 1 pts · 4d (2 replies)

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@fietkau.social · 2 pts · 4d (1 reply)

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

silverpill@mitra.social · 1 pts · 3d

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