From mime type
nostr:nprofile1qqsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqpramhxue69uhkummnw3ez6un9d3shjtnyv4ex26mjdaehxtndv5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszxthwden5te0wfjkccte9ekk7mt0wd68ytnsd9hxktc79dllq any chance you can whitelist my key to test this on your server? :)
Nevermind, I can test on void.cat directly
Sorry. Yeah we're running the same docker verisons I believe.
Added your npub anyway so that you can test since I have whitelisted npubs and Kieran does not.
On void.cat, the mime type for a PNG is coming as application/octet-stream Is that correct?
It just returns the content type from the upload, you're getting the fallback type so probably didn't set it in the request
So, I am sending image/png as form field content_type, but it always returns with application/octet-stream. I am not sure what I am doing wrong to get this.
Also, I'm getting a NIP-98 related timestamp error on Amethyst using my own install as well as Kieran's server. route96:routes::nip96::_ > Request guard `Nip98Auth failed: "Created timestamp is in the future" If I disable whitelisted npubs it works, since it's not using authorization.
Can you check date time of the server and date time of the phone?
My sever and docker container are in sync with NTP running. Phone seems accurate too.
Yes, I had this same issue with timestamp on Amethyst for NostrMedia.com and had to set an acceptable time deviation rule. As for the other errors, mine is both Blossom and NIP-96, but afaik most folks aren't having issues uploading, if you also wanted another sample to test @Vitor Pamplona
Interesting. How big is your acceptable deviation? I have a feeling that some phones stay a few seconds in the future.
Ah maybe we don't use that one atm, only content type header, will check
I also send it as part of the multipart file. I am not sure where that goes though 🤔