Nostr Web Client

nostr:npub12x8ywtnvel5r0frfzv45sj2xzws97dzt84t3wz6uxc5em9a2erws8fmjy3 nostr:npub1yqwcsafkzl4fequd25qg6yvmyxusk8gmpe7hkpfcnzc34afx4npsfhwajx nostr:npub1dft4ckvyhfpw3n56zm8j42nzrjeummudr2vmkf304eu5jhnn0ahqz7ta3d The content-type Will be set correctly. That seems to me to be the only sensible way.

Podverse 2y ago

it's a good call, and I started down that road...but this looks like we're going to have to introduce another layer of storage and data mapping to be able to handle...

we can *request from server and save* the image no problem with a HEAD request...but then to get the chapter image out of our local storage/cache, we only have the original chapter image URL to work with, and at that point we don't know the extension again, so we don't know the file path in storage...

Reply to this note

Please Login to reply.

Discussion

Podverse 2y ago

nostr:npub1jtm4dxvu3ccgk60wvvt0uw9j9vz7nuc80f7agrv0vgkkushxk5zq0rrxtn nostr:npub1yqwcsafkzl4fequd25qg6yvmyxusk8gmpe7hkpfcnzc34afx4npsfhwajx nostr:npub1dft4ckvyhfpw3n56zm8j42nzrjeummudr2vmkf304eu5jhnn0ahqz7ta3d and we obviously can't make another HEAD request for the "retrieve from storage" operation, since retrieving from storage is meant to work offline.

It's definitely solvable somehow, although I'm not looking forward to possibly having to add a whole new key/value mapping in storage in order to account for what appears to be the first edge case we've seen like this in chapter images. I'm talking to Creon tonight to see if he has better ideas...