Nostr Web Client

Here's the first proposal to send private pictures in NIP-04 DMs from the discussion with nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 this morning

The idea is to add credentials to NIP-19 URIs (the nostr:nevent.. links) and create an "Anyone with Link" can see scheme. Since DMs are encrypted, only the two people in the conversation will get access to the image. Not even image hosts can see it.

Pros:

1. Simple change to a NIP

2. Straightforward implementation

Cons:

1. If the link is copied and pasted outside of a conversation, whoever has access to that link will see the contents of the image/file.

2. Once the secret is out, it's out.

3. URIs with secrets are bigger.

I believe the Cons can be minimized with appropriate UIs. Thus, I think this is a good proposal.

https://github.com/nostr-protocol/nips/pull/519

Reply to this note

Please Login to reply.

Discussion

Kieran 2y ago

I guess it wouldn't strictly be necessary to link to nip94 of nip19 could reference a url

🥩ℝ𝕖𝕟𝕖𝕘𝕒𝕕𝕖 ₿𝕦𝕥𝕔𝕙𝕖𝕣⚡ 2y ago

Sharing the link could compromise a phot, as could right-click save or a screenshot.

Nothing is ever truly secure on the internet if someone else can see it.

nostr.build 2y ago

I don’t understand the con, if the link is copied and pasted outside of the conversation, it can be seen? This defeats the whole purpose, right? So anyone can just grab the link and paste, and can see it?

Kieran 2y ago

They can share the entire nip19 link with they key then they can see it, if they only have the url to the file they won't be able to decrypt it

nostr.build 2y ago

Got it, so they would still need the key

jb55 2y ago

Why not just .enc#key=base64uri-decryption-key&mime=png&hash=abcde…

jb55 2y ago

Whats cool about this is that when you click it in a nostr client that doesn’t support encrypted images in dms, it could open on filehost.com and decrypt it clientside for display

jb55 2y ago

I think the only additional thing needed to make this work is Accept: application/octet-stream in the header for the raw download, otherwise the link opens in a viewer client when you click it.

Vitor Pamplona 2y ago

I wouldn't put the secret in the URL. Otherwise, the image host also has access to the secret and thus the image.

Kieran 2y ago

This is a little less descriptive than a nip19 link which says it has a secret, more parsing and expectation required to know that a random URL might need decryption

jb55 2y ago

could just have a simple nip that defines a few # params and to pass Accept header for raw data. Would be nice for backwards compatibility.

If we go the nip19 + nip94 route this would be more work and encrypted images wouldn’t work in most clients, this would at least have a clickable fallback that gives clients an upgrade path. We still care about that right? Or do we want broken images in DMs too.

The amount of work just to get uploadable images working in DMs is starting to get crazy otherwise:

nip04

nip19 (required)

nip94 (required, not even planning on implementing this in damus)

nip04

nip?? (optional)

Vitor Pamplona 2y ago

We can do both. NIP-19 + URL.

To be fair, the proposed NIP-19 add-ons are not only for NIP-94 and not for just files. Other event kinds that use shareable-secret encryption can use the same technique.

graycat 2y ago

Maybe the Nostr protocol isn’t suited for sending direct messages? There are other protocols that are designed for it (e.g. Signal, SimpleX). Why does Nostr have to do it? Just because it’s a Twitter feature?

Vitor Pamplona 2y ago

The "Nostr protocol" is just an asynchronous relayer of signed content. I wouldn't call this "not suited" for direct messages.

Maybe the current implementation of DMs is not perfect, but that has nothing to do with the protocol.

graycat 2y ago

If Nostr is suited for DMs, then hiding DM metadata from the public should be simple to do. What's the solution?

Sirius 2y ago

Couldn't we just use the same shared secret we use for DM encryption?

Vitor Pamplona 2y ago

We could if we want to force it to stay in the DM (no way to decrypt without the private key of one of the individuals)

Sirius 2y ago

Or rather, without the shared secret that also unlocks your other DMs to each other.

Maybe decryption with shared secret could be attempted by default unless another secret is present in the link.

But link-specific secret is useful if you want to share it to multiple recipients.

Even if you share the link publicly, the file host won't see the file content unless someone sends them the link. I wonder if file hosts would love or hate that 😄

One consideration is that the file host needs to accept encrypted files, unlike some hosts that only accept valid images and may resize or convert them.

Vitor Pamplona 2y ago

> Even if you share the link publicly, the file host won't see the file content unless someone sends them the link. I wonder if file hosts would love or hate that 😄

That's why most hosts of "encrypted" files do the encryption themselves in the API and don't actually receive encrypted files (like Google Drive with encrypted file features). Which is not great.

Don't Believe The Vibe 🌱🍋🍊 2y ago

Not sure if i understand the question correctly, that part would be covered here:

nostr:nevent1qqstpm5z7k4f2j5w7q2525suj5sgam5v5g0vg783m3pgv4epf9hsawgpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqzwz379z

Isnt the survey about how UI would handle sharing or not sharing images from DMs? nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z can you clarify?

Water Blower 2y ago

I have lots of to catch up but alright, challenge accepted

8b278ad8... 2y ago

The trouble is that when you start inventing a distributed secret blob store you suddenly have a very different set of challenges than the ones that Nostr has already solved. Look at IPFS and Tahoe-LAFS and to some extent Scuttlebot's blobstore for some suggestions, but none of them are perfect and everyone still complains about these programs.

Really there should be a Nostr team and a team building the secret blob store, and we're risking too much technical debt being forced on the client AND relay developers.