MSC3849: Observations and Reinforcement#3849
Conversation
Gnuxie
changed the title
turt2live
added
proposal
| "observation": "spam", | ||
| "observed_server": "example.org" | ||
| }, | ||
| "type": "m.policy.observation.user" |
There was a problem hiding this comment.
Just to clarify, these are non-state events, correct? So far, the only event types defined for policy rooms (m.policy.rule.*) are state events, so it may be worth calling this out.
There was a problem hiding this comment.
Sorry, they are state events, It's incomplete because I'm pussyfooting over which entities i want to include in the proposal right now. Users, rooms, servers are a given but i think events/media are certainly blocked on the "directory of abuse" issue. I'll edit them all in with a discussion for each for now.
| ``` | ||
| { | ||
| "content": { | ||
| "observation": "$event_id", |
There was a problem hiding this comment.
Can we use the message relationships/aggregations system here, instead of creating a new key? Also, does this need to be a state event?
There was a problem hiding this comment.
Ok, thanks for pointing this out, i totally ignored this detail about relations. The following isn't addressed directly to your question but is my thoughts about the proposal in general.
Yes another problem is that for this to work well there needs to be relationships to events in other rooms.
This is because you will want to make references to labels from other policy lists (if we are keeping with the extensible+hierarchical format) but also so that you can make observations about events. The other thing is that if you do make an observation about another event, you will need a relationship to both the event and the label, which isn't something that is possible or can feasibly will become possible in the future of matrix.
So then I am forced to choose between the following:
-
water down labels into a free form key (which to me sucks because then they can't be hierarchical e.g. i want to trust nico's judgement on all labels under the moderation hierarchy).
-
Ignore matrix's support for relations completely and propose something ad-hoc (just embedding event/room id into each observation to the label definition).
-
Specify a set of labels (No way)
-
Wait a minute, you could leave the forming of a hierarchy between labels to the client? Yes that actually might work.
There was a problem hiding this comment.
Ah, OK, if you're referencing things from other rooms, that might be a reason not to use relations. Relations are also not generally used for state events. Anyways, if you decide not to use relations for whatever reason, it's probably saying something about why relations aren't used.
|
I think I have shared this in some PR, but I'd prefer if we had a structured way to declare the given instances (observations) of abuse that reinforce the given moderation action. I.e., in our ban list, I always add the room(s) where the given spammer has acted up recently. Strictly speaking, an event ID (or timestamp) would also be needed, but for all intents and purposes, the room was sufficient for us with the present rate of ham vs. spam and was much easier to add by hand. Right now, this mostly works if the abuse happened in at least one abandoned room where it is not redacted, but the future possibility of hiding abuse for a few days before redacting it would provide a better solution to this. |
| ``` | ||
| "content": { | ||
| "entity": "@alice:example.org", | ||
| "observation": "spam", |
There was a problem hiding this comment.
As discussed, this should be namespaced.
| ``` | ||
| "content": { | ||
| "observation": "spam", | ||
| "entity": "$w23r0932ir:foo.net" |
There was a problem hiding this comment.
Problem is that you often would want to redact these events. I wonder if MSC3531 would allow for this to be fully utilized.
| We're undecided on whether to propose an observation for an event | ||
| but in cases where the observation is about an action or | ||
| something an author is associated with we propose linking | ||
| to them with an `observed` and `observed_server` field. |
There was a problem hiding this comment.
observed_server should just be able to be inferred from the server name of the observed user id.
| ### Labels to provide Context (This one is a maybe) | ||
|
|
||
| Labels are used to provide context for an observation. |
There was a problem hiding this comment.
Not too sure as to what the purpose of this is, is the event id not context in of itself?
| "content": { | ||
| "observation": "$event_id", | ||
| "policy_room": "$room_id", | ||
| "reinforcement": "agree", |
There was a problem hiding this comment.
Might be useful to namespace, not too sure.
| ``` | ||
| "content": { | ||
| "entity": "@alice:example.org", | ||
| "observation": "spam", |
There was a problem hiding this comment.
When handling multiple observations (e.g. racism & spam) from a single user (and event, as below), is it recommended to send multiple of these observation events, or should observation be replaced with an array of observations?
5 participants
Rendered