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?

Reply to this note

Please Login to reply.

Discussion

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.

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

Agreed

Yay first comment

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: https://fosdem.org/2023/schedule/event/matrix20/

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.

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).

https://github.com/blakejakopovic/nostr_paywall_example

You can decide to send it to somebody else or not its up to you, using the nsec wont change that