Yes I saw he updated it to this later, my bad: https://github.com/renostr/nrps/blob/master/nrp-1.md
nostr:note1wra64ux3w5fwxjd3y3v63pwxkmx64p57564zkjk6xj0a87k8keuqy07l34
It is strange it’s not just a simple toggle in the settings to turn off all these built in filters for users who want that… #[2] can it not just be default on but user disableable?
Could relays be free and paid at the same time? Accept notes of a certain size freely but come back asking for payment of LN invoice to accept notes containing more data than their set threshold?
Seems like paid encrypted DM image hosting could subsidize the free services relays provide?
nostr:note19zqrrs38pw88dl3r6t6tmqfam5kd6zlx7dppz47kxwmk3mxnwefq9x4tmc
For your first point, I propose only paid relays would accept images since they cost so much to store and transmit. The market would discover how much this costs and users can pay seamlessly via the lightning network. Image compression can be offered to lower the cost to users, let them decide on the image resolution that makes sense to them.
For your second point, I propose this feature only be implemented for encrypted notes, relays would have no access to the unencrypted image data. To me this absolves them of any liability same as Signal’s servers when they host image data they cannot decrypt, do you agree?
For your third point, bandwidth concerns are present if a users is uploading to a relay or to an image hosting website. But with relays, they have the option to pay more to add more redundancy on additional relays, and this can be done after the initial upload as long as at least one relay or their local client has the note data. Thoughts?
P.S. #[3] putting Dave on here was a great move :)
Please expand on “As for the issue of image hosting, I agree that it may not be the best fit for the Nostr model.”
Yes, my point was you kind of restated what I said in a different way without actually saying anything new, like Karen on Veep does whenever asked to opine on something
The same legal liability?
The legal liability is not on the developer, but on the shipper of the app.
But you didn’t ship *that* app. Someone would have forked your code and changed it and then shipped it. You aren’t anonymous, they could be.
*someone* could fork Amethyst and remove the TOS and submit it to fdroid, isn’t this the point of FOSS? If #[4] isn’t comfortable doing this for liability reasons does that stop others?
:P you remind me of Karen on Veep Dave, very merits and demerits of you
Eh, text can be very illegal depending on the jurisdiction. But keeping this experiment siloed in encrypted DMs is a way to mitigate a lot of these risks brought on if the data was public and not deletable.
Users could choose the level of paid redundancy they want. If I wanted to pay the cost to reproduce the image DMs on 4 relays so be it, user choice?
Idk the best way for relays to handle larger amounts of data, but as a user, I understand data storage and transmitting isn’t free, I’d support paying via LN for specialized relays to support this activity, in whatever more efficient form it takes
Seems like inside DMs is a perfect smaller playground to build this feature out without breaking images for main feeds on nip95-reluctant apps.
Serious question, anyone actually happy with a random 3rd party image host, singular, hosting a note’s content? The whole point was to be redundant, uncensorable, relay-based I thought.. anyone? #[3] #[4] #[5] ?
Fair I guess but also, if nostr is the new internet when do we create relays that are designed to handle large blobs? Pushing all images to 3rd parties, a single one per image, that can arbitrarily delete data, seems fraught. With nostr native users can have redundancy and backup to their own relay. How do I do this with 3rd party image hosts, upload it to every one simultaneously and include every link in the post in case some break?
Seems way more hacky than imbedding the data in a note directly and backing that up via the native nostr relay redundancy, to multiple paid relays and my own, and dynamically easily rebroadcasting it as needed.
#[3] #[4] can initiating a DM somehow negotiate opening of unique private subrelays on shared relays between participants that could host larger data blobs like images and optionally (probably) require ongoing micropayments to access and use?
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