nips
nips copied to clipboard
nostr-protocol
relay-based event access-control with the `["-"]` tag
Read about it in the NIP body: https://github.com/nostr-protocol/nips/blob/protected-events-tag/70.md
This is inspired by https://github.com/nostr-protocol/nips/pull/1029, there is more discussion there.
So, relays and clients that don't yet support this tag will receive and rebroadcast the event everywhere as usual.
And the relays that do support it, will have to find a way to know what protected means (how to define: "published willingly" by its author) in each event.
verify that the authenticated public key matches the event author public key.
Doesn't that mean that, in a group, a user would only be able to download their own messages?
So, relays and clients that don't yet support this tag will receive and rebroadcast the event everywhere as usual.
Yes, but this NIP only works if it gets mass adoption by relays, which I think is not a large ask once most people are convinced of its usefulness.
Doesn't that mean that, in a group, a user would only be able to download their own messages?
No. This would fit other schemes, like https://github.com/nostr-protocol/nips/pull/566, and reuse the authorization scheme already described in those.
It could also be relied upon by an encrypted DM or group chat scheme that would rely on relays not leaking metadata to anyone.
Also remember that in most cases, specially if a group is small enough, there will be no incentive for receivers of these protected events to go around searching for a rogue relay to which publish the data against the will of the original author.
And also most normal users wouldn't also download a special client that knows what are these rogue relays and uses them specifically to download the events leaked from groups that would otherwise be private. A normal NIP-29 client, for example, would never even try to download events from groups to which it doesn't belong.
Exceptions are not the rule.
this NIP only works if it gets mass adoption by relays like https://github.com/nostr-protocol/nips/pull/566, and reuse the authorization scheme already described in those
Those two things are mutually exclusive.
The protected tag doesn't reference which authorization scheme the relay should use. If we have separate implementations of https://github.com/nostr-protocol/nips/pull/566, how would the relay know which one to apply?
Clients can use this tag to not automatically re-broadcast the event and require choosing relays when the user tries to re-broadcast. However users might not know where the event should go to make the choice themselves.
It feels very abstract/general. Which is unlike you @fiatjaf
Handy NIP to make an event be hosted just on relays that support NIPs/behavior the author needs. Though feels not that useful without an event access control spec for relays.
love this. very simple but powerful (but as with all nostr policy, only as powerful as its adoption). honestly surprised me that this hasn't already been done.
I kinda think this should just be added to the NIP42 generally, right? if so, my next question is what use case are you envisioning where we would have authenticated writes but not authenticated reads (which would need this separate NIP)? if not, what use case would have authenticated reads but not benefit from authenticated writes?
NIP-29 groups, both private and public, would benefit from authenticated writes. DMs would benefit from authenticated reads and writes. Just kind1 notes would benefit from authenticated writes/unauthenticated reads when the user wants to have some control of what they have posted and a little more assurance that deleting notes would be possible, for example.
@vitorpamplona the reason I think it's ok to be generic here is that I just expect all relays to implement this with a two-line check: if protected tag is present reject by default so that requires it being generic -- but I agree that being generic is often bad and that this is very unlike me. Maybe I'm wrong here though.
What do you think of using a tag like ["-"] instead of ["protected"] for brevity?
But this requires changing the code: if protected tag is present reject
Most relays will not even realize that this PR is a thing. The default relay behavior of folks who do NOT implement this PR is to accept, not to reject. That's why I proposed changing the serialization: to reject by default on current relays and make it backward compatible (relays don't need to change) and they shouldn't be working with "protected" events without implementing this or the other PR.
Same for all clients: The default behavior for those not implementing this PR is to accept the protected event as a regular event and re-broadcast at will.
That's why I proposed changing the serialization: to reject by default on current relays and make it backward compatible (relays don't need to change) and they shouldn't be working with "protected" events without implementing this or the other PR.
but there's nothing stopping a relay from updating its serialization (which is easy if they are using a nostr library that keeps up with nips) without actually implementing the auth in the PR. so still doesn't accomplish the goal of forcing non-supporting relays to protect these events.
so still doesn't accomplish the goal of forcing
Nothing will ever force relays to auth correctly. That's not the point. If relays want to fuck around they can do it in a lot of ways.
The only point of the serialization change is to make sure only clients and relays that have seen NIP-42 and are minimally aware of the difference between public and protected events can receive and rebroadcast these events.
Otherwise, if protected events are just being treated like public events by a majority of clients and relays, nothing in this PR makes any sense.
The only point of the serialization change is to make sure only clients and relays that have seen NIP-42 and are minimally aware of the difference between public and protected events can receive and rebroadcast these events.
yes agree. my point is you can update your nostr library dependency (which has accounted for new serialization) without being explicitly aware of the difference between public and protected events. most aren't writing their serialization code themselves (I think).
Agree. My hope was that libraries requested an extra param (isAuthed: Boolean = false) to the serialization function which fails if the relay is not aware of NIP-42
But this requires changing the code: if protected tag is present reject
I know. This is obvious and is my base assumption!
I don't know why every time I mention this proposal to someone they have to point this out, but I guess I'll rewrite this proposal to make this more explicit.
Most relays will not even realize that this PR is a thing. The default relay behavior of folks who do NOT implement this PR is to accept, not to reject. That's why I proposed changing the serialization: to reject by default on current relays and make it backward compatible (relays don't need to change) and they shouldn't be working with "protected" events without implementing this or the other PR.
I'm not sure about that. There are like 3 or 4 big relay implementations. If they implement this, which they can very easily, we give the network a couple of months and suddenly this change is in effect mostly everywhere. I think it's worth trying. If it fails then it fails, we don't lose anything.
Changing the serialization would achieve the same result at the end, but at a much bigger cost. It would make writing basic Nostr event creation libraries and using these libraries much more cumbersome for everybody forever.
There are like 3 or 4 big relay implementations. If they implement this...
I think that is the main difference between our experiences. I don't expect the current public relay codebases to be the same as the relay code that will work with the protected events. In fact, I don't want to change the public relay's code at all.
Changing the serialization would achieve the same result at the end
The difference is subtle but it's real. In this approach, there will be public relays, protected relays, and the ad-hoc relays that don't know the difference between the two because they have not read this PR yet. Those ad-hoc relays will re-broadcast everything protected.
Same for clients. There will be clients that deal with the public events, clients that can deal with the protected events and those who don't know about this and will just scatter protected events everywhere.
The proposal to change the serialization minimizes the existence of 3rd set of both relays and clients, better protecting events that should be protected.
The proposal to change the serialization minimizes the existence of 3rd set of both relays and clients, better protecting events that should be protected.
agree this is the case. I think where we disagree is whether the better protection is enough to warrant such a drastic change to protocol fundamentals. IMO its not bc the network is always going to be vulnerable to malicious relays that don't follow the rules anyway, and this is the subset I am more concerned about. non-malicious actors that are ignorant of this NIP and accidentally spread protected events will diminish over time. I'd rather wait for that slow process to work itself out than force it with changes in serialization.
I wanna see pull requests adding the protected tag spec to 10 relay implementations then we have a deal @_@ hahah
whether the better protection is enough to warrant such a drastic change to protocol fundamentals.
Don't get me wrong. I think the idea of changing the serialization is crazy as well (as I wrote in the PR itself). I don't think it is a change in fundamentals. To me, it is the start of a second Nostr relay network that is designed for private events (medical information in my case) while not forcing users to centralize in the hospital's or country's private relay. The public network shouldn't change to stay as simple as possible.
I would love to find a way to add to the serialization process a step where the relay has to prove one of the pubkeys was authenticated and in order to verify the event. In Clients, the client must prove it has access to the private key of one of the pubkeys listed in the event. That would be a dream. I would allow the event to be verified only on relays that are being used by the listed keys and those listed keys could move the event to any relay or client they want. But that is very far out.
I wanna see pull requests adding the protected tag spec to 10 relay implementations then we have a deal @_@ hahah
Working on that.
Implemented here -- with the necessary AUTH support already: https://github.com/fiatjaf/khatru/commit/cd4c25c84519a4965fdb48f462111373d38a5eb8
how about "Publication Protected Events"? or "Publish Protected Events"?
Whatever is fine for me, but I would prefer a smaller but meaningful name. A single word.
Simple enough and should be useful if relays adopt it. We will add this tag for subscriber-only events on creatr.nostr.wine.
+1. Simple enough to get implemented everywhere quickly.
Implemented in chorus here: https://github.com/mikedilger/chorus/commit/1e2187b86c7a4cd8b33672cf7cf6f777f0baf526
This is by far the simplest solution to the problem, anyone who disagrees is probably a statist.
This is live on the damus relay! I will also make a nip70 strfry plugin for https://github.com/damus-io/noteguard
