New user, spec details

Hi! I?ve been browsing the Gemini space for about a week and so far I love it! I just fired up my own server and intend to contribute to the content soon. I also skimmed the mailing list and there are still a few details of the spec I would like to discuss: First, in the overview of the transaction (#1.1), it appears to me that the client must wait for the server to close the connection before doing anything with the response. It seems to be an unnecessary constraint, especially since the text/gemini format is designed to be handled line by line without needing to store the whole document. It would also enable rendering of progressive images, playing audio files, etc during the transfer. In the same section, as well as #3.3 Response bodies, it is stated that the server closes the connection after the document is sent. I think it would be interesting to be a little more precise and state that the server sends a close_notify from the TLS layer before closing the connection. It would make it possible for clients to detect a truncated download and warn the user about it. I would also like to know the general opinion about TLS session caches. It could be used as a light tracking tool? but I don?t think it?s that bad. IP address and requests timing can also be used in the same way to track users on a single server. And if someone really wanted, they could just serve unique URLs to each visitor to track their movements on their server.

On Fri, 17 Jul 2020 21:39:16 +0200 kooda at upyum.com wrote: > It seems to be an unnecessary constraint, especially since the > text/gemini format is designed to be handled line by line without > needing to store the whole document. It might make more sense if you thought of a gemini document as an atomic object. Accessing a Gemini document is a four step process: 1. Connect 2. Download 3. Disconnect 4. Render > It would also enable rendering of progressive images, > playing audio files, etc during the transfer. If I cared about rendering images inline, streaming audio, etc. I would stick to the HTML/CSS/JS web stack. Gemini is mainly text-oriented, remember? > It could be used as a light tracking tool? but I don?t think > it?s that bad. I disagree with you. Tracking is too easily abused, as we've seen with the WWW over the last twenty-five years or so. > IP address and requests timing can also be used in the > same way to track users on a single server. And if someone really > wanted, they could just serve unique URLs to each visitor to track > their movements on their server. If I want the WWW, I know where to find it. I participate in geminispace to get away from the downsides of the WWW, and that includes the ability to track people as they visit sites and pages. -- Matthew Graybosch https://matthewgraybosch.com #include <disclaimer.h> gemini://starbreaker.org gemini://tanelorn.city "Out of order?! Even in the future nothing works."

> On Jul 17, 2020, at 23:48, Matthew Graybosch <hello at matthewgraybosch.com> wrote: > > 1. Connect > 2. Download > 3. Disconnect > 4. Render More simply, when appropriate: 1. Connect 2. Render 3. Disconnect

??????? Original Message ??????? On Friday 17 July 2020 21:39, <kooda at upyum.com> wrote: > the client must wait for the server to close the connection before doing > anything with the response. It seems to be an unnecessary constraint, > especially since the text/gemini format is designed to be handled line by > line without needing to store the whole document. It would also enable > rendering of progressive images, playing audio files, etc during the > transfer. Agreed. It will be usefull when gemini documents will be more then >1KB The important thing is one document per connection, no automatic downloading. FreD.