Data storage of Flags, Hides, Blocks

[gabehamilton]

Regarding the implementation of 'Hide Account' https://github.com/near/near-discovery/issues/383
Maybe flag should move into this collection as well?

I think it's worth designing the end state so the data storage doesn't change. It seems like eventually in the UI we will want 'hide and report' (flag), 'hide but don't report' (see less), 'block'. Does block need to also have report/don't report?

We'll likely also allow the user to specify a reason at some point, which in terms of the data we store can be a label. Do we need more than one label per post/account, "this is both 'sexual content' and 'violent'?

[tidus974]

Thanks for setting this up @gabehamilton ! I have answered some of these questions here https://pagodaplatform.atlassian.net/browse/ROAD-346 but I will tackle the rest in this thread.

Q: Maybe flag should move into this collection as well?

A: I think you are right. Flag is somehow in the same bucket as Hide and Block. Just some historical context: Social Media platforms have started off with giving Reporting options to users and over time they realized that users needed more granular actions such as Hide or Block where we wouldn't require the intervention of the platform.

In essence "Hide" a content is exactly the same as "Flag" where in both cases the content will be removed from the reporter view but is still findable by that same reporter or anyone else on the platform.

There is of course a slight distinction when we refer to "Hide Account" since it essentially means hiding all content (posts/comments) related to that account. However, it is not Blocked so it is still findable by the reporter (e.g. if they wish to go to the reportee account's page they will be able to see everything)

Q: I think it's worth designing the end state so the data storage doesn't change. It seems like eventually in the UI we will want 'hide and report' (flag), 'hide but don't report' (see less), 'block'. Does block need to also have report/don't report?

A: Absolutely correct on the UI side. Block will not lead to a report though. Block will simply prevent specific users from interacting with you or seeing your content but it also means you won't be able to see theirs (e.g. if a reporter goes to the reportee account's page they will NOT be able to see anything)

Q: We'll likely also allow the user to specify a reason at some point, which in terms of the data we store can be a label. Do we need more than one label per post/account, "this is both 'sexual content' and 'violent'?

A: That is an excellent question to be fair. And although it seems natural to go that path, I am against the idea to have more than one label simply because it will lead to very unclear and complex data to read. TikTok had the exam same logic where they would allow users and moderators to label content for multiple things but it led to a very difficult understanding of what users were facing and very broad interpretations on the TikTok T&S side. My personal take is that we should mandate users to select one option only and potentially let them add additional comments if they feel like the option is not enough to describe the issue for instance.

Let me know your thoughts on all of the above

[gabehamilton]

That's very helpful. Maybe reporting is a hide with one of certain labels?
So hide with no label would not go to a moderation queue. Hide and choosing a label of csam, nudity-nonconsensual, spam, etc would send it to the moderation queue. Later on see-less could also be a label, one that does not trigger moderation. Blocks would not trigger moderation but some % of blocks could.

@charleslavon @shelegdmitriy The data we store in each account could then look like this.

{ moderate: { 
    "myexpartner.near": "block",         # block, no report
    "annoyingreplyer.near": "block"      # block, no report
    "justhide.near": "",                 # hide no report
    "reportedaccount.near": "csam",      # hide and report
    "account1.near": {
        "100000123": "",                 # hide no report for a post
       "100000456": "spam",              # hide and report for a post
       "100000456": "flag",              # hide and generically report
       "100000456": "see-less-user",     # hide and see less of a user
       "100000456": "see-less-topic",    # hide and see less of a topic
    },
  } 
}

[tidus974]

Oh I see, I think that does make sense yes.
From a data standpoint Hide can be stored with no moderation value which would help distinguish hide + report VS hide
Yes 100%

[gabehamilton]

I realized that there are a couple more issues to sort out.

1. This data structure works for the transition from hiding posts to hiding the whole account but not the reverse. If a user un-hides an account they likely will still want posts from that account that they have previously hidden to remain hidden.

2. We should make it possible (at least in terms of data storage) to moderate anything. So we need more than just block height in the keys below an account: either paths like "comment/100000123"; or objects like {comment: "100000123", words_on_near: {invite: blockheight: "100000123", index: 7}}.

It's advantageous if the data stored for moderation decisions and for reporting/self-moderation has a similar structure. This will help with features like opting-in or following moderation panels and composing moderation trees.

3. Moderation decisions will be a larger data structure than we want to store under an account in the contract. Some users may encounter this as well if they do a large amount of reporting/self-moderation. So it would make sense to store just the latest moderation actions in each block and have the indexer keep track of the whole set, just like we do for posts and comments.

4. If a user's reporting/self-moderation data moves to private storage (once that is available), the Indexer based pattern (solution to # 3) may not work, we may need to store and retrieve the whole set of the user's data.

[gabehamilton]

To address those issues here is an updated data structure. This is the format for data that will get stored for each user. For now this is in the contract, later it can move to private storage. That handles 1, 2, and 4.

The moderator account will save moderation actions in the index format (see bottom of this post). That will be converted by the indexer into this format for use in the front end.

{ 
  "moderate": {
    "reportedaccount.near": "csam",      # hide and report
    "reportedaccount2.near": "report",   # hide and generically report
    "myexpartner.near": "block",         # block, no report
    "justhide.near": "hide",             # hide no report
    "annoyingreplyer.near": {
      "post/comment": "hide",            # hide all comments from the user
    },
    "account2.near": {
      "": "block",                       # after action on some posts, the user blocked the whole account
      "post/main": {
        "100000123": "hide"              # hide no report for a post
        "100000451": "spam",             # hide and report for a post
        "100000453": "see-less-user",    # hide post and see less of a user
        "100000454": "see-less-topic",   # hide post and see less of a topic
      },
      "post/comment": {
        "100000451": "report",           # hide and generically report a comment
      }
      "pokemon/battle_updates": "hide",  # hide an arbitrary activity type
      "pokemon/challenge": {
        "100000451": "hide",             # hide a particular instance of an arbitrary activity
      }
    },
  }
}

Example of a moderation action being saved in the index format by the moderation account. This example shows an action to label and block a post. The MODERATION_ACCOUNT for near.org is bosmod.near. A different gateway could use a different moderation account.

{
  "index": {
    "moderate": [ "{\"key\":\"MODERATION_ACCOUNT\", \"value\": {\"path\":\"reportedaccount.near/post/main\",\"blockHeight\":100780071, \"label\":\"spam\"}}"
  }
}

[charleslavon]

👏🏾 this looks like a great start with the flexibility to cover a breadth of moderation use cases.

[gabehamilton]

An additional feature we'll likely want in the future is expiration, "hide this user for 24 hours", "prevent this user from posting for 1 week". For this we need an expiration field.
In a moderator action that is easy to add to the value.

{
  "index": {
    "moderate": [ "{\"key\":\"MODERATION_ACCOUNT\", \"value\": {\"path\":\"reportedaccount.near/post/main\",\"blockHeight\":100780071, \"label\":\"spam\", \"expiration\":\"2025-12-31 00:00:00\"}}"
  }
}

In the self-moderation and compacted form that can be

       "": {expiration: "2025-12-31 00:00:00", label: "block"},                    
      "post/main": {
        "100000123": {expiration: "2025-12-31 00:00:00", label: "hide"} 
        "100000451": {expiration: "2025-12-31 00:00:00", label: "spam"},
      },
      "post/comment": {
        "100000451": {expiration: "2025-12-31 00:00:00", label: "report"}, 
      }

[charleslavon]

The hide this user.. language is a more precise way to represent what will be under our control, since we cannot prevent someone sending a transaction to post to socialDB.

[gabehamilton]

Good point. If that's a moderator taking that action, instead of "prevent this user from posting for 1 week" we can have a contextual message that says "For 1 week this user's activity will not show in near.org Feeds and near widgets".

[gabehamilton]

Latest full example of the data

Index (Moderator decisions) format

{
  "index": {
    "moderate": [ "{\"key\":\"MODERATION_ACCOUNT\", \"value\": {\"path\":\"reportedaccount.near/post/main\",\"blockHeight\":100780071, \"label\":\"spam\", \"expiration\":\"2025-12-31 00:00:00Z\"}}"
  }
}

User's self moderation format and compacted version of index format.

{ 
  "moderate": {
    "reportedaccount.near": "csam",      # hide and report
    "reportedaccount2.near": "report",   # hide and generically report
    "myexpartner.near": "block",         # block, no report
    "justhide.near": "hide",             # hide no report
    "annoyingreplyer.near": {
      ".post.comment": "hide",            # hide all comments from the user
    },
    "account2.near": {
      "": "block",                       # after action on some posts, the user blocked the whole account
      ".post.main": {
        "100000123": "hide"              # hide no report for a post
        "100000451": "spam",             # hide and report for a post
        "100000453": see-less-user",    # hide post and see less of a user
        "100000454": "see-less-topic",   # hide post and see less of a topic
        "100000455": {"expiration": "2025-12-31 00:00:00Z", "label: "hide"} # action with expiration
      },
      ".post.comment": {
        "100000456": "report",           # hide and generically report a comment
      }
      ".pokemon.battle_updates": "hide",  # hide an arbitrary activity type
      "pokemon/challenge": {
        "100000451": "hide",             # hide a particular instance of an arbitrary activity
      }
    },
  }
}

Additionally user actions that create a report get an index entry for compatibility with moderation systems that use Social.index.

"index": {
      "moderation": "{\"key\":\"reported\",\"value\":{\"path\":\"somebadaccount.near/post/main\",\"blockHeight\":104325030,\"label\":\"report\"}}"
    }

[gabehamilton]

Note that in the user's self-moderation, paths (/post/main, /post/comment, etc) are stored with . instead of / because / is not allowed in keys in social.near contract data.