πΎ Archived View for gemi.dev βΊ gemini-mailing-list βΊ 000592.gmi captured on 2024-08-19 at 01:18:33. Gemini links have been rewritten to link to archived content
β¬ οΈ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi, I recently gathered TLS-related statistics on Gemini servers, using a few shell scripts and OpenSSL. You'll find everything here: https://gitlab.com/nervuri/gemini-stats Among other things, the repo contains:
> * 66 certs are signed by Let's Encrypt > * 35 pass OpenSSL validation > * 359 fail OpenSSL validation (not signed by a trusted CA, expired, etc) 66 is more Let's Encrypt certs than I would have guessed. For better or worse, they seem a bit out of place in gemini. When I was setting up my server, I was almost going to use my Let's Encrypt cert, but I'm glad I didn't. The Let's Encrypt method is antithetical to the TOFU model of certs. Using a trusted CA is irrelevant and regularly updating your certs (often a month in advance of expiry) is not good with TOFU. > * 3 : Not After 9999 I wish I had gone this way. I think with TOFU this is the only sane way (essentially same as ssh host keys). ~Stephen
> * 40 support TLSv1.1 > * 39 support TLSv1.0 This was the most surprising/concerning part to me. These servers are breaking the spec, and my understanding is that TLS 1.0 is considered insecure by experts. I'm less sure about how insecure 1.1 is, but I know that it's deprecated in all main browsers by now. Do you have any idea what server software is allowing this? Maybe you can look at the capsules, as some will say what software they use. That way someone can file a bug or submit a patch/PR. makeworld
December 30, 2020 7:19 PM, Stephen wrote: > 66 is more Let's Encrypt certs than I would have guessed. What's strange to me is that 31 of those fail validation. It might be interesting to see why. By the way, Lupa lists 68 Let's Encrypt certs: gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi Also, Lupa knows about 528 hosts, more than GUS's 442. I wish it listed them. > For better or worse, they seem a bit out of place in gemini. When I was setting up my server, I was almost going to use my Let's Encrypt cert, but I'm glad I didn't. The Let's Encrypt method is antithetical to the TOFU model of certs. Using a trusted CA is irrelevant and regularly updating your certs (often a month in advance of expiry) is not good with TOFU. There is value in a third party attesting that a specific cert belongs to a specific domain. I would like a Gemini browser to do TOFU for self-signed certs and normal validation for CA-signed certs - and let me know when I'm dealing with the latter. There is more to say on this, I might elaborate at some point. December 30, 2020 7:44 PM, colecmac wrote: > Do you have any idea what server software is allowing this? Maybe you can look at the capsules, as some will say what software they use. That way someone can file a bug or submit a patch/PR. This kind of thing will always be an issue. The barrier to entry is low, so we can expect problematic server implementations to keep popping up. I did check out *.lanterne.chilliet.eu and it looks like it's using a self-made server written in PHP. I'll submit an issue one of these days, if someone doesn't do it before me. gemini://gemlog.lanterne.chilliet.eu/softwares.en.gmi https://framagit.org/MCMic/gemini-server As for the others... here are the hosts: ``` cat data/tls/tls-versions | grep tls1_1 cadence.moe | -tls1_2 -tls1_1 -tls1 code.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1 consensus.circumlunar.space | -tls1_2 -tls1_1 -tls1 cyberpunksin.space | -tls1_3 -tls1_2 -tls1_1 -tls1 dioskouroi.xyz | -tls1_2 -tls1_1 -tls1 ftrv.se | -tls1_3 -tls1_2 -tls1_1 -tls1 gem.johanbove.info | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini-textboard.fgaz.me | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.cycrad.io | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.sirodoht.com | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.slashdev.space | -tls1_2 -tls1_1 -tls1 gemini.thebackupbox.net | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.thegonz.net | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.ucant.org | -tls1_2 -tls1_1 -tls1 gemini.uxq.ch | -tls1_3 -tls1_2 -tls1_1 -tls1 gemini.uxw.ch | -tls1_3 -tls1_2 -tls1_1 -tls1 gemlog.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1 gsthnz.com | -tls1_3 -tls1_2 -tls1_1 -tls1 hacktivis.me | -tls1_3 -tls1_2 -tls1_1 -tls1 happycreature.org | -tls1_3 -tls1_2 -tls1_1 -tls1 heavysquare.com | -tls1_3 -tls1_2 -tls1_1 -tls1 houston.coder.town | -tls1_3 -tls1_2 -tls1_1 -tls1 iim.gay | -tls1_3 -tls1_2 -tls1_1 -tls1 jfh.me | -tls1_2 -tls1_1 -tls1 kamalatta.ddnss.de | -tls1_2 -tls1_1 -tls1 kwiecien.us | -tls1_3 -tls1_2 -tls1_1 -tls1 lord.re | -tls1_3 -tls1_2 -tls1_1 -tls1 nixo.xyz | -tls1_3 -tls1_2 -tls1_1 -tls1 ols.wtf | -tls1_3 -tls1_2 -tls1_1 -tls1 posixcafe.org | -tls1_2 -tls1_1 -tls1 rainbow-100.com | -tls1_3 -tls1_2 -tls1_1 -tls1 rocketnine.space | -tls1_3 -tls1_2 -tls1_1 -tls1 rwv.io | -tls1_3 -tls1_2 -tls1_1 -tls1 saintnet.tech | -tls1_3 -tls1_2 -tls1_1 -tls1 sanctum.geek.nz | -tls1_2 -tls1_1 -tls1 sdf.org | -tls1_3 -tls1_2 -tls1_1 -tls1 stanner.bayern | -tls1_3 -tls1_2 -tls1_1 -tls1 thebackupbox.net | -tls1_3 -tls1_2 -tls1_1 -tls1 tictactoe.lanterne.chilliet.eu | -tls1_2 -tls1_1 -tls1 trfs.me | -tls1_3 -tls1_2 -tls1_1 tweek.zyxxyz.eu | -tls1_3 -tls1_2 -tls1_1 -tls1 twins.rocketnine.space | -tls1_3 -tls1_2 -tls1_1 -tls1 typed-hole.org | -tls1_2 -tls1_1 -tls1 vignette.kalasarn.se | -tls1_3 -tls1_2 -tls1_1 -tls1 ```
> On Dec 30, 2020, at 23:15, nervuri <nervuri at disroot.org> wrote: > > This kind of thing will always be an issue. The barrier to entry is low, so we can expect problematic server implementations to keep popping up. First off, very nicely done, thank you for sharing. A server linter would be a great little project indeed. Something along the lines of Mark Nottingham 's REDbot*, but for Gemini.
It was thus said that the Great colecmac at protonmail.com once stated: > > * 40 support TLSv1.1 > > * 39 support TLSv1.0 > > This was the most surprising/concerning part to me. These servers are > breaking the spec, and my understanding is that TLS 1.0 is considered > insecure by experts. I'm less sure about how insecure 1.1 is, but I know > that it's deprecated in all main browsers by now. > > Do you have any idea what server software is allowing this? Maybe you can > look at the capsules, as some will say what software they use. That way > someone can file a bug or submit a patch/PR. The server software and the TLS library would be nice. My own server, <gemini://gemini.conman.org/> is running GLV-1.12556, written in Lua, and using LibreSSL (specifically because it comes with libtls, a sane TLS wrapper around the rest of LibreSSL). It could very well be a limitation of the TLS library itself. -spc
On 12/30/20 5:18 PM, Sean Conner wrote: > My own server, > <gemini://gemini.conman.org/> is running GLV-1.12556, written in Lua, and > using LibreSSL (specifically because it comes with libtls, a sane TLS > wrapper around the rest of LibreSSL). It could very well be a limitation of > the TLS library itself. Looks like LibreSSL has support as of May 2020 [1]. [1] https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.2.0-relnotes.txt
It was thus said that the Great nervuri once stated: > > As far as I know, with TLSv1.2 client certs are sent in the clear, > revealing login information to the ISP (and whoever else is looking). In > this respect, when used with TLS 1.2, client certs are worse than cookies. I currently log client certificates (gasp!). Yes, it's true, but I added such logging last year when the protocol was still in the intial stages of development and I wanted a way to debug client certificate issues. I have an area that requires client certificates but it doesn't get a lot of traffic. But, just bacause I'm feeling ornery about this, here are the details of the few client certs that have crossed my server over the past month (the subject): /CN=elpherAyKLzp /CN=default /CN=My Cert /C=CH/ST=Some-State/O=Internet Widgits Pty Ltd /CN=testuser /C=US/ST=FL/L=Boca Raton/CN=Sean Conner/emailAddress=sean at conman.org and except for that last one (what a stupid git, giving out his name and email address like that!), the issuer was also the same as the subject. Yeah, way worse than cookies I'd say. > Also, 1.2 isn't compatible with encrypted SNI. So I hope it will be phased > out soon, if possible. Let me know your thoughts. Sigh. Given the current state of Gemini, *even if* the domain name were encrypted, there's still a near 80% chance of knowing which domain is being accessed, just because most servers only serve one domain. And there is
December 30, 2020 11:53 PM, Sean Conner wrote: > I currently log client certificates (gasp!). That's different from what I was referring to. You're not a third party, you're supposed to receive that information. The problem with client certs + TLS 1.2 is that any third party on the network route can also see that information. When I log into a web forum over https using cookies, my ISP doesn't see what user I log in as. But when I log into a gemini forum using a client cert, my ISP does - and, as you point out, may even see the email address I used. However, that problem goes away with TLS 1.3. > Given the current state of Gemini, *even if* the domain name were encrypted, there's still a near 80% chance of knowing which domain is being accessed, just because most servers only serve one domain. I went from 394 to 258 hosts after eliminating subdomains (like all those
December 31, 2020 11:34 AM, nervuri wrote: > 45% improvement I meant 35%.
It was thus said that the Great nervuri once stated: > December 30, 2020 11:53 PM, Sean Conner wrote: > > When I log into a web forum over https using cookies, my ISP doesn't see > what user I log in as. But when I log into a gemini forum using a client > cert, my ISP does - and, as you point out, may even see the email address > I used. However, that problem goes away with TLS 1.3. Okay, point taken. > > Given the current state of Gemini, *even if* the domain name were > > encrypted, there's still a near 80% chance of knowing which domain is > > being accessed, just because most servers only serve one domain. > > I went from 394 to 258 hosts after eliminating subdomains (like all those > *.flounder.online vhosts). So it's about 65%, rather than 80%. A 45% > improvement is nothing to scoff at. > > But even if in 100% of cases there was a 1-to-1 mapping from domain to IP > address, encrypted SNI still raises the bar, as the watchers on the > network route need to do more work to find the domain - they don't simply > get it when inspecting network traffic. Especially since, with SNI, you > can't always find a domain if all you have is its IP address. For example, > let's take 107.5.198.24 - tell me what Gemini domain is hosted there > without looking at the data I gathered. If you find out, tell us how. I threw the IP address into the almighty Google. The third result (for me, your results may vary as this is Google) was to this link: https://lists.sr.ht/~emersion/alps-dev/%3C20200625175005.52130-1-zdecook%4 0ccel.org%3E/raw which showed me that Zach DeCook sent a patch to the ALPS development list originating from said IP address. The domain of his email address, ccel.org, did not show anything related to Gemini, but throwing his name into the almighty Google brought me to his homepage: https://zachdecook.com/ where at the bottom, you can see the link to his Gemini site, which has the IP address 107.5.198.24. Yes, that's a bit of work, but it was less than 5 minutes, and I'm not even a state actor here. Is that enough of a bar for you? -spc
Le mercredi 30 d?cembre 2020, 23:15:11 CET nervuri a ?crit : > I did check out *.lanterne.chilliet.eu and it looks like it's using a self-made server written in PHP. I'll submit an issue one of these days, if someone doesn't do it before me. > > gemini://gemlog.lanterne.chilliet.eu/softwares.en.gmi > https://framagit.org/MCMic/gemini-server Hey, that one is mine. Indeed I use STREAM_CRYPTO_METHOD_TLS_SERVER which means any TLS version. I can switch to STREAM_CRYPTO_METHOD_TLSv1_2_SERVER but I was afraid this would forbid TLS 1.3. I see a STREAM_CRYPTO_METHOD_TLSv1_3_SERVER in the PHP code but not in the documentation :-( Which means I need to investigate PHP git history to check when this constant was added and whether I can use it as-is. Relevant part of my code: gemini://code.lanterne.chilliet.eu/vendor/mcmic/gemini-server/src/Server.ph p (A fragment here would be handy to point the exact line, but I think no gemini clients support fragments? Here it?s not even text/plain but text/x-php so not sure what should be used?) C?me
December 31, 2020 9:45 PM, Sean Conner wrote: > Okay, point taken. Because of this privacy issue, I think browsers should only send client certificates over TLS 1.3 (and newer). This could be part of the spec. We could also make a coordinated effort to help Gemini software support TLS 1.3 - reach out, send patches, see what's holding developers back. Currently LibreSSL, GnuTLS and wolfSSL all support TLS 1.3, so most (if not all) browsers/servers/proxies/crawlers could probably make the upgrade. Once enough software supports 1.3 and enough servers have switched, the minimum TLS version can be changed in the spec. > Yes, that's a bit of work, but it was less than 5 minutes, and I'm not even a state actor here. Is that enough of a bar for you? SNI-based surveillance is automatable, making it trivial for third parties to hoard this data at nearly no cost. Even a tiny bit of non-automated work, like what you just did, will deter many (mostly commercial) actors involved in mass surveillance, for whom scalability is what makes it worthwhile. When it comes to targeted surveillance done by state actors, ESNI won't help much (if at all), but this threat model doesn't apply to most people. Let's not fall for the perfect solution fallacy. Looks like ESNI is being superseded by Encrypted Client Hello (ECH): https://tools.ietf.org/html/draft-ietf-tls-esni-08 https://blog.cloudflare.com/encrypted-client-hello/ Nice.
January 1, 2021 2:49 PM, C?me Chilliet wrote: > Hey, that one is mine. Oh, hello! :) There's an easy fix. I'll reply to you privately, I don't think people on this list are interested in PHP code.
Hello, Just recently I was creating a Gemini mirror of an HTTP site, and came across several pages that made heavy use of tables. I did what I suspect most Gemini publishers/content authors do: use ASCII tables, like so: +--------------------------------+-------+ | Food | Price | +--------------------------------+-------+ | Eggs | $2 | | Eggs and spam | $4 | | Eggs, spam, eggs and spam | $8 | | Spam spam baked beans and spam | $8 | | Just spam | $2 | +--------------------------------+-------+ There are several problems with this approach, though: 1. It requires the client to display the table in a monospaced font, which many would prefer not to use. 2. Text in table rows won't be wrapped properly on narrow displays. 3. ASCII tables are anything but screenreader friendly, since there's no semantic information about the table's structure. 4. It mixes information and presentation, which is against the spirit of Gemini(?) So, are there any other options for having tables in Gemtext, other than adding a new syntax to the spec? I'm hard pressed to think of another solution. Regards, --- kiedtl
> 1. It requires the client to display the table in a monospaced font, > which many would prefer not to use. > 2. Text in table rows won't be wrapped properly on narrow displays. If you put your table in a preformatted block, then a monospaced font and not wrapping are required by the spec, and so are a non-issue. All the tables I've seen are in preformatted blocks, and I would consider anyone not doing that to be making a mistake, for the very reasons you've written above. > 3. ASCII tables are anything but screenreader friendly, since there's no > semantic information about the table's structure. Yes, that's the main problem in my opinion. I don't see a great solution really. Perhaps if the word table is in the alt text (an unofficial idea, which is the text right after the first backtick line), a really good client could interpret where the cells are and read them? It would be error-prone of course, and still not very accessible. > 4. It mixes information and presentation, which is against the spirit of > Gemini(?) The point of preformatted blocks is to control presentation in the specific cases where it's needed, like code, ASCII art, or I guess tables. While in general you're right, I think there is sort of a "precedent" for this mixing. > So, are there any other options for having tables in Gemtext You could create a CSV or HTML file and link to it? Other than that I'm not sure, I don't see an easy solution to this. > adding a new syntax to the spec I doubt this will happen, gemtext is pretty set right now. And the ability to parse tables would go against its idea of clients only needing to look at the first three characters. Cheers, makeworld
On Sat Jan 2, 2021 at 4:36 AM UTC, makeworld wrote: > > 1. It requires the client to display the table in a monospaced font, > > which many would prefer not to use. > > 2. Text in table rows won't be wrapped properly on narrow displays. > > If you put your table in a preformatted block, then a monospaced font and not > wrapping are required by the spec, and so are a non-issue. All the tables I've > seen are in preformatted blocks, and I would consider anyone not doing that to > be making a mistake, for the very reasons you've written above. Yes, that's the point. If I have my client configured to use a variable-width font, I don't think I'd enjoy having just tables being in a monospace font. > > adding a new syntax to the spec > > I doubt this will happen, gemtext is pretty set right now. Just for the record, this was not what I was advocating. > And the ability to parse tables would go against its idea of clients only needing > to look at the first three characters. Not necessarily. Something like scdoc's [0] table syntax [1] could be used: =[ Foo =: Bar =: =| Row 1 =: Hello =: world! =| Row 2 =: Hello =: universe! Unfortunately, such a solution means that the table syntax would be unreadable without further processing, which is also against the spirit of Gemtext(?) Anyways. Back to ASCII art, I suppose. [0]: https://git.sr.ht/~sircmpwn/scdoc [1]: See scdoc(5) --- kiedtl "This, too, shall pass."
It was thus said that the Great Ki?d Llaentenn once stated: > Hello, > > Just recently I was creating a Gemini mirror of an HTTP site, and came > across several pages that made heavy use of tables. I did what I suspect > most Gemini publishers/content authors do: use ASCII tables, like so: > > +--------------------------------+-------+ > | Food | Price | > +--------------------------------+-------+ > | Eggs | $2 | > | Eggs and spam | $4 | > | Eggs, spam, eggs and spam | $8 | > | Spam spam baked beans and spam | $8 | > | Just spam | $2 | > +--------------------------------+-------+ > > There are several problems with this approach, though: > > 1. It requires the client to display the table in a monospaced font, > which many would prefer not to use. > 2. Text in table rows won't be wrapped properly on narrow displays. > 3. ASCII tables are anything but screenreader friendly, since there's no > semantic information about the table's structure. > 4. It mixes information and presentation, which is against the spirit of > Gemini(?) > > So, are there any other options for having tables in Gemtext, other than > adding a new syntax to the spec? I'm hard pressed to think of another > solution. There's not much choice you have in this matter. I use preformatted blocks for HTML tables, you can see two examples of which here: gemini://gemini.conman.org/boston/2020/12/28.1 The format I use works because I only use HTML tables for actual tabular data and *not* for layout purposes. The output uses tabs (HT, or character 9) between each field. The <caption> becomes the first line; the <thead> (table header) is followed by a line of dashes; any <tfoot> section will appear at the bottom of the table, again separated by dashes. I don't bother with any further decorations (like you have) because I don't feel its necessary (and if a cut-n-paste keeps the tab characters, it becomes rather easy to manipulate the data). -spc
<colecmac at protonmail.com> wrote: > > 3. ASCII tables are anything but screenreader friendly, since there's no > > semantic information about the table's structure. > > Yes, that's the main problem in my opinion. I don't see a great solution > really. > Perhaps if the word table is in the alt text (an unofficial idea, which is > the > text right after the first backtick line), a really good client could > interpret > where the cells are and read them? It would be error-prone of course, and > still > not very accessible. > Unofficial? It's in section "5.4.3 Preformatting toggle lines" in the spec. The proper way to use alt text in this case is to describe the information in the table as if you are talking to someone on the phone, essentially duplicating the information in prose. This can get tedious in big tables. For simple two column tables, you could replace them with lists. -- Katarina -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210102/cddc 3b12/attachment.htm>
On Sat, Jan 02, 2021 at 03:04:21AM +0000, Ki?d Llaentenn wrote: > Hello, > > Just recently I was creating a Gemini mirror of an HTTP site, and came > across several pages that made heavy use of tables. I did what I suspect > most Gemini publishers/content authors do: use ASCII tables, like so: [...] > 1. It requires the client to display the table in a monospaced font, > which many would prefer not to use. > 2. Text in table rows won't be wrapped properly on narrow displays. > 3. ASCII tables are anything but screenreader friendly, since there's no > semantic information about the table's structure. FWIW org-mode (a software for Emacs) deals very well with table like you wrote in your message (navigation, narrowing, it even include spreadsheet features!). :) So i guess a sufficiently smart client ;-) could parse and manage text table very well! :) Bye! C.
On Sat Jan 2, 2021 at 9:19 AM UTC, cage wrote: > So i guess a sufficiently smart client ;-) could parse and manage text > table very well! :) That's true. But that would work only if there was some consensus on how such ASCII tables are to be formatted, then. We can't reasonably expect even the smartest of clients to be able to parse the myriad of different table styles in use today :^) --- kiedtl "This, too, shall pass."
On 02-Jan-2021 03:04, Ki?d Llaentenn wrote: > Just recently I was creating a Gemini mirror of an HTTP site, and came > across several pages that made heavy use of tables. I did what I suspect > most Gemini publishers/content authors do: use ASCII tables, like so: > > +--------------------------------+-------+ > | Food | Price | > +--------------------------------+-------+ > | Eggs | $2 | > | Eggs and spam | $4 | > | Eggs, spam, eggs and spam | $8 | > | Spam spam baked beans and spam | $8 | > | Just spam | $2 | > +--------------------------------+-------+ > > There are several problems with this approach, though: > > 1. It requires the client to display the table in a monospaced font, > which many would prefer not to use. > 2. Text in table rows won't be wrapped properly on narrow displays. > 3. ASCII tables are anything but screenreader friendly, since there's no > semantic information about the table's structure. > 4. It mixes information and presentation, which is against the spirit of > Gemini(?) > > So, are there any other options for having tables in Gemtext, other than > adding a new syntax to the spec? I'm hard pressed to think of another > solution. Some other ideas: If you want to present the information in its original structure, there are other options (as well as trying to inline it into gemtext preformatted text already discussed on this thread): 1. provide link to a CSV 2. serialise as simple text 3. If you just want to preserve the visual appearance, you could also provide a link to a rendered PDF For option 2, most tables can be "flattened" in a way that users can usually get the idea of that was there. In my own html2gmi app [1] it has this as an option for processing tables as well as the "preformatted text layout": ? table ? Food Price Eggs $2 Eggs and spam $4 Eggs, spam, eggs and spam $8 Spam spam baked beans and spam $8 Just spam $2 Works fine for your table above IMHO. Or you could use some similar variant approach of this. I grant you this won't help for complex tables, but for those your options are limited apart from option 1 and 3 if you want to keep the full original appearance or structure. - Luke [1] https://github.com/LukeEmmet/html2gmi
On Sat, Jan 02, 2021 at 12:46:57PM +0000, Ki?d Llaentenn wrote: > On Sat Jan 2, 2021 at 9:19 AM UTC, cage wrote: > > So i guess a sufficiently smart client ;-) could parse and manage text > > table very well! :) > > That's true. But that would work only if there was some consensus on how > such ASCII tables are to be formatted, then. We can't reasonably expect > even the smartest of clients to be able to parse the myriad of different > table styles in use today :^) Good point! :-D :-D I fear we should wait for skynet for correct ascii table parsing! ;-D Bye! C.
On Sat, Jan 02, 2021 at 06:13:45PM +0000, Luke Emmet wrote: > On 02-Jan-2021 03:04, Ki?d Llaentenn wrote: > > Just recently I was creating a Gemini mirror of an HTTP site, and came > > across several pages that made heavy use of tables. I did what I suspect > > most Gemini publishers/content authors do: use ASCII tables, like so: > > > > +--------------------------------+-------+ > > | Food | Price | > > +--------------------------------+-------+ > > | Eggs | $2 | > > | Eggs and spam | $4 | > > | Eggs, spam, eggs and spam | $8 | > > | Spam spam baked beans and spam | $8 | > > | Just spam | $2 | > > +--------------------------------+-------+ > > > > There are several problems with this approach, though: > > > > 1. It requires the client to display the table in a monospaced font, > > which many would prefer not to use. > > 2. Text in table rows won't be wrapped properly on narrow displays. > > 3. ASCII tables are anything but screenreader friendly, since there's no > > semantic information about the table's structure. > > 4. It mixes information and presentation, which is against the spirit of > > Gemini(?) > > > > So, are there any other options for having tables in Gemtext, other than > > adding a new syntax to the spec? I'm hard pressed to think of another > > solution. > Some other ideas: > > If you want to present the information in its original structure, there are > other options > (as well as trying to inline it into gemtext preformatted text already > discussed on this thread): > > 1. provide link to a CSV We should try to use what we have before designing a new gemtext feature. Lagrange provides a way to create scripts which handle MIME types lagrange which are not supported by lagrange natively. We can use this to render CSV: ~/.config/lagrange/mimehooks.txt: CSV tables text/csv /bin/sh;/home/user/bin/csv2txt ~/bin/csv2txt: #!/bin/sh printf "20 text/plain\r\n" /bin/column -s, -t Don't forget to make this script executable. Now, test how well it works: gemini://gempaper.strangled.net/experiments/ubuntu-versions.csv picture: https://ttm.sh/dvO.png This is obviously not optimal:
On Wed, Dec 30, 2020 at 11:19:22AM -0800, Stephen <stephen at drsudo.com> wrote a message of 18 lines which said: > 66 is more Let's Encrypt certs than I would have guessed. For better > or worse, they seem a bit out of place in gemini. When I was setting > up my server, I was almost going to use my Let's Encrypt cert, but > I'm glad I didn't. The Let's Encrypt method is antithetical to the > TOFU model of certs. This is one of the weaknesses of the current spec (and why I think it is far from finished). Using a CA like Let's Encrypt is not forbidden but there is no detail about how it goes with TOFU. For instance, when a certificate (or key?) changes, is it TOFU-OK if it is signed by a recognized CA?
On Wed, Dec 30, 2020 at 10:15:11PM +0000, nervuri <nervuri at disroot.org> wrote a message of 55 lines which said: > Also, Lupa knows about 528 hosts, more than GUS's 442. I wish it > listed them. But only 449 working (at least one successful connect) so the numbers are not so different. lupa=> SELECT name FROM Capsules where lastsuccessfulconnect IS NULL; ... invalid.invalid gemini.example example.com ... black6kfjetfuzaeozz7fs53whh7xtd4e27telrf5fg5kgdt5ah5plad.onion ... ?.? Some of the non-working capsules come from examples, some from the darknet :-) and some were juste malformed links.
> On Jan 3, 2021, at 16:14, Stephane Bortzmeyer <stephane at sources.org> wrote: > > how it goes with TOFU Trust on first use (TOFU) has been waved as a talisman meant to absolve Gemini from actually defining it. What does TOFU means for Gemini, in practice? Gory, precise details wanted. https://en.wikipedia.org/wiki/Trust_on_first_use ? ???
> On Jan 3, 2021, at 00:25, Paper <paper at tilde.institute> wrote: > > Lagrange provides a way to create scripts which handle MIME types lagrange > which are not supported by lagrange natively. We can use this to render CSV: Clever. You could even do it inline, in one go, curtesy of the data URI scheme. ? For example, given a data encoded text/csv link: => data:text/csv;1997%2CFord%2CE350 table A smart client could render the above as a table, inline, without further ado. No need to expend gemini/text further, as it's already infinitely expendable today. ? ??? ? https://en.wikipedia.org/wiki/Data_URI_scheme
> On Jan 2, 2021, at 04:04, Ki?d Llaentenn <kiedtl at tilde.team> wrote: > > 4. It mixes information and presentation, which is against the spirit of > Gemini(?) Hmmm? If anything, gemini/text is... purely about information? Put another way, text/gemini has no control over presentation. None. Presentation is the remit of the user-agent, the client. The only escape hatch is the pre-formatted block, ala ```, which is meant to be rendered 'as-is', in monospace fonts. Therefore the endless overloading of that construct for many exotic purposes. 5.4.4 Preformatted text lines "Preformatted text lines should be presented to the user in a "neutral", monowidth font without any alteration to whitespace or stylistic enhancements." But of course, we also have links. Links can be resolved, and rendered, in any creative way a smart client sees fit. For example, an embedded text/csv, encoded as a data link, could be rendered in place into a beautiful looking table by the discerning user-agent: => data:text/csv;1997%2CFord%2CE350 Table Caption ? ???
> On Jan 3, 2021, at 20:50, Petite Abeille <petite.abeille at gmail.com> wrote: > > No need to expend gemini/text further, as it's already infinitely expendable today. Damn you autocorrect. ? ???
> On Jan 2, 2021, at 04:04, Ki?d Llaentenn <kiedtl at tilde.team> wrote: > > I'm hard pressed to think of another > solution. Automation? https://ozh.github.io/ascii-tables/ https://github.com/ozh/ascii-tables ? ???
Ki?d Llaentenn <kiedtl at tilde.team> writes: > So, are there any other options for having tables in Gemtext, other > than adding a new syntax to the spec? I'm hard pressed to think of > another solution. Remember that not everything has to be inline. Images aren't inline in gemtext, and tables are a lot like images. In my opinion, the most Gemini way of presenting a table is a link to a text/csv document. -- +-----------------------------------------------------------+ | 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 |
It looks like no one has mentioned box-drawing characters yet, they look good, are supported as part of UTF-8, and I suspect they'd be easy to parse. ``` ???????????????? ? Text ? goes ? ???????????????? ? in ? these ? ???????????????? ``` There are other styles that would need to be accounted for, like ``` ???????? ? Bold ? ???????? ``` or ``` ?????????? ? Double ? ?????????? ``` borders. => https://en.wikipedia.org/wiki/Box-drawing_character#Unicode More information about box drawing characters
> On Jan 4, 2021, at 16:00, A. E. Spencer-Reed <easrng at gmail.com> wrote: > > It looks like no one has mentioned box-drawing characters yet, they > look good, are supported as part of UTF-8, See ? ascii-tables ? Output Style ? Unicode (single line): https://ozh.github.io/ascii-tables/ ? ???
> On Jan 4, 2021, at 15:23, Jason McBrayer <jmcbray at carcosa.net> wrote: > > Remember that not everything has to be inline. Images aren't inline in > gemtext, and tables are a lot like images. Even though they could be inlined, using data: links. For example, a SVG image, data: encoded, could be rendered inline by a smart client: => data:image/svg+xml;%3Csvg%20height%3D%22100%22%20width%3D%22100%22%3E%3C circle%20cx%3D%2250%22%20cy%3D%2250%22%20r%3D%2240%22%20stroke%3D%22black%2 2%20stroke-width%3D%223%22%20fill%3D%22red%22%2F%3E%3C%2Fsvg%3E image caption Same, but base64 encoded: => data:image/svg+xml;base64,PHN2ZyBoZWlnaHQ9IjEwMCIgd2lkdGg9IjEwMCI+PGNpcm NsZSBjeD0iNTAiIGN5PSI1MCIgcj0iNDAiIHN0cm9rZT0iYmxhY2siIHN0cm9rZS13aWR0aD0iM yIgZmlsbD0icmVkIi8+PC9zdmc+ image caption ? ???
Jason McBrayer jmcbray at carcosa.net writes:
> Remember that not everything has to be inline. Images aren't inline in
> gemtext, and tables are a lot like images. In my opinion, the most
> Gemini way of presenting a table is a link to a text/csv document.
+1
As a bonus the user could configure a program to handle CSVs/TSVs that
best fit their needs. Some clients may choose to display inline like
others said.
As another bonus, the table is ready to be used by anyone who wants to
programmatically manipulate it, without any preprocessing.
-gk.
On Thu, 22 Apr 2021 at 09:17, GΓΆktuΔ Kayaalp <self@gkayaalp.com> wrote: > > Jason McBrayer jmcbray at carcosa.net writes: > > Remember that not everything has to be inline. Images aren't inline in > > gemtext, and tables are a lot like images. In my opinion, the most > > Gemini way of presenting a table is a link to a text/csv document. > > +1 > > As a bonus the user could configure a program to handle CSVs/TSVs that > best fit their needs. Some clients may choose to display inline like > others said. > > As another bonus, the table is ready to be used by anyone who wants to > programmatically manipulate it, without any preprocessing. > A big YES to something simple like *SV, only use more advanced stuff if you absolutely need to. I don't want anyone to go through the pains I have gone through getting garbled Microsoft tables and just plain weird table abuse into a usable format. -Oliver Simmons
---