Creates "Anyone with link" access controls for NIP-19

[vitorpamplona]

Adds a secret and a nonce to NIP-19 uris such that only people with access to the URI can decrypt its content.

Current use case

Problem: Sending a private picture in NIP-04 DMs.

Solution:

1. Encrypt the picture with aes-256-gcm and send the encrypted file to an image server.
2. Create a NIP-94 record pointing to the url WITHOUT adding the decryption keys to the event-1063's tags.
3. Create a NIP-19 URI with the secret and nonce used.
4. Send that URI in a NIP-04 DM.

On the other side:

5. Parse the NIP-19 uri
6. Download the associated NIP-94 event
7. Download the encrypted image from URL
8. Use the secret to decrypt the contents of the file
9. Display on screen.

Generalized case

Any event that supports encryption with independent secrets can use the scheme.

[vitorpamplona]

@frbitten check this one out.

[fiatjaf]

Looks good to me.

[frbitten]

I haven't looked into this private messaging mechanic much to be sure. Looks good to me.

Better not suggest a private event based on NIP-95 where the base64 data is encrypted, right? I think it will create a lot of discord. 😄😄

[jb55]

Just throwing this out there as an alternative that doesn't further fracture nostr between nip94-style file sharing clients and non-nip94 style filesharing clients. It won't break any of your clients so feel free to ignore this, but it's something I am looking at for damus.

Problem: Sending a private picture in NIP-04 DMs.

On nostr I suggested an alternative to this that doesn't require nip19 or nip94:

https://filehost.com/abcdef.png.enc#nipx-key=abcdef

Clicking this link would show a NIPX client that views encrypted media or files, very much like encrypted pastebins:

https://0bin.net/paste/eoPhnh8H#35dRmti8Dzc4AKs4NNTsEs19R2O62HSj9HB9tmFaPOn

The benefit of this is that it provides a fallback link and an upgrade path for clients who are not planning on implementing nip94 filesharing functionality, and would still allow these client to upload images using a NIPX encrypted upload provider.

The biggest benefit of this is that it doesn't leak any nip94 metadata on the network. Why let people now you're sharing files to begin with?

NIPX would just specify the # params so that when the client sees a link with a #nipx-key, it will know to download the link with an Accept: application/octet-stream header to pull the data and decrypt the image with nipx-key. The response should have the mime information to know what kind of file it is: image, pdf, etc. the # querystring can include a sha2 hash if verification is required.

[arthurfranca]

I ressurected NIP-54 PR using uri fragment.

It can be used along with a NIP-21 url that points to a NIP-94 event+relay like nostr:nevent1qq...pm#aes-256-gcm=i-am-a-key&aes-256-gcm=i-am-an-iv that is sent as NIP-04 DM's encrypted content.

edit: the bad thing of the secret/nonce TLV types is that it is not really clear what is encrypted. In this case (NIP-94 event) is the content of the image downloaded from the url value of the url event tag.

[vitorpamplona]

I am not sure if I like this idea: nostr:nevent1qq...pm#aes-256-gcm=i-am-a-key&aes-256-gcm=i-am-an-iv

We either use TLV or don't... having a mix of TLV and query string options feels really weird. Part of it has to be percent-encoded, part of it doesn't.

the bad thing of the secret/nonce TLV types is that it is not really clear what is encrypted. In this case (NIP-94 event) is the content of the image downloaded from the url value of the url event tag.

In my mind, the event type defines it. In NIP-94 it is the external file. In NIP-95 it's the associated event with base64 data. In an extended NIP-23 or NIP-51, it could be part of the content.

[arthurfranca]

We either use TLV or don't... having a mix of TLV and query string options feels really weird. Part of it has to be percent-encoded, part of it doesn't

I suggested NIP-54 cause it can be used with not just http urls but with any, like nostr-specific urls.

In my mind, the event type defines it. In NIP-94 it is the external file. In NIP-95 it's the associated event with base64 data. In an extended NIP-23 or NIP-51, it could be part of the content.

Yes you are right I will strike out that part.

[arthurfranca]

We either use TLV or don't... having a mix of TLV and query string options feels really weird. Part of it has to be percent-encoded, part of it doesn't.

Maybe another down side of TLV is that each new field needs to be added to NIP-19 spec, which may demand parsing libs to be updated. While NIP-54 allows for NIP-94 and all w3c or proprietary fragments fields and, as such, fragment parsing libs shouldn't assume a fixed set of fields.

[vitorpamplona]

Closing this because:

1. User research pointed us to the expectation that "anyone with link" is not a good security model for DMs. It content should be encrypted to the receiver only.
2. Stale: it doesn't look like anyone else needs this for now.