💾 Archived View for gemi.dev › gemini-mailing-list › 000392.gmi captured on 2024-08-31 at 16:55:06. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Dioscuri is a protocol intended to supplement Gemini for doing things like uploading files, performing remote actions, and running an application server. It is the POST to Gemini's GET. Dioscuri servers will run on a different port altogether, so that they do not interfere with Gemini servers. Dioscuri, unlike Gemini, absolutely *requires* the use of client certificates. Great thanks to the members of irc://tilde.chat/gemini, especially lukee and aravk. The name "Dioscuri" is the Latinized spelling of the Greek name for the Heavenly Twins, Castor and Pollux/Polydeukes, who were called Gemini in Latin; the constellation is named after them. I say dee-OH-skoo-ree, but Greeks, classicists, and others should feel free to pronounce the name their way. ======= A Dioscuri request starts out with the client sending a single line, <URL><SP><MEDIA-TYPE><CR><LF>. This indicates that a body follows which should be interpreted according to the media type. For example, "gemini:// example.org/foo text/gemini\r\n" means that the Dioscuri server should do something with the following body, which is of type text/gemini. Exactly what happens depends on the server and the URL. For example, it might replace the contents of "foo" with the uploaded body. Alternatively, "gemini://example.org/do/this text/javascript\r\n" might cause the JavaScript in the uploaded body to be executed on the server. As a special case, a client can send a Dioscuri header without a media type or separating space, in which case no request body is allowed or expected. This can be used if the contents of the URL are sufficient to tell the server what to do. ======= When Dioscuri has received the header and body, then it does whatever it does and returns a regular Gemini header with some extensions. If the server is going to be conversational, it will process the uploaded body with whatever semantics it assigns to it and then send a regular Gemini response header. For example, an application server might be sent a header "<URL> application/json\r\n" followed by a JSON value, compute something, and return "20 application/json\r\n" followed by the computed JSON value. If the server has nothing to send to the client, as in the case of an upload, it can respond with "20\r\n", which means that there is no response body. ======= By mutual agreement between the client and the server, the server may return "70 <URL>\r\n" not followed by a body. This code means that the request has succeeded, but rather than the server sending a response body in the same TCP connection, the response body can be found at <URL>. A use case for this is that the client wishes to add a new file to a container (directory or whatever) in the server but leaves it up to the server to choose the new URL according to some algorithm (random, timestamp, etc.) So a request of "<container-URL> text/gemini\r\n" followed by the body would in such a case respond "60 <object-URL>\r\n", meaning that the new resource can be found at <object-URL>. All other 2-digit response codes have the same meaning in Dioscuri as in Germini. The reason for not using the 30 code in place of 60 is that 30 would mean "redirect the request", as for all other cases of 30, whereas 60 means "the response can be found here." I thought of using 21, but that would make the second status digit an essential part of the protocol. Note that like 2x, 6x is considered a success. ======= Finally, an implementation note: the TCP library used to implement Dioscuri clients must be able to separately close the input and the output sides of the TCP connection to the server. So in the application server discussed above, the client closes the output side of its socket when it has sent the body, and the server receives EOF when it attempts to read more body. However, the input side on the client must remain open so that the server's response can be read. Comments? John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org And it was said that ever after, if any man looked in that Stone, unless he had a great strength of will to turn it to other purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200927/1020 e3cd/attachment.htm>
John Cowan <cowan at ccil.org> writes: > A Dioscuri request starts out with the client sending a single line, > <URL><SP><MEDIA-TYPE><CR><LF>. This indicates that a body follows which > should be interpreted according to the media type. For example, "gemini:// > example.org/foo text/gemini\r\n" means that the Dioscuri server should do > something with the following body, which is of type text/gemini. Exactly > what happens depends on the server and the URL. For example, it might > replace the contents of "foo" with the uploaded body. Alternatively, > "gemini://example.org/do/this text/javascript\r\n" might cause the > JavaScript in the uploaded body to be executed on the server. Does Dioscuri have the same line-length limits as Gemini? > > By mutual agreement between the client and the server, the server may > return "70 <URL>\r\n" not followed by a body. This code means that the > request has succeeded, but rather than the server sending a response body > in the same TCP connection, the response body can be found at <URL>. > > A use case for this is that the client wishes to add a new file to a > container (directory or whatever) in the server but leaves it up to the > server to choose the new URL according to some algorithm (random, > timestamp, etc.) So a request of "<container-URL> text/gemini\r\n" > followed by the body would in such a case respond "60 <object-URL>\r\n", > meaning that the new resource can be found at <object-URL>. > Do you mean "70" here instead of "60"? > > Finally, an implementation note: the TCP library used to implement Dioscuri > clients must be able to separately close the input and the output sides of > the TCP connection to the server. So in the application server discussed > above, the client closes the output side of its socket when it has sent the > body, and the server receives EOF when it attempts to read more body. > However, the input side on the client must remain open so that the > server's response can be read. Are there any limits on payload length from the client? Are there any plans for the client to indicate to the server the length of the payload? What happens if the server encounters a fault while reading in the entire client payload? Is there any guidance on timeouts? Should implementors assume that timeouts are quick and the server should hangup quickly if nothing is found on the client's send stream, or is this application dependent so that it's up to the server/endpoint to determine timeouts (e.g. for a streaming application)? My worry is that opening connections to the server and keeping the server send connection open can quickly exhaust the number of sockets/fds the server has available. - meff
Complexity inside the server I don't particularly fear. My biggest fear for Gemini has been a proliferation of protocols. "Protocols" defined loosely, not just as foo:// but as whenever a computer asks something of another and expects a reply in a particular format. That fear was behind my hesitiation re codifying behavior in the alt text strings earlier. As for whatever a server does on its own, I leave great allowance. Requests being files in a file system or routes in an MVC. But when two computers talk to each other, that's the point when two giant spinning spheres of grinding greebles speeding through space need to make contact. Need to get on the same page on what they are doing. We'll look back years from now when gemspace collective standards have a complexity that overshadows that of the W3C specifications, and maybe we'll recognize that this moment, this post was the Rubicon. Maybe we'll think that the Pandora lid was already peeked through to the point of no salvation, since an arbitrary sequence of GET requests could become a protocol. Even if the future disastrous level of complexity is inevitable, I'm not convinced it needs to be parallel. When we are proposing protocols that could already be done through existing standards (such as https) I ask that there is very good reason why. "Oh, it's chill, any particular client and any particular server can use this for ANY semantics" only makes me more concerned, since it's the foundation for a hundred hundreds of protocols. I see how we want [comments, posting, uploading, interaction, talking] between the clients and the server. The equiv of "textarea" and dinky li'l radio buttons, and POST requests are necessary for that. But where are the fences? Slippery slope? More like abyss sans railing. Sometimes there IS very good reason to scrap and start over. To voluntarily do a https://imgs.xkcd.com/comics/standards.png because you have experience with possible use cases, good and bad, and you know how to implement a simpler, coherent solution to sit beside the palimpsest of wire hangers and chewing gum that preceded and inspired it. Starting a new pile of junk next to the old pile of junk because you've started having a hard time finding things in the old pile will ultimately just leave you with two piles of junk. The question raised by this isn't just "why Dioscuri?" It's "why should we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz for this problem?" That isn't rhetorical. There could be good answers. I just can't think of them. The road to reckless complexity is spelled NIH with a ribbon bookmark.
It was thus said that the Great Sandra Snan once stated: > We'll look back years from now when gemspace collective standards have a > complexity that overshadows that of the W3C specifications, and maybe > we'll recognize that this moment, this post was the Rubicon. Maybe we'll > think that the Pandora lid was already peeked through to the point of no > salvation, since an arbitrary sequence of GET requests could become a > protocol. Nope. The Rubicon was passed earlier this year with talk of the titan: protocol which allowed people to upload content to a Gemini server and has already been implemented by at least one Gemini server. Just go to this link: https://lists.orbitalfox.eu/archives/gemini/2020/thread.html and search for "titan". You'll find the threads. Also search for the thread "Uploading Gemini Content". Again, you'll find the threads. What I find sad is that this appears to be separate approach from the titan: proposal, which either means the designers of this were not aware of of the previous work, or have rejected the previous work for some unstated reason---I'm hoping it's the former. > The question raised by this isn't just "why Dioscuri?" It's "why should > we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz > for this problem?" That isn't rhetorical. There could be good answers. I > just can't think of them. Again, check the history of this list. It has been discussed before. -spc (Who fears that no one realizes that links to the mailing list archives are sent in the headers to every message ... )
In which case please reapply my rant to _that_ Rubicon Sean Conner <sean at conman.org> writes: > It was thus said that the Great Sandra Snan once stated: >> We'll look back years from now when gemspace collective standards have a >> complexity that overshadows that of the W3C specifications, and maybe >> we'll recognize that this moment, this post was the Rubicon. Maybe we'll >> think that the Pandora lid was already peeked through to the point of no >> salvation, since an arbitrary sequence of GET requests could become a >> protocol. > > Nope. The Rubicon was passed earlier this year with talk of the titan: > protocol which allowed people to upload content to a Gemini server and has > already been implemented by at least one Gemini server. Just go to this > link: > > https://lists.orbitalfox.eu/archives/gemini/2020/thread.html > > and search for "titan". You'll find the threads. Also search for the > thread "Uploading Gemini Content". Again, you'll find the threads. > > What I find sad is that this appears to be separate approach from the > titan: proposal, which either means the designers of this were not aware of > of the previous work, or have rejected the previous work for some unstated > reason---I'm hoping it's the former. > >> The question raised by this isn't just "why Dioscuri?" It's "why should >> we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz >> for this problem?" That isn't rhetorical. There could be good answers. I >> just can't think of them. > > Again, check the history of this list. It has been discussed before. > > -spc (Who fears that no one realizes that links to the mailing list > archives are sent in the headers to every message ... )
Sandra Snan <sandra.snan at idiomdrottning.org> writes: > "Oh, it's chill, any particular client and any particular server can use > this for ANY semantics" only makes me more concerned, since it's the > foundation for a hundred hundreds of protocols. I strongly agree with you. IMO, we should resist the temptation to make Gemini a general-purpose application platform, and the like temptation to build a general purpose application platform alongside it. I prefer the idea of writing protocols that are specific to applications (or classes of applications). A protocol for email; a protocol for message boards; a protocol for file transfer. And a proliferation of both clients and servers for each protocol. The use of HTTP for everything has led to every site being an incompatible siloed application... I'll save the rest of the rant for a gemlog post. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
On Sun, Sep 27, 2020 at 9:59 PM Meff <meff at meff.me> wrote: > Does Dioscuri have the same line-length limits as Gemini? > Yes. That means that you can't have quite as long an URL as in Gemini. However, I suspect few people will do Gopher/Gemini-style searches through Dioscuri. Do you mean "70" here instead of "60"? > I picked 70 more or less at random, then went back and saw that 5x is the highest Gemini status code, so I'll go with 60. I didn't quite consummate the change. > Are there any limits on payload length from the client? No, any more than there are limits on payload length from the server in Gemini (or Dioscuri). > Are there any > plans for the client to indicate to the server the length of the > payload? That's the point of the one-sided close. If we had to batch requests on the same TCP connection, Content-Length would be indispensable, but as things stand, closing the write side of the socket conveys that information. > What happens if the server encounters a fault while reading in > the entire client payload? > That's pretty vague: what kind of a fault? The safe answer for the server is "Close the connection", at which point the client will figure out (after TCP timeout) that the request didn't work and apply its general policy (abort, retry, or ignore) for such events. > Is there any guidance on timeouts? Should implementors assume that > timeouts are quick and the server should hangup quickly if nothing is > found on the client's send stream, or is this application dependent so > that it's up to the server/endpoint to determine timeouts (e.g. for a > streaming application)? The latter, I think. The Gemini protocol definition mentions timeouts only in connection with CGI. > My worry is that opening connections to the > server and keeping the server send connection open can quickly exhaust > the number of sockets/fds the server has available. > With the Internet the way it is, servers must be written to defend themselves against both intentional and unintentional attacks in any case. But the difference between use and abuse depends on the use. Sockets can equally be overwhelmed by a Gemini attack. DDOS protection helps here. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/1af6 7ced/attachment.htm>
On Mon, Sep 28, 2020 at 3:15 AM Sean Conner <sean at conman.org> wrote: Nope. The Rubicon was passed earlier this year with talk of the titan: > protocol which allowed people to upload content to a Gemini server and has > already been implemented by at least one Gemini server. You could with equal justice say that publishing Gemini crossed the Rubicon, since I would certainly never have thought of Dioscuri without first hearing of Gemini (and being fascinated, since it was clearly a very nice extension of Gopher's ideas, which I have always loved). > What I find sad is that this appears to be separate approach from the > titan: proposal, which either means the designers of this were not aware of > of the previous work, or have rejected the previous work for some unstated > reason---I'm hoping it's the former. > I wrote down an early version of Dioscuri when I had barely heard of Titan. Later, #gemini pointed me to Titan and I looked at it. I wasn't able to find a protocol description and had to reverse engineer it from the Bash code, but it seemed to me that it was too limited: it provided upload only, rather than a conversational protocol like I wanted in which responses were symmetrical with requests. So I have not so much rejected Titan as decided that my goals were sufficiently different. > > The question raised by this isn't just "why Dioscuri?" It's "why should > > we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz > > for this problem?" That isn't rhetorical. There could be good answers. I > > just can't think of them. > (S)FTP was in fact part of the inspiration for Dioscuri, but I wanted something much similar. My earlier version of D. had GET/PUT/POST/DELETE verbs and the possibility of extensions, but #gemini participants convinced me that POST was sufficient, provided three cases were well handled: (a) no request body (b) no response body (c) the ability to respond with an URL rather than an anonymous body. I think I have done that. JSON, XML, and S-expressions are formats and are all fine: I mentioned JSON for familiarity, but exchanging information in .INI file format is perfectly fine (and in fact it can be made isomorphic with XML). Above all, DIoscuri is both simple and general. That's not an easy target to hit, and it's clear to me that Gemini has hit it. I might quibble about some details, but I won't. I have done my best to hit the (slightly different) target too. Again, check the history of this list. It has been discussed before. > I read through as much of this year's archives as I could, and I haven't seen anything bidirectional like this. Please point me to appropriate emails if there are any. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org He who would do good to another must do it in Minute Particulars; General Good is the plea of the scoundrel, hypocrite and flatterer: For Art and Science cannot exist but in minutely organized Particulars. --William Blake, il miglior fabbro -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/9c15 807f/attachment.htm>
On Mon, 28 Sep 2020, Jason McBrayer wrote: > IMO, we should resist the temptation to make Gemini a general-purpose > application platform, and the like temptation to build a general purpose > application platform alongside it. The ease and enjoyment of creating a reasonably good server or client for the Gemini protocol/format has led to perhaps more clients and servers than we need; a positive consequence has been to increase the amount of caution with which spec changes are now approached. I think however there is a negative consequence: attention is diverted from complementary aspects of the Gemini ecosystem, namely Gemini-native content itself, and the tooling connected with it, such as distribution, discovery and syndication tools. If there were a simple, fun standard/spec for some aspect of these tools, that might attract the same useful energy as the Gemini spec itself does. (As indicated above, I am pretty sceptical about additional Gemini-adjacent protocols as such) Mk
> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote: > > I read through as much of this year's archives as I could, and I haven't seen anything bidirectional like this. Please point me to appropriate emails if there are any. > Look for inimeg (gemini spelled backward :P, circa June '00, re: gemini+submit:// (was Re: Uploading Gemini content ) )
Martin Keegan <martin at no.ucant.org> writes: > I think however there is a negative consequence: attention is diverted from > complementary aspects of the Gemini ecosystem, namely Gemini-native content > itself, and the tooling connected with it, such as distribution, discovery and > syndication tools. If there were a simple, fun standard/spec for some aspect of > these tools, that might attract the same useful energy as the Gemini spec itself > does. Yeah, I think there's potentially a lot to be done here. Even just some examples, like a desktop app that lets you write and publish a journal with no server knowledge. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
> On Sep 28, 2020, at 6:09 AM, Martin Keegan <martin at no.ucant.org> wrote: > > On Mon, 28 Sep 2020, Jason McBrayer wrote: > >> IMO, we should resist the temptation to make Gemini a general-purpose >> application platform, and the like temptation to build a general purpose >> application platform alongside it. > > The ease and enjoyment of creating a reasonably good server or client for the Gemini protocol/format has led to perhaps more clients and servers than we need; a positive consequence has been to increase the amount of > caution with which spec changes are now approached. > > I think however there is a negative consequence: attention is diverted from complementary aspects of the Gemini ecosystem, namely Gemini-native content itself, and the tooling connected with it, such as distribution, discovery and syndication tools. If there were a simple, fun standard/spec for some aspect of these tools, that might attract the same useful energy as the Gemini spec itself does. I think a lot of us would rather work on Gemini things rather than served-up-over-Gemini things. Might be a pent-up-demand kind of thing. (says the guy who?s splitting his time between a static-gemlog generator and actually writing stuff for his capsule when he really should just do the latter)
Jason McBrayer <jmcbray at carcosa.net> writes: > IMO, we should resist the temptation to make Gemini a general-purpose > application platform, and the like temptation to build a general purpose > application platform alongside it. The good old days when we had separate apps for everything was paradise for me, and, well, still is because I can still happily live in that world in my li'l Debian bubble. You've seen me rant against web apps before, for example on here: https://github.com/w3c/web-share/issues/173 But it was not easy for most people to ./configure, make, make install things. Using web apps is something they can do. As an example, email exploded once web-interfaces to email became available. If Gemini and adjacent protocols turn into a general-purpose application platform, there need to be some sort of purpose or guiding light or boundaries or reason for starting a new pile instead of working on the already existing pile of junk. Dioscuri doesn't have a client-side, server-served programming language. Such things are the cause of a lot of the web's problems so that's not what I'm proposing, but, the consequence of _not_ having it means that every Dioscuri?app needs to have its own implementation. Talk about complexity in the client! With SSH I can have an app on the remote and call it from my client. ssh some-server-name 'ls|tail' The SSH client doesn't need to know or implement the semantics of ls or tail. With Dioscuro, there is a lot of responsibilty for both sides to be on the same page with regards to semantics. Sandra PS. Here's an idea, in the mindset of green hat "thinking out loud":
Sandra Snan <sandra.snan at idiomdrottning.org> writes: > The following is not gonna sound retro, but? if parts of the page > could update without reloading the entire page, that'd go a long way > to alleviate a lot of people's desire for JavaScript, AJAX etc. One > button, one checkbox, one text field etc could be sent without having > to send the entire form, and one local UI area could be updated > without having to refetch the entire page. You might be interested in looking at intercooler.js (https://intercoolerjs.org/) and HTMX (https://htmx.org/), which implement this pattern in the browser. Of course, browsers don't natively support HTMX, so it's written in JavaScript; but a browser
June '00? Wow, I was later to the Gemini party than I thought. Sandra PS I feel bad for shooting down Dioscuri so harshly, I hate being such a parade-rainer. jcowan is one of my idols Petite Abeille <petite.abeille at gmail.com> writes: >> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote: >> >> I read through as much of this year's archives as I could, and I haven't seen anything bidirectional like this. Please point me to appropriate emails if there are any. >> > > > Look for inimeg (gemini spelled backward :P, circa June '00, re: gemini+submit:// (was Re: Uploading Gemini content ) )
On Wed, Sep 30, 2020 at 12:14 PM Sandra Snan <sandra.snan at idiomdrottning.org> wrote: > The good old days when we had separate apps for everything was paradise > for me, and, well, still is because I can still happily live in that > world in my li'l Debian bubble. > I live in that world too. But there are only a few of them: ftp, ssh and friends, mail, etc. I have no trouble learning them all. But they are very inconsistent, much like Posix command-line tools. > As an example, email exploded once web-interfaces to email became > available. > I'm not sure if you think that's good or bad. See < http://www.catb.org/jargon/html/S/September-that-never-ended.html>. > If Gemini and adjacent protocols turn into a general-purpose application > platform, there need to be some sort of purpose or guiding light or > boundaries or reason for starting a new pile instead of working on the > already existing pile of junk. > Well, why work on Gemini instead of just using HTML and HTTP? Simplicity Gemini and text/gemini are simple enough without being too simple. I believe that Dioscuri is too. > Dioscuri doesn't have a client-side, server-served programming language. > There's no reason Gemini can't ship JavaScript, or Scheme for that matter. "JavaScript: The Good Parts" actually describes a very nice little language. Talk about complexity in the client! With SSH I can have an app on the > remote and call it from my client. > > ssh some-server-name 'ls|tail' > Yes, you can, but the server is at risk if it allows you to ssh and run arbitrary shell commands. Posix systems are better defended than most, but the firewall is far from complete.
---
Previous Thread: Ditch URL. Uniform Resource Names ftw!
Next Thread: [ANN] gemini-php: A Gemini server written in PHP