3rd-party Content Certifications (a tag validation proposal)

Nobody has claimed this yet.

### The Problem:
Honest tags are critical to retaining users and supporting the family as the unit of society. People need safe exploration. However, those that push addictive or overpriced content are economically motivated to lie about their tags. Examples: https://hbr.org/1990/09/why-be-honest-if-honesty-doesnt-pay . We need to reverse that motivation. Lying should decrease profitability, preferably causing content to be completely excluded.

### Alternative Solutions:
1. Have consumers add tags and/or down/upvote them. Some rules would apply for when tags could be replaced. The problem with this approach is that 10% of the tags are wrong at any given time, and new content will not have reliable tags. Consumers are generally not economically motivated to tag vast amounts of content. The numerous data points for this are also difficult to store in a distributed fashion.
2. Use algorithms to analyze content and tag it. This is difficult to get right and requires expertise and computing power that are not available to us.
3. Let the publishers lie about their tags but allow people to permanently block publishers or content. Again, where would we store this data? We need a safe homepage and safe exploration for kids; this approach would not allow such things.
4. Use a web of trust; users explicitly trust (or untrust) various publishers, which then makes all of the content that they trust available (or hidden). This will require rules of the graph -- explicit distances of trust, etc. It seems prone to error, either excluding too much or too little.
5. Scour the web for matching content and use tags/ratings from there. Eh, we really want original content to bring people to us.

### Proposed Solution: Make Certifiers 1st-class Citizens
- We presently have two primary players: publishers and consumers. We will add a 3rd: certifiers, which is really just an additional role for a publisher.
- We presently support some embedded metadata with each claim. We will add to this a flag that a publisher wants to be a certifier.
- We will also add the necessary identifier for the certifier's logo and rules and required fee/percentage. Supports will be enhanced to include a (size-limited) metadata field.
- After that, publishers may submit special "cert req" supports to these certifiers requesting certification. If the certifier refuses to certify that content, it refunds the support money. If it accepts the request, it creates a new "merits cert" support with the remaining money.
- When we render content pages, we need to show the logos of the supported certifications.
- The search page will be enhanced to allow filtering of certifications (exclusively or inclusively).
- If content has more than 5-ish certifications, we would limit the amount shown, only showing those top five certifiers with the most requests.
- We would also enhance the search page to enable searches for certifiers, with useful info about the popularity of them.

### Q & A:
1. What changes on the blockchain to support this? Only the addition of metadata to supports.
2. How are certifiers economically motivated to work? They get fees. We may also want to add an option to allow certifiers "view it first" privileges.
3. How are certifiers economically motivated to tell the truth? No one wants their certificates if the consumers exclude them.
4. How are publishers economically motivated to certify their content? Users will restrict their searches to known and trusted certifiers.
5. How do we use this mechanism to ensure new users aren't shown offensive content? The landing page has to filter to well-known certs.
6. How are consumers motivated to utilize certifications? They will help users minimize time in searching, and economic benefit.
7. Why do we need both tags and certifications? Certifications may suffice without tags, in which case we may want a window of time for certification before data goes live for general consumers. At the same time, we want publishers to be empowered and self-directed.
8. How long do certifiers have to certify specific content? The support request could include a timeout.
9. Even with certificates, would it be useful to permanently block a publisher? Maybe occasionally. It probably isn't too difficult to add this into a user's default search criteria (which should also affect their "similar to" content searches).
10. How do we prevent ourselves from getting overran by certifiers? TBD.
11. Can certifiers solicit publishers? TBD. Can they adjust their fees to improve their rank on the certifier search page?
12. Can certifiers send unsolicited certifications? There is nothing in the proposed blockchain handling to prevent this.

Start by reviewing the proposed certifier roles, metadata on supports, certification requests, content rendering, and search filtering described in the issue. No files, tests, or entry points are named; the work is not complete until the unresolved design questions are settled and the blockchain, certification, rendering, and search behavior are specified.

Written by the indexing model from the issue text.