Replying to Avatar Fabian

nostr:npub138s5hey76qrnm2pmv7p8nnffhfddsm8sqzm285dyc0wy4f8a6qkqtzx624 I tried a few uploads, it seems nostrcheck.me is always coming back with 1280x960 dimensions no matter which image, also hash is always empty

https://media.utxo.nl/wp-content/uploads/nostr/9/b/9bbc9df6c4580fed0bacf4d282043ed398f059e7e88608781cae83cef80ffc14.webp

I have detected the error.

If you notice I return you a processing_url with 202 header, in the spec of NIP96 it indicates that it should not return you neither size nor dimensions nor x at this moment, I suppose that in some update I broke it.

Whenever it returns processing_url you should process it as delayed processing (even though it doesn't take even 1 second).

I have already removed the size and dim tags from the initial response to avoid confusion.

Can you try now?

Reply to this note

Please Login to reply.

Discussion

Delayed processing spec for more info. If I can help you, let me now, and sorry 🄲

https://github.com/nostr-protocol/nips/blob/master/96.md#delayed-processing

Would this fix existing images?

I would say yes. I have seen your post in Damus and it looks good. I would say that if Fabian adjusts it the old notes will look good.

Thanks! Looks like it’s working ā¤ļø

I think it works now

nostr:note1eafx6rpdw2dkert0ngqs3yvsehwwlta3zqzwdp8jap06j0s79l0qglk7x2

But I’m not sure about the delayed processing, I have some code that handles that its never triggered because the response seems always status: ā€œsuccessā€, not ā€œprocessingā€, I’m checking that first before checking ā€œprocessing_urlā€

If I understand correctly, the spec forces me to return a 'succes' even in case of delayed processing, changing in this case the header to 202.