message schema

here's the existing message schema as used in Patchwork "Classic"

{
  type: 'vote',
  vote": {
    link: (uxerId | msgId | blobId),
    value: -1,
    reason: 'abuse'
  }
}

here's a draft attempt at something new:

{
  type: 'flag',
  link: (uxerId | msgId | blobId )
  flags: {
    [flagId]: String
  }
}

so if someone posts something not cool:

{
  type: 'flag',
  link: '%...'
  flag: [
    'abuse'
  ]
}

or something. i also consider this:

{
  type: 'flag',
  link: '%...'
  flag: {
    abuse: 'this post contains unsafe content and should not be allowed to represent the community'
  }
}

which would allow people to directly signal detail as to why they are flagging the content. i think it's important to provide as many possible vectors for actionable, specific, and kind communication, rather than a nondescript flag. however maybe this can be implemented with post messages?

user experience

on a message, i see any flags given to the post, similar to how i see likes. when i click on the "X flags", i see a full detailed view of each flag given by each uxer.

on a profile, i see any flags given to the identity by people i trust, similar to how it shows blocks.

open questions

many questions. what do you think?

Hi @dinosaur this is an excellent and important proposal. Thank you for spelling it out so clearly and opening the topic for discussion.

actionable, specific, and kind communication

I love your emphasis on kind communication.

Two questions -

• Do we also want this to be automatically actionable (eg I set my client to never show messages flagged as "abuse") or does it always have to require human intervention?
• How do we stop potential abuse of this mechanism?

Also have you seen this related discussion? It's about using tags and/or flags to voluntarily tag/flag posts as NSFW and hiding (completely or requiring a click to reveal) this material. There is also the suggestion that the same mechanism could be used to hide posts flagged/tagged with a Content Warning.

It feels like both proposals might possibly benefit from being merged if only to make the user experience less confusing.