nips
nips copied to clipboard
nostr-protocol
NIP-51 Lists
recreating previous lists nip that I inadvertently closed.
previous conversation here: https://github.com/nostr-protocol/nips/pull/114
formatted: https://github.com/monlovesmango/nips/blob/lists/51.md
I think creating a nip for just mute/follow is fine. however, I think a nip for just mute/follow still should cover multiple event types. do we really want a nip for mute/follow of pubkeys, nip for mute/follow of events, nip for mute/follow of hashtags?
in my mind I would think we want a nip that is extensible and flexible, and can easily adapt as new use cases emerge.
you always need to check each tag, you can't ever simply "trust" that it's any kind of tags in there, so specifying what each specific 'd' word means is I think something that belongs in it's own NIP. this NIP would simply introduce the concept of using the tags and encrypted content with the same type of tags inside, but one is private, the other is public. be that exclusively p tags or exclusively e tags or t tags or any combination that anyone seems fit to their purpose, which would then be a NIP and we can expect the same behaviour. you can of course introduce some of those wordings like mute and block and define what those would contain, like only p or only e in this NIP if you feel like that is needed, but I wouldn't use the p:mute logic as it would someday lead to e:p:t:g:likes:subject:mute instead of simply mute and we read the nip and know what to expect.. which is a totally fine thing to do. we can in fact choose that path of using p:follow, but what I'm saying is it doesn't need to be limiting in this NIP
I don't think it makes sense to introduce a new concept in one NIP and then list the standard/taken names in another NIP. its confusing. especially since the behavior is not changing at all, its just about organizing the documentation.
how would it ever lead to e:p:t:g:likes:subject:mute? this can only happen if we don't specify what format it should be in. if I explicitly say there are only two parts, tag type and name, it leaves very little room for people to make up their own.
I think mute should cover event, pubkeys and hashtag muting. I think follow should cover event, pubkeys and hashtag follows. why create confusion and potentially more variations by defining them all individually?
we can in fact choose that path of using p:follow, but what I'm saying is it doesn't need to be limiting in this NIP
yes but the use cases I want to enable by submitting this nip directly depend on this convention. this is central to the nip mechanics.
then you can use it. you don't need to force it on everyone else. that's why I'm saying the option is needed, otherwise I'm not going to be using this NIP, I'd have to use NIP52 or something
it's just an unnecessary friction point. NIPs should be like functions, and some build upon others to form more complex stuff. the simple concept of public / private with tags / encrypted content is what's actually needed. the wording on the d tag is a specific use case that levarages the concept in this NIP to do something specific. we should not be limiting the concept to that particular use case alone. and the concept should also work with simple lists that don't use a d tag
I'm curious what you have against using this option?
I decided to use this format for the following reasons:
- to allow cross compatibility of lists between clients
- to allow segmentation of common list names (like
muteorfollows) by tag type
I think both of these are needed in a lists nip. do you disagree with either of these objectives? do you think there is a better way of accomplishing these? I'm happy to change the design
I personally don't think its efficient to introduce a lists nip that doesn't allow for identifying the tag type for private lists (without requesting and decrypting first).
I'm curious what you have against using this option?
I decided to use this format for the following reasons:
- to allow cross compatibility of lists between clients
- to allow segmentation of common list names (like
muteorfollows) by tag typeI think both of these are needed in a lists nip. do you disagree with either of these objectives? do you think there is a better way of accomplishing these? I'm happy to change the design
I personally don't think its efficient to introduce a lists nip that doesn't allow for identifying the tag type for private lists (without requesting and decrypting first).
I have nothing against your logic, I think it might be a good thing. and IF we all go along, then it may end up working like that in the end for everyone, but I don't think it belongs in the same nip, it discusses another specific thing.
I personally don't think its efficient to introduce a lists nip that doesn't allow for identifying the tag type for private lists (without requesting and decrypting first).
you would know what to expect by reading that specific NIP. So maybe what you want here is changing the title to be more specific of what you want to achieve with your method and introduce to novel concept of using this logic. and so we dn't refer to this NIP as the one for public / private lists but to the mute / follow / ignore and whatever other thing you need NIP
If these lists are "to yourself", why not just encrypt them with your public key and decrypt with your private key? ECDH "to yourself" seems pointless to me.
edit: ~~Or maybe this cryptosystem doesn't support that? I'm more familiar with RSA which does. I'll have to check.~~ edit2: it is used for symmetric encryption so it would be encrypt and decrypt with your private key.
thats what I originally had in mind but on nostr @mmalmi had suggested just using the existing nip04 encrypt/decrypt functions for browser signing. otherwise we would have to implement new functions. I agree that reusing nip04 is much simpler for implementation. I can be convinced either way on this one.
I guess it doesn't matter. You are not exposing the key you are encrypting/decrypting with so you aren't leaking information about the keypair. And NIP-04 has an IV which does a lot.
Carry on.
Sorry, I changed my mind. This nip is not ready for being merged. We probably should not pack everything containing lists of pubkeys or events in the same kind no matter what.
I would appreciate if this nip was changed to simply covering mute/follow.
I agree, there should be a different kind per list. this would allow clients to only pull the lists they need.
I'm pretty happy with this general structure, but I don't think we need the type: thing. clients will probably have to know each d tag and know what to do with them, so perhaps those could be clarified in future nips if necessary. I would be happy with mute for the blocklist in damus, I don't see the point of having both mute and block. I would also be happy with bookmarks and pinned.
thanks all for the comments! let me rework this nip based on everyone's feedback.
I like the <number>x.md format actually, could be for extending a NIP. but how will this interact with supported_nips?
I have some questions:
~~Regarding follow list, how can someone have many follow lists, one per topic? like if i wanted to read updates/feed of a group of pubkeys that usually post about politics, and then switch to a feed based on a group of pubkeys that posts about pokemon. Maybe enhance the p tag with a topic like this
["p", "91cf9..4e5ca", "wss://alicerelay.com/", "alice", "pokemon"]?~~
EDIT: Oh sorry, disregard it. I see that one can create a list with a custom d tag ["d", "pokemon"]. Although it wouldn't have the "follow" meaning treatment by clients guaranteed
Also, how can person A use person B's public follow list, keeping it in sync instead of creating a copy that will get stale? Is it possible with this NIP?
EDIT: Inside person A kind 30000 with ["d", "follow"] could have a p tag with a link/reference/recurssion marker like ["p", "87cf9..4e5ca", "wss://alicerelay.com/", "alice", "link"]). Could link to many other people' lists of same kind and d tag.
@Semisol I feel like this NIP should use NIP-33 for supported_nips because if NIP-33 is supported then all lists are also supported. What do you think? If you agree I will update this NIP to indicate that.
@arthurfranca I think a list for following other's public lists needs to be a new list kind. I am planning on creating a new pr for that separately bc its a new tag type and would be a bit made up. I also want to create a pr for relay lists at some point. But want to wait until the base lists are established first.
@Semisol I feel like this NIP should use NIP-33 for supported_nips because if NIP-33 is supported then all lists are also supported. What do you think? If you agree I will update this NIP to indicate that.
@arthurfranca I think a list for following other's public lists needs to be a new list kind. I am planning on creating a new pr for that separately bc its a new tag type and would be a bit made up. I also want to create a pr for relay lists at some point. But want to wait until the base lists are established first.
we need depends:33
Sorry for arriving late with this question, but why does this NIP specify both separate kinds and d tags? I think it could work with just one or the other, having both seems unnecessarily confusing. Not a deal-breaker, but weird, maybe there is a reason.
Sorry for arriving late with this question, but why does this NIP specify both separate kinds and
dtags? I think it could work with just one or the other, having both seems unnecessarily confusing. Not a deal-breaker, but weird, maybe there is a reason.
it was requested that this nip be a more generic standard for lists in general but also wanted to get started defining the frequently requested list types. now that it is in this format I actually really like that all the different kinds that are used for different list types can be referenced from one nip.
I do expect the number of list types to grow as the number of use cases grow. for example, I expect that there will be lists for long form content as well that list tags for parameterized replaceable events. also lists for relays, or lists of public lists that other users have created.
still open to changing back to a more standard format but personally like this structure more (for lists specifically, not generally).
What do you mean by a "more standard format"?
What I was saying is that we should either define one kind of each list (10010 for "mutes", 10011 for "favorites" etc) or one d tag for each of these, all in the same kind (30001, for example). Both ways would work.
The way it is now is slightly confusing, because I specify d: mute, but then I don't know what kind I must use.
Oh, about having a bunch of kinds and/or d tags specified in the same NIP, I think that is totally fine and good. I'm for keeping this NIP as the directory of all future lists that people may come up with, and update it as time passes. If that's what you meant.
Sorry for arriving late with this question, but why does this NIP specify both separate kinds and d tags? I think it could work with just one or the other, having both seems unnecessarily confusing. Not a deal-breaker, but weird, maybe there is a reason.
Each list kind has tags of different type, the goal is to have a different kind for lists of e, p, t and so on.
still open to changing back to a more standard format but personally like this structure more (for lists specifically, not generally).
+1
