And a list of who has crypto in their profile and how much overlap we see in these two lists 😜😂

Should we write up a PR and put it up for discussion?

It would be a simple addition to nip-51. Add it to the table of event kinds and have a sentence or two to describe it.

I’m liking your idea. We’d have to check to make sure 30002 isn’t being used for anything else.

I’ve never used report event so I’m not sure. I guess it depends on who the event gets reported to and what gets done with it. Is it a developer-curated mute list that applies to everyone using that client? Or get passed along to relays and they use it to blacklist bad actors?

Not a bad idea. We would run into the problem that sometimes people mute others bc they just don’t want to get into certain topics, like politics. I recall zooku saying he did that long time ago on Twitter. But if people keep in mind that there’s a public and a private mute list, and the public one is for the universally-recognizable bots, that probably wouldn’t be much of an issue.

Following this train of thought:

Pretty soon you run into the problem that even if Alice and Bob each have a list of “trolls,” they may not have the same understanding of what constitutes a “troll.” Which makes it hard to merge lists by different people, if all you have is a list title without a definition.

Which is why I added DIP-03 to the basic principles of dcosl: every list needs to have a cryptographic identifier so you can have multiple fields, like a definition, in addition to the list name. That way Alice and Bob can maintain separate lists with the same list name, troll, but separate definitions of troll. Then Charlie can decide he likes one definition over the other, and adopt that list.

NIP-51 allows Alice to make a list and add items to it, but doesn’t provide the mechanism for anyone else to help curate the list for her. There would need to be a way for Alice to endorse Bob as a curator of that list, and then Bob would need a way to add items to the _same_ list.

You can make a list of people (kind 30000) or events (30001) and use the d tag as a name for the list.

This is how listr.lol does it (at least that’s my understanding? nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc)

You can have a mute list using kind 10000, per nip 51. And it can be public (in tags) or private (encrypted in content.)

https://github.com/nostr-protocol/nips/blob/master/51.md

The way Pretty Good Apps functions right now:

You make a list called “mute list” (or “bot list” or “troll list” or “real people but I want to ignore them anyway” or heck, make ‘em all). She can now add profiles by hand to the list. And she can manage the list herself.

But the app also maintains a list of users that is managed by her WoT. The app automatically creates an attestation that translates: Alice endorses Bob as a curator of that list. So if Bob adds Zed to his list, then Zed will pop up on Alice’s list. And endorsements are transitive: if Bob endorses Charlie to curate the list, then Charlie will also influence Alice’s list.

Tony’s comment made me realize that no, this would not actually satisfy DIP-02, because we’re scraping the filled list and inferring that follow == trust to help curate my mute list.

(Not sure if I’m linking to his comment correctly but we’ll see!)

nostr: note13fleh09v737x3r6ndg490f5at3frjf39zeyngl9w49hqw0afdkuq2734pm

https://damus.io/note13fleh09v737x3r6ndg490f5at3frjf39zeyngl9w49hqw0afdkuq2734pm

This is an important point. Important enough for me to put DIP-02 way up high on the list of principles for dcosl. Basically, DIP-02 says that stuff like mute lists should be calculated using explicit attestations (“I select Bob as someone to help manage my mute list) rather than inferences, often incorrect ones, from scraped data. (e.g. scrape Alice’s follows list and infer, often incorrectly, that if she follows Bob then she wants Bob to curate her mute list.)

https://github.com/wds4/DCoSL/tree/main/dips/coreProtocol

This, except mute list instead of relays.

I’d love to see one of the popular clients do this. nostr:note1eghxdc75k62uaw8gyylnz0jwqvdhy3lf2qklf34k8g6szjvrqusqz8n2zr

It would more or less follow the principles of DIP-01 (a list managed by your WoT, which means distinct lists for distinct users) and DIP-02 (based on explicit attestations instead of scraped data). I can’t think of any existing feature of any existing client that does that. (Except for my WoT-generated relays list, sorta.)

https://github.com/wds4/DCoSL/tree/main/dips/coreProtocol

What would you say about scraping a list of everyone muted by your follows (nip-51) and auto muting anyone who’s muted by some threshold number of them?

Maybe let users view the curated mute list the way the relays list is viewed below, and then select the threshold number of mutings before you auto mute. Would be interesting to see how many profiles get muted by lots of follows vs muted by just one or two.

Maybe also include follows’ follows.

What about muting any user who is nip-51 muted by your follows? (Or maybe needs to be muted by 2 or more follows, or some percentage of your follows). Seems like a lot of bots would disappear pretty quickly that way.

😋