Nostr Web Client

> "We shall never have a good tagging system until it is removed from the central indexers via some sly, roundabout way"

In my view, any attempt at semantic tagging must be built on top of a subjective trust/assertion layer, as in nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 's project.

A tag is essentially an assertion that "this Thing is X":

1. I might agree with Bob's assertion that Thing 1 is X, while I disagree with Alice's assertion that Thing 2 is X.

2. I might agree with Bob's assertion that Thing 1 is X, while I disagree with Bob's assertion that Thing 2 is X.

3. ...additional permutations abound...

All of effects that fall out of the above system are totally tangential to and in conflict with any "global" indexer (especially one that is tightly coupled to a particular client application) that attempts to make the same assertions for everyone.

Each node in the graph should have a very different complex of agreements/disagreements (and weightings for the same) on all tags and all other nodes' opinions of those tags.

The key is **disagreement** and not only allowing for it but more or less requiring it at the lowest levels of the protocol. "Global state" (in this context, a central indexer + client app) is absurd on its face when you have the prior that disagreement is a fundamental particle.

Even if the central indexer allowed for infinite arbitrary assertions on a given Thing, it becomes totally unwieldy and useless if it is collecting every node's disparate opinion.

The natural place for the divergent assertions to live is _at the edges_ - with the node making the assertion.

- You start to build up your worldview by weighting strongly on YOUR OWN assertions...

- Then looking out through your neighbors, taking into account the weight you give to each on THIS topic...

- Then looking at _their_ neighbors and taking into account _their_ weight they give to _their_ neighbors on THIS topic...

That gives you your own subjective view of the graph with trust/credence flowing from you and your own authority out to wherever you say it should go, given your preferences.

I am something of a jihadist on this topic. I'm happy to have friendly arguments about it, but my bar for bending on it is set extremely high after a decade++ of watching it fail to be addressed properly: with Megacorp "social media" handling it worst, and many decentralized social networks getting closer but still failing to cross the final crucial Rubicon.

----

PS: Any individual can _act_, fleetingly, as a "global" indexer if a large number of people happen to trust that individual as a supreme authority on a given topic. But crucially - and this is where the (central indexer + app) model fails - they might be an authority only on this ONE TOPIC.

It is highly unlikely that the node I trust ultimately for "pizza reviews" is the exact same node I trust ultimately for "code reviews".

david 6mo ago 💬 1

I participated in the initial beta test of pubky and I had the same thought as nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6, that tagging is one of the best things about pubky. Simple, easy, useful, user friendly.

NIP-32 could be one way to implement tags in nostr, but a simpler way would be something similar to NIP-56. Same basic structure as NIP-56, but we rename it from “reports” (which obviously has a negative connotation) to “tags”, and instead of a “report type”, we just have the tag itself, which would typically be a human-readable string (but in theory could be any string, like an event id that points to a “tag” with some sort of structure).

Tags generated via either of the above methods, or any other method for that matter, will be great sources of raw data to be fed into GrapeRank, via the process of “interpretation” which will convert the raw data into a format that is ready to be ingested by the GrapeRank algo.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 6mo ago 💬 1

NIP-32 was created from discussions related to NIP-56 already, by that same reasoning I imagine.

I have no idea of how to do the graperank thing already, even less if one is supposed to input arbitrary tags, but if such a thing is possible than I can only imagine it will be great.

david 6mo ago

It’s definitely possible — I and others have built GrapeRank proofs of concept that synthesize follows, mutes and reports into a trust score. Each of these 3 sources of data gets “interpreted” as the first step. Things like replies, reactions, zaps, tags, etc will be straightforward to interpret using the same technique that we’ve already used.

Have you done a deep dive yet into #PageRank? PageRank and GrapeRank are both examples of centrality algorithms. PR is easier to explain, easier to implement and historically significant as the thing that launched Google in1998 and wiped away — like magic!! — the vast majority of spam from internet keyword search. I’m excited to see PR and similar algos in production & in use by nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz9mhxue69uhkummnw3ezumrpdejz76jympz, nostr:nprofile1qqs0dqlgwq6l0t20gnstnr8mm9fhu9j9t2fv6wxwl3xtx8dh24l4auspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgqg4waehxw309ash2arg9ehx7um5wgcjucm0d52m9qj9 and others, and I would like to see more nostr devs understand and appreciate what PR and other centrality algos can do for nostr.

Dawn 6mo ago 💬 2

That last paragraph is what I was thinking. If the labels exist in many places, then anyone can utilize or present them (or not) however they want... there must be a better way to create them, though. 90% of this conversation is well beyond me, but lacking an efficient way to do it, is the only thing that holds me back from labeling things now.

david 6mo ago

I’d love to see one or more nostr clients implement tags. Probably worth looking at how Pubky does it from a UX perspective.

Dawn 6mo ago

I hate to use Amethyst as an example of everything but there's a 'timestamp it' option in the 3 dot menu on each note. A 'label it' option would fit really nicely below that. The same could apply to any client that offers note menu options beyond like, reply, and zap, such as raw event data & n-prefixed idenifiers (or whatever those are called). It would be tucked away but easily accessible to anyone who want to use it. I don't think it would complicate the UX any more than that stuff already does. Talking a client developer into adding it, I think, would be the hard part.