nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Why is Amethyst appending all that extra data? The original image URL is much shorter.
Discussion
It's the NIP 54 proposal. It adds a bunch of tags to clearly define the content type, facilitate previews and size calculations before downloading the media. https://github.com/nostr-protocol/nips/pull/521
ugh. this feels very wrong.
we're gonna need a new term like cowboy coding that is applicable to adhoc spec development
This.
I definitely prefer NIP94, which is available since March on Amethyst. But here we are...
I'm confused. Are you saying there's a setting in Amethyst that can get rid of the ridiculous URLs?
I thought it was a server issue...
It's not a server issue. The extra parameters are needed to create previews and prepare the UI for the size of the image. There are multiple ways to do it, but in the end they will always be there.
It's better to have them in the URL directly if people are copying urls from post to post. Then they copy everything together.
Copying attachment URL that were longer than the user post / reply is absurd.
Why not handle it in HTTP header instead? (Like with `img_bitmap` http header representing the bitmap of image preview) or even via event tags?
Sure. You want to get this working well. But putting everything into a single URL creates a big burden for users.
Copying a url with all the tags in it is key. Lots of people copy the url from somebody else into their posts. If we place these tags in any other location, they are not going to be copied to the new post. In this way, users keep spreading the improved experience even in clients that do not support these tags.
What lies along the skewed lines? Some kind of density? I don't understand the numbers on that, the labels mention no units for that.
Nip 54 inline metadata. Not a terrible idea, but in practice much worse than Will's imeta tag.