It works because the lists are referenced using #a (address) tags rather than #e (event) tags.
"Any standardized tag can be included in a Categorized Bookmarks List."
Discussion
ahh I had not known about a tags. Ty!
Yup. The id of the list is the three fields that you mentioned earlier. Author, kind, d tag (name of list).
If you change the name of your list you’re actually creating a brand new list. So as long as everyone keeps using the same lists it does work well.
So if I’m following correctly: if we wanted to have a system where Alice maintains a list of users whom she explicitly endorses as curators of a mute list, she could maintain a list of their mute lists. Although there’s currently no standard method in the protocol to communicate “I endorse these lists.” She could put it in the name of her list, and perhaps some naming convention could emerge that’s not in the protocol, although hard to imagine that catching on, and might not be the best way to go about it.
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 ?
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