Nostr Web Client

nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr what do you think about supporting a directory prefix in a Blossom URL? E.g. myhost.com/user-x/

It could be useful to manage a better filesystem organization in complex setups.

BUD-03 already requires this kind of parsing, so it should not create compatibility issues.

hzrd149 5mo ago

The problem with supporting custom paths is that the URL used to fetch blobs would be completely different on every server. which means before fetching a blob from a server the client would have to interview the server (fetch the api map) to know what endpoints it should talk to. they would effectively all be talking a different language and the client would have to interpret it.

BUD-03 allows users to provide a list of servers they upload their blobs to, but there is no expectation that extra paths in the URLs will be honored because its expected that every blossom server will handle a `cdn.server.com/` URL

All that said there isn't anything wrong with a server using a 301/307/308 redirect to another URL that actually serves the blob. I think blossom.band, and 24242.io do something similar to this

Reply to this note

Please Login to reply.

Discussion

daniele 5mo ago

Yes, you are right, it would start a mess.

And what about an internal implementation, where the PUT action takes a "dir" optional param, and the GET always point to the root but searches across all the available internal locations?

The alternative is to have a separate db that handles grouping (that is what I'm doing now).

hzrd149 5mo ago

If the goal is the sort blobs into buckets for performance reasons then what about taking the first 8 char of the hash as the "directory". should be perfectly random.

If the idea is to allow users to sort blobs into "folders" and have filenames, then I would caution against storing too much metadata that couldn't be transferred. blossom servers are in the business of storing and serving raw binary data. nostr is the protocol for storing metadata

For example there is nothing stopping you from making a plugin for NextCloud to support blossom endpoints. but users are going to be very confused that their "decentralized", "censorship resistant" files dont have the same names or folder structure on another server.

Either way I don't see any harm in servers having their own special upload endpoints or GET endpoints. just so long as they support the core BUD-01 and optionally BUD-02 it should be enough for users to effectively use multiple servers without worrying about each of their special features

I think of it like relays, some support negentrapy, but all support NIP-01 filters. so all clients use filters :)