Blossom doesn't specify what format the "url" field should be in however it does require that servers make the blob available at "GET /
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c
Do you think it Is worth adding a requirement for what the url should be in the spec?
To me it is only a small annoyance that when I get a URL in a descriptor I have to check the last part to see if it already has an extension, and if not add one matching the original uploaded local filename. If I use BUT-01 GET /
I like that. I'm still undecided if there should be a requirement for the "url" to be the "GET /
I agree. Because we are adding it anyway in the client side to facilitate figuring out the mimetype for previews.
Yes having the extension requirement for URL descriptor would be great and clients using that returned URL. This way the URL structure can be different from just the /
Which would be a happy compromise imo nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr as otherwise I'd have to completely rebuild NostrMedia.com from the ground up to support only GET /
I'm undecided if thats a good thing or not. but thats how it works currently.
either way nostrmedia.com should support the "GET /
Could you please clarify which hostname they'd use? For example, we use nostrmedia.com as the hostname for /upload endpoint, but files are stored under file.nostrmedia.com hostname. Are the GET requests going to be to nostrmedia.com/upload/
And does it now mean if we're going to be enforcing file extension that the GET requests will be /
Or, maybe also include using the returned URL in descriptor as a fallback? That way there's backwards compatibility? Since, a lot of current Blossom implementations appear to be utilizing it in that way.
no, the extension on the "GET /
Although I'm going to open a PR tomorrow to make the file extension required on the "url" field returned from the /upload /list and /mirror endpoints. since that field is intended to be used by the client and the client generally needs the file extension
The "GET
generally its also good to have the /upload endpoint on the same domain because clients wont be able to easily know about both domains. and when users select a the blossom server in a client they would be only setting one of the domains
Hmm that might not work for a lot of folks who use object storage providers... including our friends at nostr.build if they end up wanting to also support Blossom, as their media is on various subdomains too.
So, maybe the default could be
Or, am I completely misunderstanding this and the GET to /
Client can and probably will use the "url" field returned from the /upload endpoint when composing kind 1 notes. although the GET /
If my main server cdn.hzrd149.com went down or the image was removed from it. clients could lookup my preferred list of blossom servers (kind 10063 event) and start going down the list asking each one for the exact same blob (without needing to know how the server works)
1. 
2. 
Thats the point of requiring the "GET /
Ah gotcha! Ok, thanks for explaining that 👍
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub16jdfqgazrkapk0yrqm9rdxlnys7ck39c7zmdzxtxqlmmpxg04r0sd733sv nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub138s5hey76qrnm2pmv7p8nnffhfddsm8sqzm285dyc0wy4f8a6qkqtzx624 PR for making the file extension required in the "url" field https://github.com/hzrd149/blossom/pull/38
