Also thinking about this:

"zero score means it's outside the social graph entirely, which correlates strongly with spam"

It seems entirely possible that there could be popular spam and unpopular high-value content, which may be outside the social graph entirely. One could argue that this is often the case.

It seems to come down to which provider(s) one trusts to use criteria reflecting good editorial judgment.

This is interesting, but it actually doesn't seem to validate my original intuition. That intuition was:

"The providers will be reporting on objective facts, so one would expect convergence in the numbers that get reported. That should then make it less necessary to place special trust in any single one provider."

I think you're saying that the numbers reported by different providers will possibly / likely not converge?

But why is that? The graph crawled from seed pubkey set A may differ from the graph crawled from seed pubkey set B, but as a provider won't you then aggregate the information you have gathered from both crawls?

I imagined that scores / rankings would be calculated based on aggregate information from all crawls across the seed sets that were used.

Makes sense. I've not really had to contend with spam with my new account so far, but I guess this becomes more of a problem later.

From what I've learned at this point, the basic issue seems to be who can *contact* you.

You yourself can select the people you follow, so there isn't any obvious need for a technical solution here. As for curated content, you can choose providers just as you can subscribe to TV channels. Providers that generate automatic feeds will likely want to use a spam filter for their feed, but whether / how they do this is maybe not a central problem for nostr as a protocol, unless feeds are crucial to the experience you want to have.

So the remaining problem is then that one gets too much spam in one's replies or notifications. One could solve this by filtering replies and notifications by follow-distance, but that would close one off to the world at large. If you want to stay open for everyone to make contact with you, which is arguably desirable, you thereby open yourself up to spam. And that's where we need a technical solution. And it seems like your verifiers would do the job.

To be more precise, there should be nothing in Inkan that automatically prompts you to sign kind-3 following list events. You can of course manually add or remove followers as you would otherwise in jumble, but there should be nothing that asks you to sign events that add 500 followers to a pubkey.

If you notice any strange requests to sign kind-3 events while using Inkan, by all means let me know - but there really shouldn't be anything like that, and I've been using it for a while now without experiencing anything of that sort.

Please feel free to create another test key pair and send me the pubkey. I'll put it on the allowlist.

Inkan should not have caused the followings since the private key should have stayed in your browser extension without ever being sent to the site. You may want to check your browser extension setup, or maybe the method you used to create the key pair (did you maybe use some sort of online generator?). Inkan is just using NIP-7.

I'll hopefully automate registration later, but at this stage I'm just looking for people to try it out, get an understanding of it and provide feedback, maybe let others know that it's available.

A pubkey could of course nonetheless use follow lists to signal not that the followed key is interesting, but that it is human and not a spammer. It's ultimately a matter of intent and convention. But yeah, using follow lists this way might be confusing, and have technical limitations.

We currently have basically only two pre-defined modes of expressing approval or disapproval of a pubkey, through public following and public muting. Expanding this to include other information - e.g. "is human" or "is not a spammer" - seems useful, although one wonders how far the range of pre-sets should go (one could have verifiers for "is safe-for-work", "is appropriate for children" etc.).

Your dedicated verifier idea seems to be quite implementable.

You just have to have a pubkey that hold itself out as a "verifier" and vouch for all the pubkeys that it follows. Actually, on second thought, you don't even need the pubkey to "hold itself out" in that way. You can just choose to treat any existing pubkey whose social judgment you trust as a "verifier".

Then all we need is a functionality in clients that lets a user set a list of the user's trusted verifiers, and then the client filters out all pubkeys that are not followed by any of the verifiers specified by the user.

Am I getting this right?

NIP-85 seems fine for what it is.

Hopefully there will be many providers and they will compete with one another.

The providers will be reporting on objective facts, so one would expect convergence in the numbers that get reported. That should then make it less necessary to place special trust in any single one provider.

The question remains how the reported information should be used. Hopefully there will be a culture of always putting the question of how such information should be used (if at all) to the individual user, who can then decide.

Agree.