FEP-c0d0: Context Locking
-
@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).
-
@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 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@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.
the context-level interaction controls
This is documented in FEP-171b: Conversation Containers.
-
the context-level interaction controls
This is documented in FEP-171b: Conversation Containers.
@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.
-
the context-level interaction controls
This is documented in FEP-171b: Conversation Containers.
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?
-
@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).
-
@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
Acceptactivity instead ofAdd.Some FEP-171b implementations add
canReplyflag. 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login