Allow any node to act as a sheriff and put sheriff's marks on posts and comments. Viewing non-public content should still be allowed manually for every sheriff.
Since there may be a lot of sheriff's marks, need to keep them in a separate table. In GET queries, the client should define explicitly the name of the sheriff whose marks should be used for filtering the results. This makes client-side filtering unnecessary. If client queries a post and it is marked by the sheriff, the node should return a special error code to distinguish this case from absence of the content or lack of permissions.
If the client wants to create (or update) a copy of a post, it should add a parameter to the query asking to include all sheriff marks to the result.
Similarly to the search engine, any sheriff whose name was mentioned in a query becomes "a known sheriff" and the node will need to subscribe to this sheriff's blocked users list.
Only handpicked sheriffs are worthy of notifying the user of their decisions.
Allow any node to act as a sheriff and put sheriff's marks on posts and comments. Viewing non-public content should still be allowed manually for every sheriff.
Since there may be a lot of sheriff's marks, need to keep them in a separate table. In GET queries, the client should define explicitly the name of the sheriff whose marks should be used for filtering the results. This makes client-side filtering unnecessary. If client queries a post and it is marked by the sheriff, the node should return a special error code to distinguish this case from absence of the content or lack of permissions.
If the client wants to create (or update) a copy of a post, it should add a parameter to the query asking to include all sheriff marks to the result.
Similarly to the search engine, any sheriff whose name was mentioned in a query becomes "a known sheriff" and the node will need to subscribe to this sheriff's blocked users list.
Only handpicked sheriffs are worthy of notifying the user of their decisions.