nips
nips copied to clipboard
nostr-protocol
NIP-65 Relay List Metadata (was Feed Advertisements)
Gossip shouldn't have to be so complicated. Nostr should scale better. People should be able to find what they want.
This is related to nip-23 kind10001, except that that NIP is really more about people controlling what their clients do rather than to advertise to others, and has complex hard to code runes language stuff in it and has been sitting around for a long time now.
This is related to kind-3 contact list content, except that Contact Lists are far too long for this purpose and their content was also intended for users to control their own clients rather than to advertise to others.
So I thought a new kind was called for.
Implemented in gossip on branch 'feed-advertisements' with some testing, but needs more testing, however:
I don't want to push out many of these events in case I am colliding with somebody else's kind number (though I searched for 10002 and didn't see it in this repo).
I don't see the need for this because we can already say what relays we read and write from NIP23. this would not solve it, it would introduce a new thing to manage. I agree that the runes thing is complicated to implement if there's nothing that handles runes easily available. NostrTools should have support for that IMO for it to start to be used, I think that instead of this NIP, we could simply use NIP23 in a simplified mode, with only true false values that can later be replaced by runes. This would let most relays implementations in clients switch more easily as it follows the same model of a list of relays with read and write values and would all be valid once runes are implemented.
oh didn't see this post: https://github.com/nostr-protocol/nips/pull/32#issuecomment-1414920744 before posting mine but it's relevant i guess..
We should cancel NIP-23 and use this instead. It is good since we can query for r tags and learn what relays are more popular (is that a good thing?).
What do you think @dskvr @sondreb @monlovesmango @kjsrepo @staab @jb55 @v0l @styppo @koalasat @kaiwolfram @ismyhc @brightonbtc @ekimber?
we could simply use NIP23 in a simplified mode, with only true false values that can later be replaced by runes
That was my original intention with NIP-23, but I think it's an over-engineered solution, specially because we don't have a concrete use case for these runes.
Also this NIP doesn't incentivize people to both read and write to the same fixed set of relays, which is good. And it can be extended with extra elements in the arrays later too (if, for example, someone wants to say they only write about Marlon Brando on relay A and only about Ovos Moles on relay B).
I think we should go with this one now.
if we're going this route, then IMO this array should maybe be better in kind-0 as content.relays:[]. having what relays you post to is pretty integral part of identity, and it would reduce a lot of guessing and events back and fort since kind-0 is pretty much always needed... we already have a bunch of frivolous fields there, it's easily updateable and probably the most up to date everywhere. a simple list of relays there makes more sense to me in terms of practicality.
if that doesn't make sense, and everyone prefers this model, then let's use this kind, but I think having the relay information readily available in kind:0 solves multiple problems at once.
or add the r tags to the kind-0 event tags directly
I really like this NIP, it looks like it would solve the problem of not being able to find where authors are posting.
That said, I think it's solving a much different problem than NIP-23, which is about storing relays and rules for clients to connect to. In fact, I think NIP-23 would support this one well. If the user doesn't have access to the NIP-23 runes rules to clients, then it relies on the client to decide which relays to post 10002 events to (or implement an ad-hoc solution to allow the user to decide). If we accept both NIPs, then it allows fine-grained interoperability between clients.
Regarding runes rules being complicated and no use-case: We are obviously very early doors here, but I believe this is a non-issue. Currently, 99% of everything is kind 1, so it's not too complicated to uncheck "read" on relays you don't want to see posts from (e.g. for spam prevention). Going forward, as more kinds come about, users will absolutely want to block certain event kinds from certain relays. The runes rules do seem a little daunting, but it's only as complicated as a user wants to make it. Plus, it's only a matter of time before some dev figures out a UI paradigm that is intuitive for users.
if we're going this route, then IMO this array should maybe be better in kind-0 as content.relays:[]. having what relays you post to is pretty integral part of identity, and it would reduce a lot of guessing and events back and fort since kind-0 is pretty much always needed...
Good point.
Regarding runes rules being complicated and no use-case: We are obviously very early doors here, but I believe this is a non-issue. Currently, 99% of everything is kind 1, so it's not too complicated to uncheck "read" on relays you don't want to see posts from (e.g. for spam prevention). Going forward, as more kinds come about, users will absolutely want to block certain event kinds from certain relays. The runes rules do seem a little daunting, but it's only as complicated as a user wants to make it. Plus, it's only a matter of time before some dev figures out a UI paradigm that is intuitive for users.
I agree, but we must standardize these things once the need arises and solutions start to pop, not try to prevent what we will use and need while completely blind.
I think this is much better than NIP 23, especially since it recommends clients broadcast these events more aggressively than a user's regular notes. I also like @eskema's kind-0 idea, and it would make sense for clients to aggressively broadcast kind 0's for the same reason.
It does seem like the use case of saving which relays a user prefers to read from is still not yet solved. I wonder if a new kind for "account settings" would work well. It would work the same way as kind 0, which has become sort of an "account metadata" junk drawer, and which is mostly used by the clients of other users. In contrast, kind x would be the same kind of junk drawer but encrypted and meant for the use of the user's own clients, including things like relay read/write settings, private follows, blocks, etc.
It does seem like the use case of saving which relays a user prefers to read from is still not yet solved.
the relays a user choose to read from will then get fetched from the pubkeys he follows. we can then look at all our contacts on kind-3 and assign one relay from this relays list to our kind-3 contact relay field. we can make the decision which one to use with a system like @mikedilger relay model, so the client should know where to fetch data just by looking at it's own kind-3 if nothing else available.
It does seem like the use case of saving which relays a user prefers to read from is still not yet solved. I wonder if a new kind for "account settings" would work well. It would work the same way as kind 0, which has become sort of an "account metadata" junk drawer, and which is mostly used by the clients of other users. In contrast, kind
xwould be the same kind of junk drawer but encrypted and meant for the use of the user's own clients, including things like relay read/write settings, private follows, blocks, etc.
I'm 100% for this. The reason I picked up and ran with NIP-23 was to solve for the use-case of a relay that a user subscribes to for a very specific data stream, i.e. subscribing with your zip to get local weather on your feed (not an amazing use-case, but presents the problems to be solved). This would need a secure way of holding your zip where it's not visible to others but moves with the user from client to client. I was just going to provide the ability to encrypt everything in the kind 10001, but I think this would be much better.
Perhaps we can standardize the content of this schema in a new NIP. (Frankly, NIP-23 should have been two separate NIPs anyway, which is why I won't fight too hard for it).
we can then look at all our contacts on kind-3 and assign one relay from this relays list to our kind-3 contact relay field
That works, but I'm not completely satisfied with it. As special-purpose relays emerge, a user may want to follow a particular relay independent of any individual person who posts there.
As special-purpose relays emerge
I agree there, but I'd say that a special relay would also need special handling, so it would be handled however it needs to be handled anyway.. it's not like we're simply subscribing to everything in a relay, there's more into it than that so the relays could simply have a pubkey and you follow them like any other identity.. it's a total different case that we don't even know yet what it will be.. so it's not much possible to anticipate what that special handling might be..
if we're going this route, then IMO this array should maybe be better in kind-0 as
content.relays:[]. having what relays you post to is pretty integral part of identity, and it would reduce a lot of guessing and events back and fort since kind-0 is pretty much always needed... we already have a bunch of frivolous fields there, it's easily updateable and probably the most up to date everywhere. a simple list of relays there makes more sense to me in terms of practicality. if that doesn't make sense, and everyone prefers this model, then let's use this kind, but I think having the relay information readily available in kind:0 solves multiple problems at once.or add the
rtags to the kind-0 event tags directly
I totally agree with this point. As I was working out thinking about this, my first thought is why do we not have a relays array on kind-0. This would simplify client side handling so much. As of right now I think @jb55 is putting relays in the content of kind-0.
Im am 100% for adding a relays array to kind-0. This makes the most sense and Im surprised it wasn't there from the beginning. I should be able to get all I need about a pub key holder via kind-0.
Just my 2 cents.
Could use one parameterized replaceable event for each relay (the "d" tag would be the relay URL). Say kind 30001
Seems better for concurrent use by multiple clients. Each time any of my clients successfully establishes a websocket connection to a relay, the client publishes a parameterized replaceable event. This won't overwrite the other events (only the ones corresponding to the same relay). So for instance, I could request kind 30001 authored by "Mike Dilger" and filter by limit:5 to receive the 5 most recent relays successfully used by any of Mike Dilger's clients.
@mikedilger I love this idea, thanks for putting this nip together! and agree with everything @eskema has said here so far. and agree with @fiatjaf suggestion to use this rather than nip23.
I've been contemplating nostr relay strategy based on some of fiatjaf's recent comments. In my mind it seems like there are 2 basic strategies regarding users defining their relays. either users are a) encouraged to define which relays they want read from b) encouraged to define which relays they want to write to
option a is what has mostly been used so far, but over time it feels like it will slowly require more of option b to continue operating smoothly which can get messy. having a mix of the 2 options would also be messy. whereas option b would never need to mix in some of option a to work, which is why I like this model more (as long as relay advertisement is widely broadcasted). option b is also MUCH more scalable for relays and prevents unnecessary duplication of data across relays.
if we are going to lean towards option b, it seems unnecessary to require users to publicly define which relays they want to read from at all. optionally, if users did want the ability to do this, it would be really easy to add that, either as nip23 relay list (though nip23 supports/encourages option a as well which I think its unnecessary now) or as nip51 generic list (which could be public or private). however it might be more urgent to support reposting events other than your own to your paid relays via relay auth in order to ensure events can continue to be widely propagated when necessary.
I would also really prefer to have this info on the kind 0 record as @eskema had suggested. and then have your kind 0 record spread widely across the network. I also like the idea of adding relays in the kind 0 tags rather than in the content.
should there be some limit to the number of relays that can be listed should be suggested? and/or some verbiage to say relays are ordered by priority? this way if a client only wants to connect to one relay they know which is the most important and also discourages people listing their whole relay list here.
I guess we can all agree on using kind 0 then.
I like having relays as tags. I think it unlocks some nice features like being able to query who is in each relay, but I don't know if that is worth the trouble.
I also think there should be some recommended limits on the number of relays, and honestly relays should be blocking events with too many tags already, so there is that.
However, if Damus is not using the tags, but just using an array of strings inside the metadata body then we probably should do that. Would be nice to know what Damus is really doing.
I guess we can all agree on using kind 0 then.
I like having relays as tags. I think it unlocks some nice features like being able to query who is in each relay, but I don't know if that is worth the trouble.
I also think there should be some recommended limits on the number of relays, and honestly relays should be blocking events with too many tags already, so there is that.
However, if Damus is not using the tags, but just using an array of strings inside the metadata body then we probably should do that. Would be nice to know what Damus is really doing.
Im fine with it being in tags as long as it lives on kind-0. :)
I only found one profile with "relay" in metadata, however this kind 0 is really nonstandard, has a content key within the content field. note1q7w36puvtxukgflu2kvugyral4tvk938lj9mmq7djvxugftazdlq2sf65g
@ismyhc are you sure Damus is adding relay in kind 0 content? I would have expected to find many of these events if so
I only found one profile with "relay" in metadata, however this kind 0 is really nonstandard, has a content key within the content field. note1q7w36puvtxukgflu2kvugyral4tvk938lj9mmq7djvxugftazdlq2sf65g
@ismyhc are you sure Damus is adding relay in kind 0 content? I would have expected to find many of these events if so
Oh shoot. I just found my conversation with @jb55 and he puts them in kind3. In the content I believe. My bad!
I still believe that relays should be on kind-0, somewhere.
could we maybe put 'relay' in the name and remove 'feed'? like 'relay advertisement' or 'relay advice'?
I just found my conversation with @jb55 and he puts them in kind3
That's what most clients are doing, it's a crappy legacy from branle.
In this case I think we should go with "r" tags on kind 0. What are the arguments against that? Tags are also good because we can add more stuff to them after the first two elements if necessary.
Main downside would be from @barkyq
Could use one parameterized replaceable event for each relay (the "d" tag would be the relay URL). Say kind 30001
Seems better for concurrent use by multiple clients.
I agree with this, but I'm not sure how important concurrent use is. It has been demonstrated to be a problem thus far however, and the more we pack into a single kind the more severe it will be.
I just found my conversation with @jb55 and he puts them in kind3
That's what most clients are doing, it's a crappy legacy from branle.
In this case I think we should go with
"r"tags on kind 0. What are the arguments against that? Tags are also good because we can add more stuff to them after the first two elements if necessary.
%100 in agreement
Just woke up and read all your comments. I'm glad the need for this is understood.
I think nip23 still has a useful purpose for controlling your own clients as you move between them.
I'm fine with using kind-0. I prefer using the "r" tags for the reason that metadata currently is all strings, not lists of strings, so this won't add any new complexity for anyone. It doesn't hurt to be queryable but I'm not sure why they would be queried. If anyone has a good argument for a different non-queryable tag I'm listening.
What do people think about changing the name to "Relay Advertisement" or something other than "Feed Advertisement" as suggested by @monlovesmango ? Since it's not a new type, I could retitle the NIP to "Relays in Metadata" or something.
Should we add a priority to the relay tags or other markers?
Can someone suggest a recommended limit?
I think nip23 still has a useful purpose for controlling your own clients as you move between them.
agreed, but the need for a simple system is urgent, so let's do this :)
I'm fine with using kind-0. I prefer using the "r" tags for the reason that metadata currently is all strings, not lists of strings, so this won't add any new complexity for anyone. It doesn't hurt to be queryable but I'm not sure why they would be queried. If anyone has a good argument for a different non-queryable tag I'm listening.
queryable is good I think, the only doubt I had was about the letter, since we already have it in some fringe use as a url reference (I guess a relay would still qualify as a url), even though I think maybe a dedicated relay tag that is not some other type of url may be handy for all types of things, so we either reserve r for relays or another one, but r kind of makes sense for relays, so maybe we can come up with another for the url ones, it's not much used anyway..
What do people think about changing the name to "Relay Advertisement" or something other than "Feed Advertisement" as suggested by @monlovesmango ? Since it's not a new type, I could retitle the NIP to "Relays in Metadata" or something.
Relays in metadata makes sense, but if we go for tags, is it really in the metadata since the metadata is supposedly only in content? this may be an irrelevant point that won't matter much and doesn't warran't loosing time discussing it, choose whatever you find appropriate.
Should we add a priority to the relay tags or other markers?
I think we should be treating those as all equal, it's a list because it gives some choice for the client to optimize, we could use the order but we already saw the need for proper markers with root and reply, maybe be can leave this open and let clients experiment a bit and maybe settle later on a specific approach that is tested
Can someone suggest a recommended limit?
this will be a tough consensus, let's say less than 10? my sweet number would be between 3 and 6
queryable is good I think, the only doubt I had was about the letter, since we already have it in some fringe use as a url reference (I guess a relay would still qualify as a url), even though I think maybe a dedicated relay tag that is not some other type of url may be handy for all types of things, so we either reserve
rfor relays or another one, butrkind of makes sense for relays, so maybe we can come up with another for theurlones, it's not much used anyway..
I went looking for "what is a tag that means Url?" and stumbled across 'r'.
Can someone suggest a recommended limit?
this will be a tough consensus, let's say less than 10? my sweet number would be between 3 and 6
Does the recommendation mean users probably shouldn't write to more than that many? Or that relays should reject kind-0 with more than that many? Might need two numbers.
Does the recommendation mean users probably shouldn't write to more than that many? Or that relays should reject kind-0 with more than that many? Might need two numbers.
I'm not sure it makes sense to explicitly limit, it's just a list to where the user at least writes to, we can still have other means to write to other relays not on this list, but at least it is expected that the user posts to these, so the number should only be a recommendation.
I hesitate to push this argument because everybody came down on the other side of it and I don't want to derail this. But I think this is better as a new event kind outside of metadata for the following reasons: (1) the event is much smaller. If you spread it widely it has less impact as such, and (2) there is no content that would need moderation, so relays that require subscriptions might allow these without a subscription (metadata may need moderation). AFAIUnderstand it, the benefits of being in metadata are that you encourage people to spread their metadata widely (not sure if that's important) to avoid a new event kind (not sure I follow) to group together similar data (I don't see the practical benefit, just a conceptual one).
I hesitate to push this argument because everybody came down on the other side of it and I don't want to derail this. But I think this is better as a new event kind outside of metadata for the following reasons: (1) the event is much smaller. If you spread it widely it has less impact as such, and (2) there is no content that would need moderation, so relays that require subscriptions might allow these without a subscription (metadata may need moderation). AFAIUnderstand it, the benefits of being in metadata are that you encourage people to spread their metadata widely (not sure if that's important) to avoid a new event kind (not sure I follow) to group together similar data (I don't see the practical benefit, just a conceptual one).
Good points. I'm switching my allegiance to this.