Just seeing all this.
1. You can have lists of lists. So that makes things like compiling a list based on other lists created by other people trivial.
2. The limitation would be the that clients wouldnāt recognize those lists as your mute list. Or would not process it properly to mute people in the lists included in your mute list.
3. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z could probably fix the above.
I want to have lists of lists! So far I've only seen this supported in Highlighter
You mean: Alice, Bob and Charlie each make a list using nip-51 (either 30000 or 30001), and then Dan makes a kind 30001 list referencing each of those 3 events?
Actually that wouldnāt work, because the event id changes every time Alice updates her list. If Dan wants to make a list of nip-51 lists, each item on his list would itself be a list and would need to specify:
- pubkey of that itemās list author
- the list kind
- the list d-tag (if kind=30000 or 30001; not needed if kind=10000 or 10001)
Then the client would look for the most recent event that fits that criterion.
So Danās list would be: kind 30000. What would be the d-tag of Danās list? How does he specify the d-tag of Aliceās list (and Bobās, etc.)
(Could be Iām just staring past the solution bc itās late and I need š“! Lol )
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."
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
