bud-12: media servers information document.

[kehiy]

as we know currently we have more clients relaying on blobs and users/clients need to interact with blossom servers more. this bud is similar to nip-11 and help users and clients to understand media servers behavior.

[kehiy]

@hzrd149 fyi. 🫡

[hzrd149]

I am resultant to introduce any kind of metadata document for individual servers. I'm sure it will be useful for describing a single server, but having a "information document" or "site map" can introduce an additional step when interacting with servers. and it opens up the possibility for servers to start acting differently (besides rejecting types of uploads)

For example if it became standard for servers to have an /information endpoint (or /.well-known) it wouldn't be a stretch for that document to contain a "downloadURL" field that should be used to download blobs from, or a "uploadApiEndpoint" field that changed the standard upload endpoint

Again not that big of a deal for a single server, but if the client/user needs to intact with multiple servers it becomes a very complicated process just to upload a blob since it would have to check all requirements for every server

For a good example of this look at the /.well-known/nostr/nip96.json document in NIP-96. IMO its way to customizable, which made it really difficult for users and clients to interact with the services

[kehiy]

this standard wouldn't contain uploadapiendpoint or downloadURL and similar stuff. it would just help client to understand what they are dealing with. how to contact them? what is their name? do they respect reports at all? or they are a dark web like thing? its paid or not? is it possible for media to be removed in future or not? and more.

[hzrd149]

this standard wouldn't contain uploadapiendpoint or downloadURL and similar stuff. it would just help client to understand what they are dealing with. how to contact them? what is their name? do they respect reports at all? or they are a dark web like thing? its paid or not? is it possible for media to be removed in future or not? and more.

Most of this can either be expressed in HTTP headers or on the servers homepage for users to read. I want to avoid is clients changing their behavior based on what server they are talking to.
Once clients start treating every server differently then we start to loose the simple interoperability between servers. again NIP-96 and NIP-11 are good examples of this. very few clients pay attention to or implement them because there is so much customization and restrictions to take into account

If the goal is to inform the user about how the server works ( upload limitations, accepted mime types, .onion urls, etc ) I think it would be a lot better to show that on the servers homepage instead of a json document that would rely on the client to support

[kehiy]

@hzrd149 these are logical reasons as well.

@v0l @quentintaranpino @pablof7z what do you guys think?

[v0l]

I agree with both of the points you made, this can be useful as long as it doesn't change any of the existing buds

[kehiy]

it won't break or change anything.

[kehiy]

should we close this?

[v0l]

should we close this?

No i dont think so, why would you close it?

[kehiy]

@v0l if it doesn't make sense and won't get implemented so its pointless.
but i think we need more discussion on it.

[v0l]

@v0l if it doesn't make sense and won't get implemented so its pointless. but i think we need more discussion on it.

If you close the issue it certainly will never be implemented :D

Try to get other server/client devs to give feedback

[1l0]

I would like at least pubkey information because I want to make a zap. Assuming that kind-0 is published for the pubkey.

[kehiy]

@v0l if it doesn't make sense and won't get implemented so its pointless. but i think we need more discussion on it.

If you close the issue it certainly will never be implemented :D

Try to get other server/client devs to give feedback

@v0l makes sense. i've mentioned them before, waiting for them to respond.

[kehiy]

I would like at least pubkey information because I want to make a zap. Assuming that kind-0 is published for the pubkey.

of course, it would be possible. and basically a pubkey with kind-0 published is expected most of the time.

it even enables tools like nostr watch to discover blossom servers as well and a lot more. currently they are just black boxes.

[erskingardner]

ACK.

I would like to have a machine readable file that gives some basic info about the server. For my use case, I'm principally interested in whether the server requires auth for the various standard endpoints.

This makes it much easier for my app to allow users to specify what blossom server they want to use and for the app to check that that blossom server conforms to the things we need; in White Noise's case, that the GET /<sha256> endpoint doesn't require auth.

[hzrd149]

I would like to have a machine readable file that gives some basic info about the server. For my use case, I'm principally interested in whether the server requires auth for the various standard endpoints.

For individual actions like a specific upload for downloading a specific blob, the HEAD method can be used to check for 401
Although I agree there is a use case for servers to describe their general auth / upload / retention policies

[erskingardner]

Yeah, it's easy enough to check on a case by case basis, if you have a file. But we want to know that group members will be able to download files without auth before we allow a user to set a specific blossom server they want to use. Otherwise it's pointless to allow the user to select it. So in this case (when we don't have a file url) we need to have another way to check, otherwise we'll have to upload trash to the server, then use the HEAD method to check for the presence of auth on the GET endpoint.

[kehiy]

@hzrd149 @erskingardner that's correct. using such a documentt is the most proper way for both users and machines to understand these stuff. basiccly we have a lot of usecases for this and also it won't break/change anything in protocol.

[quentintaranpino]

Wouldn't /info be better than /information?

[kehiy]

i can change it if everyone agrees with this.

@hzrd149 @v0l @1l0 @erskingardner

[quentintaranpino]

I'm partially in favor of adding this. However, I think we should first reach a broader consensus about exactly what kind of information we want to include here. It might be beneficial to give this proposal a bit more time to mature before finalizing it.

[kehiy]

@quentintaranpino yes, fields can change. i believe cashu paid storage information can be added here.

if we get implementations, we can finalize the fields based on people implementations.

[flox1an]

Can we maybe build this externally first, like an extended version of blossomserver.com (https://github.com/hzrd149/blossomservers) --> like caniuse.com?

IMHO it would make sense to expore what data is needed, for example I would like to know supports_range_requests, max_upload_size, etc.

[hzrd149]

For server discovery ( users choosing a blossom server ) I think it makes more sense to build that externally with nostr or a transitional website. blossom servers having a descriptive home pages can help with this

For things like range request support or /mirror support. those can easily be checked with a HEAD request. but there are a few things like "max upload size", "accepted mime types", and "expiration time" that cant easily be exposed using http headers

[kehiy]

this bud is not only for discovery. it has a lot of use cases that different apps and clients need.

http headers can't cover all needs.

[hzrd149]

this bud is not only for discovery. it has a lot of use cases that different apps and clients need.

This is what I'm worried about in a way. If we describe how blossom servers behave in a machine readable way then clients will start being developed against that and automatically selecting blossom servers without asking the user.

I don't think blossom successes if clients automatically select upload servers for the user and "hide" the complexity from the user.
The powerful part about blossom is that its not just a generic uploading solution, instead its a way for users to bring their own public storage servers to a client app

However having some information about the servers rules / policies is necessary to allow users to pick servers. but I'm undecided how much of that should be described on the servers homepage (In human readable format) or in a machine readable file
A good example of a homepage is https://24242.io/ it allows users to quickly get an idea of how the server works and what the user could use the server for

P.S. Sorry I've been ignoring this PR and thread for a while, I've been busy and I don't think we should rush something like this

[erskingardner]

I don't think blossom successes if clients automatically select upload servers for the user and "hide" the complexity from the user.

I'm very sympathetic to this. That said, I think machine readable capabilities gives clients the ability to build some safeguards to help users select blossom servers that do support the features that they need in order to function properly. There's no point in giving a user choice, then allowing them to select a server that isn't going to work. Or, only slightly less bad, giving the user loads of required tech specs and then hoping that they'll work out what blossom server might be compatible.