NIP-64 - Trust Score

[arthurfranca]

Read here

[alexgleason]

We really need to get kind 30382 and 30383 in the NIPs. This is just sugar on top.

[arthurfranca]

Seeing Trustroots/nostroots#20 from #1208 (comment) comment, I rewrote this trust score proposal .

Imo the above is better than the NIP-77 from #1208. For example, using NIP-77 in the current form a client can't fetch just "good hosts" directly from relays. While NIP-64 make it possible by requesting events with this filter: { "kinds": [30382], "#T": ["3:inn:host", "2:inn:host", "1:inn:host"], authors: ["people", "i-became-friends-with", "at-trust-roots"] }

Another good thing about NIP-64 is it reuses kind:30382 event that is meant to enable an user adding public information about another user, not just trust/review data.

[huumn]

Stray recommendation: it might be worth providing a design that's compatible with float, rather than just int, trust scores.

I haven't seen floats used much in the NIPs last time I read them, so maybe there's a bend against them, but for something like trust, it can help to have more granularity, especially if trust isn't entirely explicit.

So long as the float is constrained to [-(2**53)+1, (2**53)-1] it should be interoperable with most JSON implementations.¹

Footnotes

1. https://www.rfc-editor.org/rfc/rfc7159.html#section-6 ↩

[dluvian]

If a client doesn't recognize a topic name it will probably be discarded when updating the event. We shouldn't rely on devs being altruistic enough to write extra code just for the sake of not nuking content of other clients.
We also shouldn't overload events. A wiki client doesn't care about car reviews, so they shouldn't be forced to download it when fetching wiki reviews.

Maybe add the topic to the d tag to separate reviews like ["d", "<top-level-topic>:<pubkey>"] ?

[arthurfranca]

This all is yet to be implemented, feel free to test other ideas derived or not from this.

["d", "<top-level-topic>:<pubkey>"] works too. Most pubkeys wouldn't have multiple T tags, in fact if using kind:30382 most would have none. Usually an user won't add that many metadata about another user. That's why currently I think stuffing diverse metadata inside the same kind with d-tag=another-user isn't a problem.

[franzaps]

@arthurfranca what's your npub? Can't seem to find you

[arthurfranca]

@franzaps npub1l3cgtsurhfchg4cyhhqudm70074sr96srhje330xc5m6czej5n9s9q6vs2

[arthurfranca]

@huumn agree some use cases may need more precision. Problem with floats is you can't ask relays for all events with trust within a specific range of floats, that's why i used (a small set of) integers.

A ["trust", "context", "1.33"] tag, to be read client-side, could be included in addition to ["T", "1:context"]

[huumn]

@huumn agree some use cases may need more precision. Problem with floats is you can't ask relays for all events with trust within a specific range of floats, that's why i used (a small set of) integers.

Great point. afaik all queries use equality and set inclusion because most nostr things don't need range queries.

edit: one exception is created_at but that's not a tag