Subnostr

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?

david 2y ago

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 )

Reply to this note

Please Login to reply.

Discussion

captain ☦️ 2y ago

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."

david 2y ago

ahh I had not known about a tags. Ty!

JeffG 2y ago

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.

david 2y ago

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.

JeffG 2y ago

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 ?

david 2y ago

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.

david 2y ago

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.

david 2y ago

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