• The End-User Perspective
• The Client Developer Perspective
• Beyond Trusted Assertions: The Need for Trusted Lists
• On-Demand Requests: DVMs
• Conclusion

At NosFabrica, we believe that users should have maximum control over their user experience. This principle has lead us to champion two ideas: that trust metrics should be personalized (tailored to each individual) and portable (movable across clients and platforms).

In my earlier article, Separation of Trust and Client, I argued that personalized trust metrics should be computed in one place, a **Web of Trust Service Provider **(WoT SP), distinct from the Nostr clients where they are consumed. This naturally reaises the question: how should WoT SPs deliver these metrics to clients?

This article argues that the Nostr community should adopt shared, interoperable protocols for delivering trust metrics. To understand why, let’s examine the problem from two particularly important perspectives: the end user and the client developer.

§The End-User Perspective

Users must retain full, granular control over their trust stack. Alice should be able to select not only which trust metrics she wants to follow, but also which WoT SP she wants to calculate each one. For example, she may select:

• Service Provider 1 to calculate baseline Trust Scores

• Service Provider 2 to curate her 24-Hour Trending Content Feed

• Service Provider 3 to surface the best up-and-coming musicians in her favorite genre

Furthermore, she should not have to repeat these choices for every new client she tries. Her preferences, once set, should be stored so that they can travel with her, changing only when she decides to change them.

The Trusted Assertions NIP already solves the preference-storage problem beautifully: a single, portable kind 10040 event records exactly which service provider is responsible for each metric.

§The Client Developer Perspective

Client developers should not be forced to integrate with every WoT Service Provider individually.

Ideally, a client that supports community standards such as Trusted Assertions should automatically support every compliant WoT SP, without maintaining an ever-growing list of endpoints, authentication methods, or data formats.

For many use cases, the Trusted Assertions NIP already moves us most of the way there. For a specific pubkey or event id, multiple trust metrics are bundled into a single kind 3038x event. Clients can read and apply these metrics without knowing (or caring) which WoT SP authored them.

§Beyond Trusted Assertions: The Need for Trusted Lists

Trusted Assertions work perfectly for per-pubkey or per-event metrics, but many use cases require ordered or filtered lists:

• “Top 10 trending posts in the past 24 hours”

• “Most trusted accounts in the Rust programming community”

• “Rising musicians ranked by Tunestr listeners”

The current Trusted Assertions format cannot efficiently deliver ranked lists. We should perhaps consider a companion specification, which we may call the Trusted Lists NIP, that standardizes how service providers publish ordered or curated lists of pubkeys or event ids along a given trust dimension. Think of this as a cross between Trusted Assertions and NIP-51 lists.

§On-Demand Requests: DVMs

Neither Trusted Assertions nor a future Trusted Lists NIP specify when or how these events are generated. Some metrics might be push-based and continuously updated; others are expensive and should be computed only on demand.

To remain service-provider-agnostic, we need a standardized request/response flow. The cleanest path is to treat requests themselves as Nostr events directed at the relevent WoT SP’s pubkey, discoverable via the user’s preferences as recorded for Trusted Assertions (kind 10040) or Trusted Lists (full specification to be determined). This is precisely the model behind Data Vending Machines (DVMs) and ContextVM. Using the DVM or ContextVM frameworks as models, the community can come up with standardized methods for triggering fresh Trusted Assertions, Trusted Lists, or other trust-derived data.

This does not preclude traditional HTTPS APIs. NIP-86: Relay Management API already provides a standard envelope for Nostr-native HTTP APIs. Using this NIP as a model, the community can define WoT-specific request and response schemas in a manner that achieves both flexibility and interoperability.

§Conclusion

Web of Trust Service Providers occupy the same structural niche as email providers or Lightning service providers. Protocols that vary from one WoT SP to the next will not only slow growth of the ecosystem, but will also repel users and client developers wishing to avoid vendor lock-in. One of the goals of the NosFabrica Web of Trust Hackathon is to help foster a dialogue between WoT Service Providers and client developers in the development of these shared protocols.