Yeah that is right. All you'd really need to make mute lists comprised of other lists work well for users is to have clients parse a user's mute lists in a recursive way – e.g. when they come across a list in the mute list, they'd need to fetch that list too and add the users/threads from those lists.

I don't know how many clients already do this...

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 ?

Reply to this note

Please Login to reply.

Discussion

I see. Alice’s mute list would effectively parse into two lists: one list of pubkeys to mute and one list of lists of pubkeys to mute. Putting someone else’s list on the list is pretty close to being an explicit endorsement of contextual trust. And it could be implemented transitively, if desired. Maybe up to N hops away. And perhaps a user showing up on a list two hops away counts for less than just one hop away.

I very much like the idea of putting together a mute list in the way you’re describing. It comports with the abstract notion in DIP-01 of dcosl, which makes explicit the idea that community-generated lists (of whatever) ideally shouldn’t generate one list for the community, but rather one list for each user. It’s a principle worth thinking about in the abstract.

I actually wrote about that idea 8 years ago. Damn.

There are a few other abstract ideas that flow naturally after this one that are also worth explicit consideration imho, if we are ever to make a web of trust that lives up to its potential.

https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/Principle-of-Relativity-for-WoT.md