My writing can be a bit complicated to follow without me realising, don’t hesitate to ask for clarifications. Comments, criticism and suggestions are welcome too!
– baschdel 2020-06-06 21:33 UTC
The two proposals seem to be very similar. If the world ends up using your proposal, I won’t be sad. 😃
As for specifics: I find the use of TAB to separate fields reminds me of Gopher and that’s not really something we need for Gemini. It’s also harder to write about in documentation because it’s invisible and easy confused with spaces, unlike newlines. I also felt that my proposal just uses status code 59 and manages to do well enough so I am not convinced we needed all the extra.
I also felt that it was a lot longer and I can’t put my finger on specific sentences and paragraphs but after reading it, my main reaction was: “wow, that’s long. Do we need all that?” Specially since I already know that the minimal format I use is working.
I also feel that I’m not interested in the kind of client certificate authentication that Gemini uses: I don’t care if two edits are made by the exact same user, and I might want to restrict edits even if they have a client certificate, so the proposal now forces me to keep state, and a database of known certificates, instead of a much simpler list of tokens (possibly just a single editor password for everybody).
As you can see, nothing big, but still a lot of friction.
– Alex Schroeder 2020-06-06
The reason I have used the TAB-separated approach to send metadata tab separated (despite liking and actually preferring Alex’s approach of putting them onto separate lines) is to keep the request scheme of Gemini, client sends one line to the server and the server reply with a status line, however an in spec Gemini client would never write a
gemini+upload:// URI to the server anyway, but the chances of flaws with implementations being discovered should be higher when the client fails because of an unrecognised non numeric status code instead of waiting for the server while the server waits for the client, eventually timing out.
The many response codes are there to always let the client know why the upload failed. As a client developer this is a big one for me.
The third stage however could be replaced by a simple optional redirect that sends an URI on one line or an empty line. But because of the way I specified authentication, I wanted to keep the option to save a redirect in the proposal, also the server could send some human readable information directly to the client after the upload without being limited to a single line or having to store it until the user decides to follow the redirect: detailed descriptions of errors, friendly links to manuals, tokens to delete the file etc.
On authentication tokens: I’m still in favour of putting them into the URI (client certificates are OPTIONAL) instead of having a dedicated token field. Asking the user for something, not knowing what the server wants to know is extremely inconvenient and is guaranteed to confuse at least some users, especially if the server doesn’t even care about that field, or uses it something other than an authentication token. Implementing the other one would require me to do about five minutes of work on my client plus another five for fixing bugs, but designing the UI in the least confusing way would be quite challenge without having a reliable source of information on what to ask the user for.
– baschdel 2020-06-06 22:06 UTC
You point about a lack of good UI is well made. My error messages are necessarily terse and I don’t like that, either. I think the better solution (though unlikely) would be to allow a payload for error messages, too. Like HTTP: if a page does not exists, you have three levels:
I really like that.
– Alex Schroeder 2020-06-06 22:21 UTC
On the three part error message: The proposal already supports that in its current form by jumping to the third stage (downloading a response from the server) when the server sends an Ex response code whith a message (or in the case of the file being too big the maximum allowed size)
Examples for failed uploads and uploading using only a tken will be added soon (TM)
– baschdel 2020-06-06 22:33 UTC
I added a few more examples and tryed to give the diocument a bit more structure by categorising the stage 1 responsecodes.
The stage two responescode “E_” was replaced by “EC” in order to avoid one code having two meanings.
Code 41 in response to Stage 1 is now specified to indicate a full disk as this makes the uploading functionality temporarely unavaiable and is a kind of overload.
– baschdel 2020-06-07 01:13 UTC
I made a diagram, that visualizes the protocol, to view it your browser has to support UTF-8 (If it doesn’t the first version was uploaded as a png image) gopher://alexschroeder.ch:70/0Baschdels_spin_on_Gemini_uploading_diagram https://alexschroeder.ch/wiki/download/Baschdels_spin_on_Gemini_uploading_diagram
– Anonymous 2020-06-07 21:16 UTC
I think my main issue is the multi-staged approach. Perhaps I’m simply used to stateless protocols like HTTP, finger, gopher, etc. Waiting for the WR response seems to offer little benefit.
On the contrary, I currently have the problem that my site cannot tell users “this is a page you can edit”. They just get an error if they try to write to the wrong URL. I also cannot link to the editable URL because following the URL is going to be an error due to the unknown URL scheme. Solving that problem seems more interesting to me right now.
I don’t mind mind more error codes explaining what the errors are, but I also get the feeling that many of them don’t result in clients doing anything other than displaying an error message. And once we’re simply displaying an error message, we could also just use 59.
I’ve used the token idea for leaving comments on this site, though: you have to answer a simple question when trying to leave a comment via Gemini: follow the comment link and you are asked for the question, answer the question and you are redirected to a new URL where you are asked for the comment, and finally you are redirected back to the page with all the comments.
– Alex Schroeder 2020-06-08 07:09 UTC
I have tryed to improve the section, and made it explicit, that the client does not have to wait for the server to send a WR response, at the risk of the uploaded data being ignored.
When it comes to the status codes: You are right most of them will on most clients result simply in an error message to the user (but that is also the case with the whole 4× and 5× range on gemini), but a dedicated uploader for, say mediafiles could offer the user to convert the file to a different format if the current one gets rejected, or to drop just enough quality for the file to be accepted if its too large. Also a well behaved automated client (bot) will wait at least a few hours if not days, when it receives a 59 or 53 code as this indicates, that the server does not support uploading at all.
I’m sure people will come up with other genuine uses that depend on the server telling the client why the upload was rejected. (With a single status code, you have to guess that based on the message wich kind of works when you expect the message to be in english and the server replys in english but falls apart, as soon as any of these assumptions mismstch (also no assumptions was one of the goals, if I havn’t messed that up too))
– baschdel 2020-06-08 10:21 UTC
Also I like how you implemented commenting on gemini, this is excactly the kind of thing I suggested for upload authentication without using client certificates.
Telling the user how to upload should be simple enough by putting a
Replace this page using gemini+(write|upload):// at the bottom of the page together with the Raw text link. The gemini specification already states that clients have to expect unknown uri schemes, and even the simplest clients should offer the option to copy an uri with an unknown scheme (That includes simply writing it on screen where the user can select and copy it).
– baschdel 2020-06-08 10:43 UTC
Ok, not exactly what I suggested, but for this wiki, with behaving users this implementation should be fine
– baschdel 2020-06-08 11:16 UTC