Spot on. IMHO … the essential elements are: - “is trusted” should be explicitly determined by end users. - “filters” that operate from “is trusted” should be subscribable and sharable by end users across all apps. Using this simple architecture, “filters” may “ingest” any data or metadata from the network to satisfy for ALL of the diversity of “WoT algorithms” that smart people like yourself have designed. - use filters for content feeds - use filters for recommendations - use filters to manage the “is trusted” list itself, so a user doesn’t have to. 🤯 What are your essential elements?

Replies (2)

Agree with what you said. This is not exhaustive, but a few essential elements: - explicit trust attestations need to be contextual - trust (or lack thereof) in a broad context automatically implies trust (or lack thereof) in all subcontexts - the list of contexts and their relationships must ultimately be curated by one’s web of trust (but ok for devs to manage these in early product iterations) We don’t need to roll out all of the above in one fell swoop. We can and should roll them out in baby steps. Builders who know DESIGN and who know PRODUCT will be CRUCIAL in figuring out how to roll things out, one step at a time, in a manner that will be accepted by users!
Imagine having a list of filters and tools that allow your WoT to recommend filter A (or some set of filters) to be good ones to use for some given purpose. e.g. my Grapevine recommends Filter A to show me a list of financial armageddon movies from an orange pill perspective