nips
nips copied to clipboard
nostr-protocol
NIP35: Relay-Specific Notes
This is a very early/experimental idea on relay-specific notes. Initial feedback welcome!
What happens if I am connected to relay.jb55.com, receive a note intended only for this relay, and I reply broadcast the parent note to all my other relays, most of which do not recognize this NIP/spec?
I had this exact same idea a few months back. I'm still not sure if it's good or not. Possible downsides:
- If a relay goes away, all its content dies with it
- Proxies can't function as simply
- This can be easily be bypassed by just not validating the url (this point conflicts with my first one. One possible way to fix it would be to make
toimplicit, so you'd have to know what relay the note came from in order to validate the signature, or you could brute force the sig against all known relays)
What happens if I am connected to relay.jb55.com, receive a note intended only for this relay, and I reply broadcast the parent note to all my other relays, most of which do not recognize this NIP/spec?
The relays will reject it because the signature will be invalid.
I had this exact same idea a few months back. I'm still not sure if it's good or not. Possible downsides:
- If a relay goes away, all its content dies with it
seems like a feature to me!
- Proxies can't function as simply
true, haven't thought of a good solution for this yet but maybe its not too big of a deal. this is why I put a "SHOULD" in the client validation wording...
- This can be easily be bypassed by just not validating the url (this point conflicts with my first one. One possible way to fix it would be to make
toimplicit, so you'd have to know what relay the note came from in order to validate the signature, or you could brute force the sig against all known relays)
this is where both client and server validation is important, both client and server would have to not do validation to propagate the note outside the intended location.
As users can not trust clients or relays to not (re-)propagate their events to relays that doesn't support this NIP, I wonder what would be the real use cases of this?
As users can not trust clients or relays to not (re-)propagate their events to relays that doesn't support this NIP, I wonder what would be the real use cases of this?
What do you mean? These are not valid nostr events to current relays. They are not propagatable.
As users can not trust clients or relays to not (re-)propagate their events to relays that doesn't support this NIP, I wonder what would be the real use cases of this?
What do you mean? These are not valid nostr events to current relays. They are not propagatable.
That's a good point but it doesn't prevent "rogue" relays to keep the events anyway (received from candid clients). So I was interested on what would be the use cases (as the privacy can't be one)
I got a lot of flack for suggesting something similar on #1029, but I do think the change in the serialization algorithm is the answer for relay-controlled events.
I just don't know if it is a good idea to give that much power to relays.
For the specifics of this proposal, changing the serialization to block events from reaching current relays will only work until StrFry includes the to field in their serialization without checking the current domain name of the relay. Then more relays will accept everything.
For the specifics of this proposal, changing the serialization to block events from reaching current relays will only work until StrFry includes the to field in their serialization without checking the current domain name of the relay. Then more relays will accept everything.
As @jb55 points out though, that would be non-standard behavior, and well-behaved clients would consider these invalid events. So it requires collusion between clients and relays to bypass this. In the aggregate, this will I think allow for pretty robust relay de-commodification.
Maybe the biggest problem is that the correct relay has to be selected by the client signing the event, which might not align with the events the recipient relays actually want to store.
The relays will reject it because the signature will be invalid.
Do all relays check signatures today?
As @jb55 points out though, that would be non-standard behavior, and well-behaved clients would consider these invalid events. So it requires collusion between clients and relays to bypass this. In the aggregate, this will I think allow for pretty robust relay de-commodification.
I don't know... I don't trust people to run well-behaved anything these days... Especially when protected data (and thus more valuable data) is involved.
But I am not against it if somebody wants to push this forward.
The relays will reject it because the signature will be invalid.
Do all relays check signatures today?
yes
The relays will reject it because the signature will be invalid.
Do all relays check signatures today?
yes
Given this, does a single adversarial relay, or relay + client combo undo this NIP's stated benefit?
Given this, does a single adversarial relay, or relay + client combo undo this NIP's stated benefit?
No, because it will still work for anyone who cares enough to run a compliant relay or client.
Given this, does a single adversarial relay, or relay + client combo undo this NIP's stated benefit?
No, because it will still work for anyone who cares enough to run a compliant relay or client.
Sorry for the left curve questions. Last one: if your company had "trade secrets" would you be confident in using this approach - i.e. only post these to this relay only?
Given this, does a single adversarial relay, or relay + client combo undo this NIP's stated benefit?
No, because it will still work for anyone who cares enough to run a compliant relay or client.
Sorry for the left curve questions. Last one: if your company had "trade secrets" would you be confident in using this approach - i.e. only post these to this relay only?
You still would want AUTH or vpn/ip blocking as well, this doesn't prevent leaking anything. Screenshots can always do this. What this does stop is making notes trivially propagatable via "broadcast" and "repost" features in clients. The ease of propagatability is a huge downside that makes private use cases not feasible on nostr.
In the repost case, you cannot repost relay-specific notes, because the inner signature doesn't validate. Same as broadcast.
Another example: it's not easy to make someone's comment appear in many different discord servers. In their case it's not a problem to enforce this because it's centralized, but it would be nice to have a similar mechanism in a decentralized network.
Initially I thought of just adding a "to" tag, but everyone would ignore it so that's a dead end. This is a similar problem with @fiatjaf 's - proposal.
One problem with this is that I can't change my mind and publish my events to other relays after creation, everything is set in stone.
I can't migrate my events from one relay to another or other basic things. Depending on the situation this might lead to people copying events and resigning them with different ids, breaking references and all that.
The ["-"] approach solves that by given the event creator agency over where the event can go at any point in time. I also think it's saner in the long run, as it would take just a few lines of code to hardcode it in the 3 or 4 relay implementations that exist (which after some time will make their way into currently deployed relays).
Here's the implementation on Khatru: https://github.com/fiatjaf/khatru/commit/cd4c25c84519a4965fdb48f462111373d38a5eb8 (this implementation already includes the AUTH stuff, a simpler implementation would be to just block events with the ["-"] tag, which would be really 3 or 4 lines).
Meanwhile this proposal requires cumbersome changes in all of the dozens of Nostr libraries in existence so they can understand the new signature algorithm.
Now I'm thinking of a way to bootstrap the ["-"] mechanism such that it will only work today on relays that voluntarily decide to implement it: clients can just send the event with some invalid part in it, like a single extra letter appended to the "sig" field. And compliant relays will remember to check that and remove that extra letter when the received event has a ["-"] tag. Relays can just append that extra letter when sending these events to clients too, so only compliant clients will understand these.
Eventually as relays catch on with the implementation we can remove this hack and start sending normal signatures everywhere.
Now I'm thinking of a way to bootstrap the
["-"]mechanism such that it will only work today on relays that voluntarily decide to implement it: clients can just send the event with some invalid part in it, like a single extra letter appended to the"sig"field. And compliant relays will remember to check that and remove that extra letter when the received event has a["-"]tag. Relays can just append that extra letter when sending these events to clients too, so only compliant clients will understand these.Eventually as relays catch on with the implementation we can remove this hack and start sending normal signatures everywhere.
this sound like versioning the protocol in a terrible way
this sound like versioning the protocol in a terrible way
I agree, I very much prefer that relays just implement handling the ["-"] properly.
like a single extra letter appended to the
"sig"field. And compliant relays will remember to check that and remove that extra letter when the received event has a["-"]tag. Relays can just append that extra letter when sending these events to clients too, so only compliant clients will understand these.
This was my initial idea when I started thinking about this, but I then realized it would be trivial for people to strip that a re-propagate it.
I can't migrate my events from one relay to another or other basic things. Depending on the situation this might lead to people copying events and resigning them with different ids, breaking references and all that.
yes this is either crappy or really good depending on how much you want these notes to be propagated.
Maybe if the relays had associated pubkeys instead it would alleviate these issues?
I didn't see the - spec until now. I think it's fine and is much simpler. although not sure how long it will take for all relays to implement. strfry still doesn't have AUTH support :(
This spec doesn't need all relays to update so it works out of the gate which is nice.
I like this spec more and more. The only downside in my mind was illustrated in this comment from @fiatjaf:
One problem with this is that I can't change my mind and publish my events to other relays after creation, everything is set in stone.
I can't migrate my events from one relay to another or other basic things. Depending on the situation this might lead to people copying events and resigning them with different ids, breaking references and all that.
However, I just had a thought that perhaps this is not an issue, but actually a strength, a feature. It is technically possible to migrate things to a different set of relays by recreating events and references "en masse" — it only requires either one of two things:
- Cooperation from everyone involved (to make the new signatures)
- Intentional programming on particular clients and relay configurations to accept address discrepancies, some internal "knowledge" of said data migration
If there is general consensus among a controlled group (e.g. a company), these methods above are not very difficult — provided enough tooling to do this.
Therefore, this kind of friction may sound bad, but could actually be a strength that protects private data, by requiring a degree of consensus before moving data somewhere that could be considered less private by members of such a group of people.
Example: If I post something meant to go to "privatecompanyrelay.com", but someone wants to move it to "lessprivaterelay.com", it is harder to do so without my consent. If they have my consent, I can approve the migration by signing the updated event
cc @jb55
In the context of a company, rarely are these operated by consensus. Usually there is one or a few decision maker.
In the context of a e.g. community such as the ones @staab is building for, perhaps there is more of a need for consensus. Maybe I'm wrong as communities have leaders as well.
In the context of a company, rarely are these operated by consensus. Usually there is one or a few decision maker.
True, so in practice the decision maker of a company would ask team members to re-sign their events to include the new relay(s), and those team members would most likely just comply.
Worst case scenario (e.g. if a private key is lost and re-signing is not an option), the company's relays/clients could be programmed to accept the old pre-migration notes (i.e. explicit exceptions to the rules in this NIP)
In the context of a e.g. community such as the ones @staab is building for, perhaps there is more of a need for consensus. Maybe I'm wrong as communities have leaders as well.
In the context of a community, a lack of migration consensus means that propagating data from the non-consenting author would become a bit more difficult, which is also a plus, as the author may not want their notes to be on the new location.
Overall, data migration is still possible under this NIP, it just requires a bit of a process/formality, which I consider to be a good thing in the context of handling private data and avoiding leaks.
The most difficult part of this approach is to make sure privacy expectations are correctly set among participants: users/company/community, meaning:
- These are not private events by any means. Anyone can read them when they leak.
- They can be verified as authentic when leaked.
- Somebody can put up a relay that simply copies all these events to a new relay for public consumption in real time. That new relay would simply ignore the rule to verify if it is one of the
todomains in the URL. It's very easy to imagine a NostrLeaks relay that disregards thetorule and captures all of the corporate notes it can.
I run 3 private relays for companies. Two use normal relays but one of them runs #1029 (validates per user, instead of per relay), which has similar privacy framework as the proposal here. It was not fun when they discovered that events could leak and be verifiable. Most companies can deal with a "screenshot" leaking, but if a signed package leaks, things get to a whole new level of problems. So, managing expectations is important.
In my experience, user-initiated migration is not likely to happen within companies because they own your communications when inside of it. But company-initiated migrations will likely happen (e.g. when changing the relay's DNS name, branding changes, etc). And when it happens, the company won't ask past employees to re-sign payloads. The new relay code will have an exception to accept the old and the new DNS domain as valid. So, I do expect to exceptions to become the norm in the long run.
The most difficult part of this approach is to make sure privacy expectations are correctly set among participants: users/company/community, meaning:
- These are not private events by any means. Anyone can read them when they leak.
If they leak, anyone can read them, yes. But the same is true about leaked emails or any kind of private communications. Emails and other private platforms prevent unauthorized access and accidental leaks, but they cannot prevent an internal malicious actor from intentionally leaking private info.
The good thing about this NIP is that it prevents accidental leaks by:
- Not being compatible with existing clients/servers that do not know or care about this NIP.
- Forcing clients and servers to implement logic that explicitly handles these private data rules — if they want to be compatible with this NIP
- Somebody can put up a relay that simply copies all these events to a new relay for public consumption in real time. That new relay would simply ignore the rule to verify if it is one of the
todomains in the URL. It's very easy to imagine a NostrLeaks relay that disregards thetorule and captures all of the corporate notes it can.
In this scenario, are you assuming this to be an outsider attack (e.g. An outsider waiting for accidental leakages) or an insider attack (e.g. A malicious person with access to a private group)?
I run 3 private relays for companies. Two use normal relays but one of them runs #1029 (validates per user, instead of per relay), which has similar privacy framework as the proposal here. It was not fun when they discovered that events could leak and be verifiable. Most companies can deal with a "screenshot" leaking, but if a signed package leaks, things get to a whole new level of problems. So, managing expectations is important.
Interesting. I don't quite understand what difference it makes in practice, can you please provide some examples of how digitally signed communications leaking becomes a much bigger problem than normal data leaking?
In my experience, user-initiated migration is not likely to happen within companies because they own your communications when inside of it. But company-initiated migrations will likely happen (e.g. when changing the relay's DNS name, branding changes, etc). And when it happens, the company won't ask past employees to re-sign payloads. The new relay code will have an exception to accept the old and the new DNS domain as valid. So, I do expect
toexceptions to become the norm in the long run.
Fair point, perhaps that will be the standard strategy people will adopt under this NIP
On Wed, Apr 17, 2024 at 10:29:57AM -0700, Daniel D’Aquino wrote:
I run 3 private relays for companies. Two use normal relays but one of them runs #1029 (validates per user, instead of per relay), which has similar privacy framework as the proposal here. It was not fun when they discovered that events could leak and be verifiable. Most companies can deal with a "screenshot" leaking, but if a signed package leaks, things get to a whole new level of problems. So, managing expectations is important.
Interesting. I don't quite understand what difference it makes in practice, can you please provide some examples of how digitally signed communications leaking becomes a much bigger problem than normal data leaking?
This started making me think of strategies of tweaking signatures with private information so that even if the note was leaked it would not be possible to verify the signature without this tweaked key. I am not a cryptographer so I'm not sure how you would do this, but deniability would be a really cool feature.