Wikilink tags and Trust Rank NIP (and how to apply it to wikis) #1220
Conversation
54.md
Outdated
| Those tags are handy when searching for topics related to an article. | ||
| They may be used as labels to tell two articles with the same `d` tag apart. | ||
| They are also used when [ranking authors](#author-ranking). |
There was a problem hiding this comment.
Having y and z tags instead of just t tags for these use-cases feels overly complicated.
There was a problem hiding this comment.
Agree. Though used r instead of t. People tend to over use hashtags and I think the d value would end up being a t tag too, which is not the intent.
64.md
Outdated
| "kind": 30382, | ||
| "tags": [ | ||
| ["d", "<pubkey>"], | ||
| ["T", "3:wiki:role-playing-video-game", "x"], // has written a based wiki article about RPG | ||
| ["T", "2:driver"], // polite and skilled driver but doesn't turn the air conditioner on | ||
| ["T", "3:buyer"], // no problems when selling to this person | ||
| ["T", "-2:seller"] // had a bad experience when buying from this person or company |
There was a problem hiding this comment.
I would prefer a different kind for each trust rank application or another indexable tag that sets the application like ["D", "wiki"]. Otherwise a wiki client would just discard the driver, buyer, and seller tags when updating a wiki value, because these are not useful for the client, leading to interoperability issues.
There was a problem hiding this comment.
Added this:
If a client doesn't recognize a topic name, it should leave the corresponding
Ttag untouched. For example,
a wiki client will only add/update/removeTtags with topic names starting withwiki:.
This kind comes from @vitorpamplona's #761.
I think a good side effect of using trust metrics related to wiki content is that for someone to become trusted on a topic they would first have to write a good public wiki article about it.
There was a problem hiding this comment.
My point remains. Leaving junk data untouched would require client devs to write extra code for no benefit to their own clients. It's also more bandwidth efficient if I can query only the tags that are of interest to me.
There was a problem hiding this comment.
Leaving junk data untouched would require client devs to write extra code for no benefit
Even if there was a kind just for ranking authors of wiki articles, the client would have to fetch the latest version and don't touch ratings on topics other than the current one. Similar work.
[...] indexable tag that sets the application like ["D", "wiki"] [...] It's also more bandwidth efficient if I can query only the tags that are of interest to me
One isn't supposed to fetch all wiki-related trust scores but do one article at a time like this:
{ kinds: [30382], authors: ['<my>', '<follows'>, '<...>'], #T: [
'3:wiki:nostr',
'2:wiki:nostr',
'1:wiki:nostr',
]}
The above will return just people with positively ranked knowledge on the encyclopedic nostr topic (randed by one's follows). Those with the d marker will lead to a recommended article variant. Pubkeys ranked with r markers can be used on a follow-up query in the authors filter till reaching a d marker to lead to a recommended article variant.
There was a problem hiding this comment.
Even if there was a kind just for ranking authors of wiki articles, the client would have to fetch the latest version and don't touch ratings on topics other than the current one. Similar work.
No. All wiki ratings are relevant to a wiki client, every other ranking is junk. Same with the legacy follow lists. If a client does not implement following relays and hashtags than it would just ignore these tags, why would the client cache these irrelevant tags? This leads to clients nuking each others lists.
Nip51(Lists) does it right, having a different kind for each use-case because managing one giant list is hell, same applies to these rankings.
Also it's much more efficient if you don't have to constantly refetch and validate the event when a marketplace client changes tags that have nothing to do with your wiki use-case.
Doesn't have to be a new kind, maybe put it in the d tag like ["d", "wiki:<pubkey>"]
64.md
Outdated
|
|
||
| The `kind:30382` is used to assign public relationship statuses between the event author and a pubkey set to the `d` tag. | ||
| This NIP assigns one or more trust ranks by adding `T` tags with different topic names to such event | ||
| using the following structure: `["T", "<int_value_ranging_from_-3_to_3>:<topic-name>", "<context_dependent_marker>"]`. |
There was a problem hiding this comment.
What do you think about ["T", "<topic-name>", "<int_value_ranging_from_-3_to_3>", "<context_dependent_marker>"]?
This way you could easily query a pubkey's trust rank for a topic.
There was a problem hiding this comment.
Your example doesn't allow to filter on relays by trust score.
The reason the score has few possible values (-3 to 3) and goes together with the topic name is that it enables filtering on relays by both (always picking one or more specific topics).
Filter examples:
All "nostr": { #T: ['-3:wiki:nostr', '-2:wiki:nostr', "...", '3:wiki:nostr'] }
Positive "nostr": { #T: ['1:wiki:nostr', '2:wiki:nostr', '3:wiki:nostr'] }
Negative "nostr": { #T: ['-3:wiki:nostr', '-2:wiki:nostr', '-1:wiki:nostr'] }
"nostr" gurus: { #T: ['3:wiki:nostr'] }
|
Am I expecting too much from this or am I right to expect these changes to:
|
|
Gonna separate the trust nip part |
Edited TLDR:
When user gives a thumbs up/down to an article, wiki client auto sets the trust rank for the wiki author relative to the said article (and to some other closely related articles; most likely the first two article links).
By looking at an user network (him and his follows) of trust metrics, client can figure out the best article version to show.