Replies (63)
I guess it wouldn't strictly be necessary to link to nip94 of nip19 could reference a url
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?
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
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?
Got it, so they would still need the key
Couldn't we just use the same shared secret we use for DM encryption?
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
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.
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)
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.
I wouldn't put the secret in the URL. Otherwise, the image host also has access to the secret and thus the image.
Yeah # is never sent to servers
Doesn't it make it confusing? Now if you copy and paste the URL into the browser, it doesn't decrypt anything because it doesn't know how to.
Media hosts that support arbitrary/encrypted files could build javascript viewers on their domain. Encrypted pastebins work the same way. I suspect some image hosts wouldn’t want to host arbitrary data (encrypted blobs) so we would need dedicated hosts for this? An ephemeral, encrypted, pastebin-like thing for files would be cool.
Pretty sure #[2] ‘s void.cat does this, store encrypted non-image files as blobs.
I can also allow for encrypted files coming from clients, and put them
In another location. Glad to experiment!
In this case, the site controls encryption and decryption. With Nostr, we would encrypt it directly on clients, which then requires clients to follow whatever encryption scheme the hoster is providing in their viewer.
The URL also gets saved in the browser history which is not great.
Awesome! This has been the thing that has been stopping me from adding image attachments in DMs. If i could encrypt + upload and then store the key in the # then it would be perfect. Could build a quick js viewer as well if someone hasn’t done that already.
The site can only decrypt client side and only if the # is included. Otherwise the nostr client can pull the raw data and decrypt locally from the key in the #
The server never has access to the key unless the user clicks the fallback link and the js code sends the key to their servers.
Nostr clients that support these links could just render and inline image and never show the fallback link.
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.
> 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.
If we do this, we need to remind all clients to remove # from `r` tags when creating events.
Does amethyst add those when someone pastes a url? Is that a nip? Not sure if any other client does this 🤔
void.cat does this, its all client side
Not sure if i understand the question correctly, that part would be covered here:
View quoted note →
Isnt the survey about how UI would handle sharing or not sharing images from DMs?
@Vitor Pamplona can you clarify?
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
Example:
https://void.cat/GGwv29XHjFY1sNgE8JPUYL
Key: 59919f1f26a3d71e28055d0fa35872a1:03d6fc0a2bdfce1c276a10bf
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)
vs
nip04
nip?? (optional)
If Nostr is suited for DMs, then hiding DM metadata from the public should be simple to do. What's the solution?
Do these links support the # thing? That would be neat
No but it used to, people just paste the links everywhere with the key attached and it didn't offer any barrier to entry for DMCA takedown requests
Ah i see, so void.cat couldn’t be used for the # fallback idea
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.
It could, if thats what people decide to use
Why “anyone with link” instead of encrypted with the recipient’s public key? If I DM someone an image why would I want it viewable by anyone else with just a shared link?
There is no difference, you can just save the file and send it to somebody else
Right but then there isn’t proof that I sent it. It’s one step removed, it takes intentional action/reupload unless they want to share their private key?
But I guess this link way presupposes you don’t like nip 94 and native image uploads to relays, encrypted or not. Idk feels like the leaning tower of nostr, more bolted on hacks upon hacks 🤷♂️ why wouldn’t we want native specialized relays hosting these files with proper nostr key encryption / signatures
Tldr “anyone with link” sucks. Anyone with nsec or gtfo imo for private content
This is a fair point, this would break images in DMs though. It would just be a link that you couldn’t click to view.
You can decide to send it to somebody else or not its up to you, using the nsec wont change that
And kieran has a good point: if they wanted to share the link they could just save it and upload it to a public link. Just a few more steps, removing the shared secret from the fallback link would just make a bad UX for little gain.
Maybe nip94 encrypted images (pay per upload/download via specialized relays that want to do this. It’s not free to store and transmit images anyway so users should pay the cost with a single tap like a zap. Anyone could pay the fee and download the data but only correct nsec could decrypt?
I’m DMs I don’t think this friction is a dealbreaker, for normal feed images it is.
In*
It would be nice to have encrypted inline images in DMs in the simplest possible way. Otherwise DM images sent by snort and amethyst will be broken in all other nostr clients and that will be yet another wart on the protocol.
I think if you ever did implement nip94, DM images in particular would be where it could make sense. Ppl expect their DMs to persist, native nostr relay image hosting for this use case makes sense for me, ideally the micropayments to keep the circular incentives flowing for all parties would just happen automatically but idk how to do this without making Damus a wallet itself or Apple allowing some new kind of automatic background interaction with another wallet app?
More broadly, users should shed the fiat mindset of everything being free ‘?somehow?’ and understand that services cost money, fractions of a cent even to incentivize ongoing storage and transmission of data. Encrypted images in DMs is the shallow pool to get their toes wet for the future when all services are run on LN micropayments automatically running in the background
I have lots of to catch up but alright, challenge accepted
Agreed
Yay first comment
I am also open with
@Nostrfiles for a separate endpoint and location for encrypted blobs. 👋🏽
It seems to me that nostr is an awesome social media protocol but just not really meant for DMs at all. The current solution seems a little clunky and not scalable to a good messaging experience. What if nostr added some support for people including their matrix usernames and then nostr clients could work to incorporate a full matrix messaging experience in addition to the social media side of things that already works so well. A client like this would have a fantastic social media, messaging, group chat, video calling, and payment (via lightning) experience. It’s like a decentralized super app lol.
Matrix is a horrific protocol last i looked at it
Interesting! why do you say that?
I’m partial to #[8] myself if we’re talking of porting DMs to another service
It feels like SimpleX's concept of rotating message queues can be easily recreated in Nostr.
I’d never heard of it before, but definitely looks interesting
Yes, maybe people have experienced the horrificness.
There is a talk from earlier this year about how they are making an noble effort to improve the thing in their next version:
Have these changes already started taking effect? I admittedly don’t have much experience at all with matrix but tried it the other day and thought the basic messaging functionality at least was fairly smooth. Far from the worst I’ve experienced haha
I use their Android Element client and room sync is way faster than it used to be, as demonstrated in the talk.
The UX still bothers me though, I wish it was slicker.
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.
I’ve build a POC CDN that can support 401 Unauthorised / 402 Payment Required. It’s centralised, however can support custom domains. It uses NIP98 HTTP AUTH.
I have a local version that’s more advanced, but not yet ready to release. Mostly because I’m still working out a cross-compatible payment flow for lightning - something like LSAT, but with Nostr auth instead of receipts and cookies (which can be shared).
GitHub
GitHub - blakejakopovic/nostr_paywall_example: This is an example Nostr rust project to enable '402 Payment Required' responses for requests to paid content.
This is an example Nostr rust project to enable '402 Payment Required' responses for requests to paid content. - blakejakopovic/nostr_paywall_example
