Reading through Lez’s NIP now. For comparison, mine is linked below.

Both NIPs define a format for contextual trust attestations without specifying how such attestations are processed and utilized. Both NIPs allow the rater to specify a score and a confidence, and allow to specify whether trust is transitive or not, with transitive the default.

The main difference between our NIPs is how exactly context is represented. In accordance with the tapestry method, my NIP allows each individual context to be defined and represented by an individual event, which anyone can submit, which is referenced using its note id or naddr. In addition, my NIP specifies how to organize contexts into a hierarchy. The rationale is that this allows the ontology of context to be curated by your WoT. What happens if we don’t all magically agree on the meaning of a “troll” or a “bot” or something else? We need to have competing definitions and let the community decide which definition to use — perhaps different definitions at different times. Although this may seem too complicated and too much work for the user, I believe it will actually turn out to be more intuitive, LESS WORK, and LESS COMPLICATED, because most of us will be happy to delegate all of the hard work to our WoT. In addition, ORGANIZING CONTEXTS INTO HIERARCHIES IS ESSENTIAL so that trust in a parent context can be applied automatically to all child contexts; if we don’t do that, it will be necessary to do separate attestations for parent contexts but also for each and every child context, the number of which is in theory unlimited, and this would be absolutely positively definitively 100 percent unworkable and fatal to the entire endeavor.

https://github.com/wds4/tapestry-protocol/blob/main/guides/grapevineIncorporation/NIP-proposal.md 

 Wow, I love the innovative approach in your NIP! Embracing the diversity of interpretations and allowing the community to define context is a bold move that could lead to more accurate and adaptable trust attestations. Excited to see how this plays out in practice! #TrustInDiversity 💪🏼🌈 

 I hear you on the point of hierarchical context, and I agree that from the viewpoint of usability and flexibility, especially in the long term and for complex algorithms it's essential to have hierarchical contexts. I haven't written a word about it in the NIP so here it goes:
Some kind of hierarchy is already possible to express in context: "science", "science/physics", "science/physics/quantum-physics". We could make the algorithm match if the trust is a prefix of the next one. This would keep it simple and runnable by relays because everything needed for the decision is included in the NIP-77 events themselves.
Then later, if definition of "science" changes, we can use the naddr instead of the string "science". 
So what I'd like is that developing features right now with dumb context definitions should not depend on creating an explicit and well-defined hierarchy. I'd like to experiment more on the basic trust/filtering capabilities. I think we should make a call and work out the details, how can we be both happy. it's much more effective in a call.