Someone told me that #Amethyst has made some controversial changes.
Wat happened?
Discussion
#[2] Is there a long-form explanation on this, or is it just scattered in various notes transmitted by relays? I’d like to be able to understand the bigger picture, pun intended. 😉
Lmao 🎯🎯
Not really. The main issue seems to be that part of the community doesn't want quotes in Kind 1 events (the text posts themselves) that are not other Kind 1 events (other posts). In their mind, for Nostr to stay simple you can only cite events of the same kind.
This for me breaks the entire idea of event composability of Nostr, like having a Poll as a quote of a regular post or being able to report a like.
NIP-94 offers a way to add an image to Kind 1s via a Quote. The kind 1 event will include a Kind 1063 event, which has a URL field that can then be previewed in the post. So, instead of a direct URL, the client has to load the quote first and then the URL.
Since most clients already load quoted notes, it's not really hard to load a kind 1063 and get the URL. But because it's a different event, they are fighting against it.
My push for NIP 94 is simple. All static content inside a Kind 1 event must be immutable (hashed or signed). Otherwise, as we scale, static content servers will be the target of attacks. The idea is that if you can't change what somebody said, you can change the image they linked and completely reverse the idea of the post.
Image servers we use today can also go evil at any point in time. They can serve ads in videos or watermark pictures by changing the linked file itself.
It might not be a problem for now, but as we scale up, we will see more and more of these issues.
How will content loading optimizations like image resizing and encoding be handled? Every CDN does this to improve performance.
As long as they don't change the file, which most CDNs don't, it should be fine.
CloudFlare resizes the image, and encodes it into a different format, depending on the platform it is loaded on.
I'm not arguing against your idea, I'm all for security, I just don't think most image hosts make a bit-perfect guarantee. Mine doesn't. It doesn't store the images in their original format even. Is the hash created after upload? Will this require a special API for hosts?
Here is specific information on CloudFlare.
Amethyst creates the hash after the upload.
So, you can do all the changes you want when uploading, the user will preview the image and if it's good, the app calculates the hash and saves to the Nostr event, thus requiring that your server doesn't change it anymore.
Well, respectfully, that will end my being able to host images for Nostr. It will also rule out several very large backends from being usable, and rule out a lot of potential bandwidth optimization.
I very much respect your goal here, but as stated, it will not be feasible for me to contribute space to Nostr images if this becomes a requirement.
Will this be an optional feature?
I am sure some clients won't verify the hash. Amethyst will still display the image for now but with a red warning on top of it.
Do you mind explaining why do you must change the image afterwards? I don't think users expect that at all.
The software I am using (FOSS) provides functionality that allows the user to link to their uploads in a multitude of formats. In the backend, it stores all images as QOI format for efficiency reasons. Upon request at a generated URL, whatever format they request is generated and cached for a time period.
This is a minor thing. Other image hosts resize images for smaller screens to save bandwidth. Data usage is already a top complaint I hear from fellow nostriches, so I think these things should be considered inv your planning. Images are heavy, and we should eventually be able to optimize for that.
Again, I love the idea of tamper evidence, but wondering how this can work. Is there a way to use perceptual hashing?
Is it theoretically possible to have a hash function compatible with a resizing algo? For instance, if the resizer agreed to keep every N pixels intact, and the hash function only hashes those particular pixels? Likely N would have to be large enough to make it difficult to create a fake replacement image. Maybe every fourth pixel, which would be compatible with image resizing to 50% or 25% directly. Or every pixel in the center square of the image?
But really, I still don't understand the problem with #[7] method.
Don't mind me, I'm drinking.
first time Vitor deeply explaining himself, sounds to me-
vitor: immutability 1st.
will: reverse compatibility 1st.
#[4]
Not that I know of. He asked a somewhat controversial question about a possible feature addition, and people voted overwhelmingly "No". But I think he was just trying to get an idea of what kinds of features people want and what they definitely don't want.
#clientwars