I think there is a small bug in Amethyst image uploaded . nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z:

Images that are uploaded to nostrfiles.dev from within Amethyst seem to loose the "s" of "https", which is especially bad for a .dev domain.

E.g. one of my last images that has been published from within the Amethyst image uploader:

{"pubkey":"f9a352db4aa115ec5d330540dda37b71e2460cc0f65e3318fa3b244945dc8eb8","content":"#sunset 🌄\n\n","id":"f6e0683264978387f497f7a662594620f09474d70891430b23852851a83d1838","created_at":1687893557,"sig":"dcf966c22f3f15d852c5c8bf5679a73577d5a47c4ad1a7d136af75d6804f800a2d2ead18b94f8abeaf5cbc19459aeac7eda378ab488b85c11c23eecadcccc806","kind":1,"tags":[["t","sunset"],["t","sunset"],["r",""]]}

Reply to this note

Please Login to reply.

Discussion

We're sending to https://nostrfiles.dev/upload_image actually 👀

That correct. I didn't make any changes since the initial implementation. I think, that the "s" of https gets lost during handling the answer of the API and inserting the URL.

As an example: if I insert now another image, than again the URL does not contain the https:

screenshot of previous message:

We're putting in the event what the server is sending back.

->

return tree?.get("url")?.asText()

Oh damn, sorry, fund the bug in the API, so it gets lost on my end. Sorry, sorry, sorry! 🥺

Will fix it later the day and push a new deployment.

All fine :)