NIP-55: Proxied NIP-05 Authetication

This commit is contained in:
benthecarman 2023-02-27 19:46:45 -06:00
parent b549a9809f
commit 35082b6dbe
No known key found for this signature in database
GPG Key ID: D7CC770B81FD22A8
2 changed files with 47 additions and 6 deletions

38
55.md Normal file
View File

@ -0,0 +1,38 @@
NIP-55
======
Proxied NIP-05 Authetication
-----------------------------------
`draft` `optional` `author:benthecarman`
This NIP defines a way for clients to ask a relay to fetch the JSON document for a given NIP-05 address on their behalf.
## Motivation
A bad actor could be logging IP addresses and doing all of kinds of analytics on users that are making requests to a NIP-05 address in order
to verify the user. This could be proxied through a trusted relay to help protect the user.
The `NIP-05` parameter is used so the `PROXY` message can be later extended for other proxied requests in the future (ie image downloading).
## Definitions
This NIP defines a new message, `PROXY`, which clients can send to ask a relay to proxy a request through
```
["PROXY", "NIP-05", <NIP-05 address>]
```
And, when sent by relays, of the following form:
```
["PROXY", "NIP-05", <NIP-05 address>, <JSON returned from NIP-05 address>]
```
## Expected Behavior
If clients are worried about a relay lying to them, they can send the same `PROXY` request to multiple relays, if any of them give a different result,
they can assume that relay may be malicious.
Relays would be expected to fetch the JSON on behalf of the user, in order to prevent potential DoS attacks the relays could cache these requests to
save on bandwidth.

View File

@ -32,6 +32,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
- [NIP-42: Authentication of clients to relays](42.md)
- [NIP-46: Nostr Connect](46.md)
- [NIP-50: Keywords filter](50.md)
- [NIP-55: Proxied NIP-05 Authetication](55.md)
- [NIP-56: Reporting](56.md)
- [NIP-57: Lightning Zaps](57.md)
- [NIP-58: Badges](58.md)
@ -71,12 +72,13 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
## Message types
### Client to Relay
| type | description | NIP |
|-------|-----------------------------------------------------|-------------|
| EVENT | used to publish events | [1](01.md) |
| REQ | used to request events and subscribe to new updates | [1](01.md) |
| CLOSE | used to stop previous subscriptions | [1](01.md) |
| AUTH | used to send authentication events | [42](42.md) |
| type | description | NIP |
|--------|-----------------------------------------------------|-------------|
| EVENT | used to publish events | [1](01.md) |
| REQ | used to request events and subscribe to new updates | [1](01.md) |
| CLOSE | used to stop previous subscriptions | [1](01.md) |
| AUTH | used to send authentication events | [42](42.md) |
| PROXY | used to proxy requests through relays | [55](55.md) |
### Relay to Client
| type | description | NIP |
@ -86,6 +88,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
| EOSE | used to notify clients all stored events have been sent | [15](15.md) |
| OK | used to notify clients if an EVENT was successful | [20](20.md) |
| AUTH | used to send authentication challenges | [42](42.md) |
| PROXY | used to proxy requests through relays | [55](55.md) |
Please update these lists when proposing NIPs introducing new event kinds.