bud-12: media servers information document.#58
Conversation
|
@hzrd149 fyi. 🫡 |
|
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 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 |
|
this standard wouldn't contain |
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. 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 |
|
@hzrd149 these are logical reasons as well. @v0l @quentintaranpino @pablof7z what do you guys think? |
|
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 |
|
it won't break or change anything. |
|
should we close this? |
No i dont think so, why would you close it? |
|
@v0l if it doesn't make sense and won't get implemented so its pointless. |
If you close the issue it certainly will never be implemented :D Try to get other server/client devs to give feedback |
|
I would like at least |
@v0l makes sense. i've mentioned them before, waiting for them to respond. |
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. |
|
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 |
For individual actions like a specific upload for downloading a specific blob, the |
|
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. |
|
@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. |
|
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. |
|
@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. |
|
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 |
|
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 |
|
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. |
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. 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 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 |
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. |
|
its now planned on nos3 blossom server to be implemented: dezh-tech/nos3#20 |
|
also, more users are demanding this: #66 which means it's needed... |
hzrd149
left a comment
hzrd149
left a comment
There was a problem hiding this comment.
I like half of this BUD and am concerned about the other half
I like the ability for servers to advertise a name, description, policies, and software information. However I think the concept of defining limitations or generally how the server behaves is not a good direction
Trying to define how a server behave using a static limitations json will only make it more difficult for clients to use the server. presuming they want to parse and understand the limitations defined in the info doc first
Maybe I'm wrong, but from what I've observed around NIP-11 and similar NUT-06. clients only end up using the general information defined in the documents. The limitations are rarely ever used
P.S. Sorry I've been ignoring this PR for a while and for the harsh comments now. but Its taken me a while to gather my thoughts about this
|
@hzrd149 thank you for your suggestions. ive just updated the spec. i kept icons and supported buds since they won't break anything, and they are just information. but i removed the limitations part. |
|
This spec uses the exact same names as NIP-11, which is good. I think this is an important addition to the spec, allowing both system administrators and users to get a minimum set of metadata from the media server. The uploading_policy is an important aspect. I think Primal just upgraded their Blossom server and now my Nostr app doesn't work anymore, I have no idea what software they might be running, what policy has changed, etc? It just returns errors when I attempt to list my files. At least as a technical person, I could mitigate it if there is upgraded to servers, different implementations incompatibilities, etc. Without any info, I'm stuck with asking the admins... and who are users supposed to contact, if there is no BUD-12 information to begin with? It will be abused; I am planning on abusing this with some extra fields. That's not a good reason to don't include this though, that is the nature of anything. 👍 |
|
@sondreb thank you for explaining this. you can add extra fields to bud12 documents as well. also, we hace contact information on current standard. |
|
update: khatru implementation: |
|
NIP-11 was a mistake, and this will be also. Please don't merge. |
|
why? also, we can see enough use-cases and developer requests for this. |
Strong opinions need strong reasons. :) Why was NIP-11 a mistake and why would this be? |
What matters is the need and purpose. I have a purpose for NIP-11 and that is showing nicely formatted information about the relays to user's. Additionally there are multiple NIPs afaik that explicitly says to not post event kinds to relays unless they specifically support certain NIPs. How are Nostr clients suppose to figure this out, without NIP-11? There are two ways to connect with servers, either through protocol/software versioning, or capability-discovery. If there is no NIP-11, it means clients need to poke and query what features the relays actually supports. It is obviously a horrible idea to have the clients attempt various features to see if it works, so either NIP-11 or the relays should send capabilities (and metadata) in a reply to a REQ. Clients needs to be informed about NIPs supported by the relays. For this purpose, NIP-11 is not a mistake, it's the only source for this information that is reliable. Perhaps relays have started returning NIP-11 metadata over WebSocket now that I don't know about to replace this capability of NIP-11? |
|
This makes sense if it stays strictly descriptive and optional. Basic metadata like name, contact, pubkey, etc. Useful for tools and users. No behavior, no endpoints, no client-side logic should depend on it. Dropping the limitations part was the right call. If this turns into another NIP11 full of optional complexity, it will get ignored. Keep it minimal and factual IMHO. |
This makes sense, but its something I want to avoid. ideally blossom servers and the blossom protocol can be simple enough to where it does not need to be "negotiated" between clients and servers. Maybe some negotiation or discovery is necessary for clients to understand how they can or should upload to servers. i.e. does it support /media, can I upload this mime type, etc... but I don't think negotiation or discovery helps at all for downloading blobs. This is what I'm hung up on, I understand the arguments for having a simple information document (name, icon, metadata, upload policy, contact info, etc) but I'm worried about the protocol fracturing or becoming more complex if servers start to introduce extra metadata field that clients start to rely on before connecting to the server
I generally agree with @fiatjaf that NIP-11 was a mistake. It was convent to have the owners pubkey and contact info, but from my experience the and again I apologize for ignoring these conversations for weeks. I need to start setting more time aside to maintaining this repo |
The |
|
When a user adds a relay or media server, they could (should?) be presented with the policies that apply. I want users to explicitly accept agreements and policies for relays and media servers. Doing implicit agreements is relying on the State. |
NIP-11 is only useful for providing a name, an icon and a description for the relay, and a public key. But because the relay name should be its domain name and the relay icon should be
Maybe these things are mildly useful for relays, but for media servers? They're barely useful and more likely to be harmful (names allow impersonation while DNS doesn't, for example). Also media servers are much more likely to remain commoditized than Nostr relays, so their identity should matter much less.
A standardized JSON object will never be enough for an agreement. Users should either know the terms because someone told them or they memorized or they should go to the media server website and read what is to be read there.
I'm interested. Why? I don't think there is an implicit agreement when you just upload a file to a server you don't know at all. You just uploaded the file, no one has agreed on anything. What has the State to do with it? |
|
I believe in a contract society, where everything is based on voluntary agreements, no implicit rules mandates by a third party. When I provide a service, I want to give information and receive consent from the receiver/user of the service. It can of course be enough to simply redirect the users to the website of the media server and have them find agreements there. If there are no implicit contract behind the media server, meaning they (the service provider) don't care about the State, it means anyone is allowed to upload anything to those media servers. This is obviously not the case, most people who host these media servers want their users to follow certain rules and many rely on the implicit support of the State. That's a whole different discussion though, if this JSON endpoint don't get added it's fine, I'll send user's to the websites. |
|
@kehiy The BUD looks better without the Impersonation may be an issue because users could start referring to (and searching for) servers based on the name instead of domain, in which case it would be easy for bad actors to spin up 100+ servers with the same names as popular servers Also for the uploading policy URL, there may be some small use for having it available in a JSON document, wouldn't most servers have this in big bold text on their home page? |
|
@hzrd149 Users/clients must take care of their security by following best practices, I believe. For the privacy policy link, without BUD-12, they can put it on their home page as well. Like a big text or in their website footer/header. I use both NIP-11 and manual documents on the website for my relay. I still prefer to keep such things in the standard, but the rest of the decision is up to other devs and users here. I keep an eye on that. |
|
Any updated on this? |
9 participants
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.