💾 Archived View for gemi.dev › gemini-mailing-list › 000047.gmi captured on 2023-12-28 at 15:40:21. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Greetings all, After today's change to the spec to introduce some new line types, I am announcing a three month spec freeze. I am happy to make small changes to correct typos, fixing inconsistencies or reduce ambiguities (and I have no doubt the latest change intorduced some of these things). But I will not make any substantive changes until June 1st 2020. The reason for this, as previously stated, is that I think in general we are doing far too much "designing in a vacuum". Designing protocols in the abstract on a mailing list is fun, but there will *always* be reasonable arguments for adding just one more thing. We'll never be finished and we'll move ever further away from the ethos that people should be realistically able to write their own feature-complete Gemini software in a weekend or two. I am strongly of the opinion that, now that we have defined something which is (hopefully!) manageably small and simple, we should build the best possible space we can within the limits that small and simple thing imposes, and then ask ourselves "are we content with this?". Not "wouldn't it be nicer if we also had X?", because of course it would, but "if this really were it, forever, would using this be genuinely unpleasant?". At this point I would really like to consider making changes if and only if they fix actual real-world problems which we can point at that are affecting multiple non-hypothetical servers or users. Right now there's just not enough stuff out there for this kind of "real world driven design" to happen, and until that changes I think our time is better used writing content than specs or code. Moving forward, I strongly advocate for a model something like: 1. INTERVAL = 3 months 2. Spend INTERVAL actually building Geminispace and associated tools, with no major spec changes. 3. Ask "What is the *single* biggest problem/shortcoming of the current spec, based on everything that has actually been done or been tried in the past INTERVAL?" 4. Possibly (but not necessarily) change the spec to address the answer to 3, if the problem is deemed bad enough and can be addressed without adding too much extra complexity. 5. Set INTERVAL = 2*INTERVAL 6. GOTO 2, or END. This way the protocol solidifies pretty rapidly, and all our attention is focussed on demonstrable problems, which are tackled in order of severity. This model strongly encourages solving most problems not through changes to the spec, which are precious rareties, but through extra layers of optional convention, e.g. defining well-known endpoints like robots.txt or sitemap.xml. This, in turn, minimises breakage of existing tooling. So, let's spend most of our Gemini energy until June on creating content and tools! In addition to finally starting some gemlogs, I still plan to prioritise the creation of an Atom-based aggregator to play the role of Bongusta for Geminispace. This, I hope, will encourage content creation by making new content easily discoverable. In Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog listing played a strong role in easy content discovery. Geminispace is still stuck with manually checking every known server every day to find infrequent updates, which is not something many people are going to want to do (even I quickly stopped doing it!). This discourages writing content, due to the feeling that it will never be seen. Fixing this is, I think, important. Cheers, Solderpunk
This kind of sork is like writing a book. It is always tempting to go back and revize and edit because yu are never happy eith it. As someone that is lookingto use this on api zero acting as a tinkerboxservet? I am lookingforward to the serverand client software that can be written jn this time now that the spec is at least momentarily in place. On Sun, Mar 1, 2020, 11:07 AM solderpunk <solderpunk at sdf.org> wrote: > Greetings all, > > After today's change to the spec to introduce some new line types, I am > announcing a three month spec freeze. I am happy to make small changes > to correct typos, fixing inconsistencies or reduce ambiguities (and I > have no doubt the latest change intorduced some of these things). But I > will not make any substantive changes until June 1st 2020. The reason > for this, as previously stated, is that I think in general we are doing > far too much "designing in a vacuum". > > Designing protocols in the abstract on a mailing list is fun, but there > will *always* be reasonable arguments for adding just one more thing. > We'll never be finished and we'll move ever further away from the ethos > that people should be realistically able to write their own > feature-complete Gemini software in a weekend or two. I am strongly of > the opinion that, now that we have defined something which is > (hopefully!) manageably small and simple, we should build the best > possible space we can within the limits that small and simple thing > imposes, and then ask ourselves "are we content with this?". Not > "wouldn't it be nicer if we also had X?", because of course it would, > but "if this really were it, forever, would using this be genuinely > unpleasant?". > > At this point I would really like to consider making changes if and > only if they fix actual real-world problems which we can point at that > are affecting multiple non-hypothetical servers or users. Right now > there's just not enough stuff out there for this kind of "real world > driven design" to happen, and until that changes I think our time is > better used writing content than specs or code. > > Moving forward, I strongly advocate for a model something like: > > 1. INTERVAL = 3 months > 2. Spend INTERVAL actually building Geminispace and associated tools, > with no major spec changes. > 3. Ask "What is the *single* biggest problem/shortcoming of the current > spec, based on everything that has actually been done or been tried > in the past INTERVAL?" > 4. Possibly (but not necessarily) change the spec to address the > answer to 3, if the problem is deemed bad enough and can be > addressed without adding too much extra complexity. > 5. Set INTERVAL = 2*INTERVAL > 6. GOTO 2, or END. > > This way the protocol solidifies pretty rapidly, and all our attention > is focussed on demonstrable problems, which are tackled in order of > severity. This model strongly encourages solving most problems not > through changes to the spec, which are precious rareties, but through > extra layers of optional convention, e.g. defining well-known endpoints > like robots.txt or sitemap.xml. This, in turn, minimises breakage of > existing tooling. > > So, let's spend most of our Gemini energy until June on creating > content and tools! In addition to finally starting some gemlogs, I > still plan to prioritise the creation of an Atom-based aggregator to > play the role of Bongusta for Geminispace. This, I hope, will encourage > content creation by making new content easily discoverable. In > Gopherspace, Bongusta and, before Bongusta existed, the SDF phlog > listing played a strong role in easy content discovery. Geminispace is > still stuck with manually checking every known server every day to find > infrequent updates, which is not something many people are going to want > to do (even I quickly stopped doing it!). This discourages writing > content, due to the feeling that it will never be seen. Fixing this is, > I think, important. > > Cheers, > Solderpunk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200301/0272 bfc9/attachment.htm>
Ahoy, As of yesterday, the freeze is over! The spec is now "liquid" once again. Many people involved in Gemini now were not here for the original freeze announcement, so I want to give this some context. The spec is now open to non-trivial changes again, but this is not a time to start suggesting new features "willy nilly". The idea behind the freeze was to give everybody the chance to build things, or try to build things, using the spec as it stood, so that at the end of the freeze we could make changes which solved actual concrete problems people had run into using Gemini in the real world. The idea is that we then fix those problems as best we can, and do another freeze. I want each freeze to last longer than the previous, and for the changes we make to get smaller and smaller each time. We should not expect any major changes and certainly no new totally new capabilities to enter the spec at this point. We are in the "polishing" phase. A lot happened during these last three months! Notably, Astrobotany appeared as the first non-trivial use of client certificates, revealing how poorly specced that whole thing was (and is). Non-English content appeared in Geminispace for the first time (and may much more follow!), prompting questions related to search and accessibility in a multilingual space. People started using pre-formatted lines in ways not conducive to search or accessibility, raising more questions on these topics. Plus a whole pile of tiny ambiguities or inconsistencies were spotted, many of which I pre-emptively cleaned up so that we could now focus on these bigger issues. No dout many more remain! I really think there is more than enough on our plate to deal with before announcing another freeze, so I'm not really looking for more suggestions on things to change. But if anybody thinks they see a real problem with the design of anything currently in the protocol, in principle now is the time to mention it. I will start making changes to the spec to fix the problems described above in the near future. I'm not sure when I will formally announce the next freeze, but I expect it to be in weeks, not days or months. As always I'll share my thoughts with the list and solicit feedback about proposed changes before making them official. Cheers, Solderpunk
> On Jun 2, 2020, at 21:26, solderpunk <solderpunk at SDF.ORG> wrote: > > As of yesterday, the freeze is over! The spec is now "liquid" once again. Cool. Can we remove things? :) ? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?). ? drop everything from text/gemini but text and link lines. Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. ? mandate >= TLS 1.3. Drop legacy support. Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation. In short, Mercury over TLS [1] :) Networking Truths #12 [2]: In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away. This would make Saint-Exup?ry proud. [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpunk /cornedbeef/the-mercury-protocol.gmi [2] https://tools.ietf.org/html/rfc1925 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/3d68 568c/attachment-0001.htm>
I am in favour of 1, but not 2 or 3. Regarding 1: Is there a valid usecase for serving non UTF-8 content? It is unlikely to be supported and should just be converted. But on the other hand, I don't feel like it's a huge issue if it's allowed. And `charset` is a part of the MIME media type anyway, so it's always valid. Regarding 2: I think that preformatted text lines are very important for rendering purposes and I would be sad to see them go. I don't feel strongly about list lines, but now that they're here it seems good to keep them. Regarding 3: Solderpunk has already indicated that this would be nice, but not all language libraries support it. I'd rather have TLS 1.2 still supported, so that all existing (and future) clients and servers can work. makeworld ??????? Original Message ??????? On Tuesday, June 2, 2020 3:57 PM, Petite Abeille <petite.abeille at gmail.com> wrote: > > On Jun 2, 2020, at 21:26, solderpunk <solderpunk at SDF.ORG> wrote: > > > > As of yesterday, the freeze is over! ?The spec is now "liquid" once again. > > Cool. Can we remove things? :) > > ??drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings.? > > Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?). > > ? drop everything from text/gemini but text and link lines. > > Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...).?text/gemini will not move the state of the art. Keep it simple. Less is more. > > ? mandate >= TLS 1.3. Drop legacy support.? > > Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation. > > In short, Mercury over TLS [1] :) > > Networking Truths #12 [2]: > > In protocol design, perfection has been reached not when thereis nothing left to add, but when there is nothing left to take away. > > This would make?Saint-Exup?ry proud. > > [1] https://portal.mozz.us/gemini/gemini.circumlunar.space/users/solderpu nk/cornedbeef/the-mercury-protocol.gmi > [2]?https://tools.ietf.org/html/rfc1925
Heya! > I am in favour of 1, but not 2 or 3. Everything makeworld said. +1 for (1) +1 for (2) -1 for (3) Note on (1): I strongly recommend supporting utf-8 only. iconv -l lists 1179 possible/known encodings. I don't want to support more than one in my code, most libraries don't support more than UTF-8, UTF-16, UTF-32 and ASCII. And for UTF-16 and UTF-32 not even a difference between little and big endian encoded data. Encoding is hell, enforcing UTF-8 solves this and is even ASCII compatible Regards - xq
> +1 for (2) So you're for Option 2 of what Abeille said? Could you elaborate on that? makeworld
On 02.06.20 22:25, colecmac at protonmail.com wrote: >> +1 for (2) > > So you're for Option 2 of what Abeille said? Could you elaborate on that? Maybe i'm just tired and/or distracted? Had a hard day. No, i'm against dropping headings and other formatting (really nice for outlining [0]). +1 for (1) -1 for (2) -1 for (3) Regards - xq [0] https://mq32.de/public/d6de3871ba066477b12a9e64411ea7308b31b8b4.png
On Tue, Jun 02, 2020 at 09:57:27PM +0200, Petite Abeille wrote: > > > > As of yesterday, the freeze is over! The spec is now "liquid" once again. > > Cool. Can we remove things? :) Yes, but not willy nilly. :) > ? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. > > Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?). Being "about the future" shouldn't mean "losing the ability to view the past". Clients are very explicitly permitted not to burden themselves with legacy charset conversions. From section 3.3: > Compliant clients MUST support UTF-8-encoded text/* responses. > Clients MAY optionally support other encodings. Clients receiving a > response in a charset they cannot decode SHOULD gracefully inform > the user what happened instead of displaying garbage. If the majority of clients don't support anything other than UTF-8 (which is likely, because adding support for other things is not fun, and many Gemini clients will be written for fun as small single-developer or small-team projects), this will exert a strong pressure for people to only author in UTF-8 (which is also very strongly encouraged in the Best Practices document that nobody reads), as well as motivate the inclusion of automatic transcoding in servers. > ? drop everything from text/gemini but text and link lines. > > Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. My biggest objection to this is the heading lines, which I actually don't see as fundamentally about formatting at all (although obviously clients
On Tue, Jun 02, 2020 at 10:14:59PM +0200, Felix Quei?ner wrote:
> I strongly recommend supporting utf-8 only.
Noted, but...
> I don't want to support more than one in my
> code
You don't have to! Support UTF-8 and you are spec compliant.
> most libraries don't support more than UTF-8, UTF-16, UTF-32 and
> ASCII.
Oh, now that can't be true. Loads of content produced on Windows
computers is saved in some silly legacy ISO-whatever encoding that
Microsoft refuses to drop. Any library used by working programmers
in the "real world" of commercial software needs to be able to deal
with that, at least.
> Encoding is hell
It's really not that bad at all in a situation, like Gemini (and
unlike Gopher!), where you get told precisely what the encoding is.
AV-98 does this:
---
if mime.startswith("text/"):
encoding = mime_options.get("charset", "UTF-8")
try:
body = body.decode(encoding)
except UnicodeError:
print("Could not decode response body using %s encoding declared
in header!" % encoding)
return
---
Hardly a nightmare!
Cheers,
Solderpunk
> On Jun 2, 2020, at 22:51, solderpunk <solderpunk at SDF.ORG> wrote: > > Hardly a nightmare! Because you have delegated it to a bazillion of python scripts behind the scene: #!/usr/bin/env python3 # AV-98 Gemini client Out of sight doesn't imply out of mind in this case.
Hi, just some comments from the peanut gallery.. Petite Abeille writes: > ? drop ;charset= from text/gemini content-type response. Everything is UTF-8. Gemini doesn't support legacy encodings. > > Rational: Clients shouldn't burden themselves with legacy charset conversions, which is finicky. Servers are better placed to normalize encoding if they must. Gemini is about the future, not the past (EBCDIC 273 anyone?). Clients don't have to implement any of these things. They can just refuse to serve non-utf8 content. But at lease I _know_ that I shouldn't try to render your koi8 page and can give a sensible reason why. Otherwise we're back to gopher, using guesswork and inference. > ? drop everything from text/gemini but text and link lines. > > Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. Ok, there goes ascii art from gemini. Seriously. This just forces me to choose between having prose rendered at a sensible width for reading or having nice art. Or having to implement more guesswork and inference. > ? mandate >= TLS 1.3. Drop legacy support. > > Rational: no point dragging the burden of the past into the future. Gemini innovative take on TLS deserves a modern foundation. Is this really necessary? What's so awesome about 1.3 from a layperson's perspective? I'm honestly asking, not just trying to be contrary. I worry this would increase the difficulty of complience without a real qualitative benifit. (Also, I think this would immediately break my server, so I'm biased. :-) ) plugd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/930b e09f/attachment.sig>
> On Jun 2, 2020, at 22:33, solderpunk <solderpunk at SDF.ORG> wrote: > > This quote has always been dear to my heart. :) Here is another one: ?The details are not the details; they make the product? -- Charles and Ray Eames
On 6/2/20 8:59 PM, plugd wrote: > ? drop everything from text/gemini but text and link lines. > > Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. I'll be that guy to step in here. As solderpunk mentioned, headings have semantic meaning, as do lists. These are not formatting features, although they can be styled by clients that want to be pretty. They provide structure and meaning to text documents which is invaluable for accessibility and alternative devices. We have also had a LOT of conversation on preformatted text to get where we are. There are some types of content which are impossible to implement without it. I don't see any of those things as extraneous features. They enable the text/gemini format to be what it is as much as links.
On Tue, Jun 02, 2020 at 10:59:23PM +0200, plugd wrote: > > Is this really necessary? What's so awesome about 1.3 from a > layperson's perspective? I'm honestly asking, not just trying to be > contrary. 1.3 drastically reduces the range of permissible cryptographic primitives which can be used. Instead of supporting dozens and dozens of different ciphersuites with opaque names ranging from "as secure as it gets" to "known to be broken for years", requiring careful configuration and implementation to avoid shooting yourself in the foot or being susceptible to downgrade attacks, 1.3 is basically foolproof. All the legacy cruft like RC4 is gone, every availble key agreement scheme offers perfect forward security, etc. It's definitely something to be excited about. Cheers, Solderpunk
> On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote: > > Is this really necessary? TLS in general? A minimum version of it? Not really. But mandating a secure channel of sort is value added. That said, mandating TLS only is perhaps counterproductive. After all, how do I run Gemini over wireguard now? With TLS on top? Because the spec forces me to? Oh, my... Perhaps Gemini should mandate a secure transmission channel, and then define a profile of it in the specification., say TLS vs TLS >= 1.3 vs wireguard vs whatnot.
On Tue, Jun 02, 2020 at 11:15:43PM +0200, Petite Abeille wrote: > That said, mandating TLS only is perhaps counterproductive. > > After all, how do I run Gemini over wireguard now? With TLS on top? Because the spec forces me to? Oh, my... If you run Gemini *without* TLS, how do you handle any of the status codes relating to client certificates? Cheers, Solderpunk
> On Jun 2, 2020, at 23:19, solderpunk <solderpunk at SDF.ORG> wrote: > > If you run Gemini *without* TLS, how do you handle any of the status > codes relating to client certificates? They are irrelevant. Or rather, for something like wireguard, imply running under 62 AUTHORISED CERTIFICATE REQUIRED or something. P.S. Off topic, but interesting, https://tailscale.com/blog/how-tailscale-works/
> On Jun 2, 2020, at 23:19, solderpunk <solderpunk at SDF.ORG> wrote: > > If you run Gemini *without* TLS, how do you handle any of the status > codes relating to client certificates? Actually, more specifically, the TLS related status code should be part of the TLS Gemini profile. Which would not be relevant for the WireGuard Gemini profile. Or such.
Another voice over here in against any suggestion to drop the frugal but useful heading and bullet structuring we have already. Having already implemented automatic table of contents in GemiNaut I can confirm it does give a usability boost when reading longer posts. It is very lightweight and zero burden for anyone who just wants to write a long essay. I think the current spec has it right. Utf 8 everywhere sounds good as a working principle. Maybe we can wait and see if there really is a widespread need for any other encodings. We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier. As for TLS versions, I don't have a strong opinion, except to say that implementing the normal case for the majority of content should be straightforward on the client and server side. Keep the complexity down as far as we can. Best wishes Luke > On 2 Jun 2020, at 22:11, James Tomasino <tomasino at lavabit.com> wrote: > >> On 6/2/20 8:59 PM, plugd wrote: >> ? drop everything from text/gemini but text and link lines. >> >> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. > > I'll be that guy to step in here. > > As solderpunk mentioned, headings have semantic meaning, as do lists. > These are not formatting features, although they can be styled by > clients that want to be pretty. They provide structure and meaning to > text documents which is invaluable for accessibility and alternative > devices. > > We have also had a LOT of conversation on preformatted text to get where > we are. There are some types of content which are impossible to > implement without it. > > I don't see any of those things as extraneous features. They enable the > text/gemini format to be what it is as much as links. >
It was thus said that the Great Felix Quei?ner once stated: > > I strongly recommend supporting utf-8 only. iconv -l lists 1179 > possible/known encodings. I don't want to support more than one in my > code, most libraries don't support more than UTF-8, UTF-16, UTF-32 and > ASCII. And for UTF-16 and UTF-32 not even a difference between little > and big endian encoded data. RFC-1436 (the gopher RFC) suggests ISO Latin1 (ISO-8859-1 if I'm not mistaken) for 8-bit character sets and says *nothing* about UTF-8 (of course, it was written before UTF-8 was an RFC, three years later). But most of the gopher sites I hit these days are UTF-8---it's rare that I actually encounter anything but UTF-8. Secondly, Linux systems come with iconv. Not only is this a program, but it's also a library which is dead simple to use as there are only three functions: iconv_t iconv_open(char const *tocode,char const *fromcode); size_t iconv(iconv_t cd,char **inbuf,size_t *inbytes,char **outbuf,size_t *outbytes); iconv_close(iconv_t cd); and that's *if* you want to support conversion. The world is migrating to UTF-8 so I think this will be that big of an issue in the long term. And in case anyone is curious, I found bindings for Lua Python Rust Go Haskell (no comment on how well these bindings work, just that they exist). -spc
It was thus said that the Great James Tomasino once stated: > We have also had a LOT of conversation on preformatted text to get where > we are. There are some types of content which are impossible to > implement without it. And you are not limited to just text/gemini. I know of one blog that is serving up text/markdown: gemini://alexschroeder.ch/ -spc (HTML is another option ... )
It was thus said that the Great Petite Abeille once stated: > > > > On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote: > > > > Is this really necessary? > > TLS in general? A minimum version of it? Not really. > > But mandating a secure channel of sort is value added. > > That said, mandating TLS only is perhaps counterproductive. > > After all, how do I run Gemini over wireguard now? With TLS on top? > Because the spec forces me to? Oh, my... Wireguard is a VPN implementation, not specifically a protocol. And as with other people who have questioned the use of TLS, show us an implementaion. Get a Gemini server working over wireguard. Or both wireguard *and* TLS. Because as it is, I have no idea how to go about this, nor any easy means to test it. > Perhaps Gemini should mandate a secure transmission channel, and then > define a profile of it in the specification., say TLS vs TLS >= 1.3 vs > wireguard vs whatnot. Again, the devil is in the details, and we need some more details about this. -spc (And then convince the gopher people who are working hard to get TLS working that *that* protocol ... )
It was thus said that the Great Martin Bays once stated: > * Tuesday, 2020-06-02 at 19:26 +0000 - solderpunk <solderpunk at SDF.ORG>: > > >But if anybody thinks they see a real problem with the design of > >anything currently in the protocol, in principle now is the time to > >mention it. > > One little thing that's bothered me ever since first reading the spec, > and which I can't see being discussed before (sorry if I missed it): > there seems to be no way to quote a line starting with "```". So for > example there's no way to present in a preformatted text block a gemini > document which contains "```" lines. I don't really have a horse in this race (I don't really care) but let me tell you about an interesting feature of Lua. Lua has three forms of strings. The first type is with the double quote: "This is a string.\n" The second form is with the single quote: 'This is also a string.\n' These types of strings allow certain characters to be escaped and are identical in nature, except that the double quote needs to be escaped in a string in double quotes, and the single quote needs to be escaped in a string in single quotes. The third type is what I want to talk about: [[ This too, is a string. ]] This type of string can expand beyond a single line, and it taken as-is. There is no escaping of characters though. So '\n' is NOT translated to the LF character. But there *is* a feature of these strings to include the '[[' and ']]' in the string being formed: [=[ This is a Lua string: [[This is a string.]] See? ]=] And if *that* needs to be quoted as a string? [==[ [=[ This is a Lua string: [[This is a string.]] See? ]=] ]==] And so on. The format is: '[' '='* '[' <data> ']' '='* ']' where the number of '=' match (not sure how to express that). I'm just throwing this out there. -spc
On 6/2/20 11:06 PM, Martin Bays wrote: > One little thing that's bothered me ever since first reading the spec, > and which I can't see being discussed before (sorry if I missed it): > there seems to be no way to quote a line starting with "```". So for > example there's no way to present in a preformatted text block a gemini > document which contains "```" lines. I just wrote a gemlog that was demonstrating the uses of ``` [1]. There's a much easier way to do it. Just add a space at the start. ``` ``` ``` As for lines starting with a magic string, you can just put them inside a preformatted block. ``` => gemini://linky.mcgoo ``` I'm holding out hope that the space after the ``` will be used for great purpose for accessibility. I think that's a much more productive direction than fringe cases of formatting. [1] gemini://tilde.black/users/fox/journal/20200601-accessibility.gmi
Petite Abeille writes: >> On Jun 2, 2020, at 22:59, plugd <plugd at thelambdalab.xyz> wrote: >> >> Is this really necessary? > TLS in general? A minimum version of it? Not really. Sorry, you're quoting me without context, which makes it sound like I was questioning whether TLS is necessary _at all_ - which I absolutely wasn't. My question was specific to the suggestion that TLS >= 1.3 be used. plugd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/b9f7 114a/attachment.sig>
Hey, solderpunk writes: > On Tue, Jun 02, 2020 at 10:59:23PM +0200, plugd wrote: > 1.3 drastically reduces the range of permissible cryptographic > primitives which can be used. Instead of supporting dozens and dozens > of different ciphersuites with opaque names ranging from "as secure as > it gets" to "known to be broken for years", requiring careful > configuration and implementation to avoid shooting yourself in the foot > or being susceptible to downgrade attacks, 1.3 is basically foolproof. > All the legacy cruft like RC4 is gone, every availble key agreement > scheme offers perfect forward security, etc. It's definitely something > to be excited about. Thank you for this clear explanation, this is very helpful! You've convinced me that requiring >= 1.3 would be a sensible move. plugd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/2137 73ee/attachment.sig>
On Tuesday 2 June 2020 23:44, Luke Emmet <luke.emmet at gmail.com> wrote: > We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier. I can't wait for UTF-8 art :-)
James Tomasino writes: > On 6/2/20 8:59 PM, plugd wrote: >> ? drop everything from text/gemini but text and link lines. >> >> Rational: The world has enough formatting options as it is. Everybody and their pet fish has their preferences (most posts on this list are about formatting...). text/gemini will not move the state of the art. Keep it simple. Less is more. > > I'll be that guy to step in here. I think you meant to reply to Petite Abeille - I was just quoting :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/ab10 f89e/attachment-0001.sig>
>> We can do ASCII art in Unicode - I don't get what the drive behind that remark was, mentioned earlier. > > I can't wait for UTF-8 art :-) Simply blockpixel UNICODE art: gemini://random-projects.net/ (shameless self-advertising)
> It was thus said that the Great Felix Quei?ner once stated: lul > Secondly, Linux systems come with iconv. Not only is this a program, but > it's also a library which is dead simple to use as there are only three > functions: Yeah, i know these bindings and i know that libiconv is a thing. It's still a dependency that *all* Gemini programs need to incorporate to be
On 6/3/20 11:40 AM, Felix Quei?ner wrote: > So, what you are saying is: > Most people already use utf-8, so there's no reason to enforce utf-8? > > I think it's even more an argument to enforce UTF-8. It makes the > software way simpler and less error pronce, reducing the possibilities > of attacks via badly implemented encodings and also reduces the risk of > il-translated and badly displayed text. > > Why drag a dependency on old cruft in when Gemini wants to be "as slim > as possible" and does not need to take care of "the old problems". I didn't have much skin in this discussion at the start, but the more I understand things the more I support enforcing UTF-8 in text/gemini. To be clear, though, we're talking specifically about text/gemini, right? Not text/*. Since text/gemini support is all that's minimally required for a client then only UTF-8 is minimally required for that format. If authors were to add support for wider mime types they could also add support for other encodings there. Or am I not following along properly?
? ? ??? ???
?? ?? ????? ????? ? ? ? ?? ??
?? ?? ? ? ? ??? ? ? ??? ???
? ? ? ????? ? ? ? ? ?
?? ?? ? ? ? ? ? ? ? ?
?? ?? ?????? ????? ??? ????? ? ?
Is it render properlly?
??????? Original Message ???????
On Wednesday 3 June 2020 13:33, Felix Quei?ner <felix at masterq32.de> wrote:
> > > We can do ASCII art in Unicode - I don't get what the drive behind
that remark was, mentioned earlier.
> >
> > I can't wait for UTF-8 art :-)
>
> Simply blockpixel UNICODE art:
> gemini://random-projects.net/
> (shameless self-advertising)
> To be clear, though, we're talking specifically about text/gemini, > right? Not text/*. Since text/gemini support is all that's minimally > required for a client then only UTF-8 is minimally required for that > format. If authors were to add support for wider mime types they could > also add support for other encodings there. Or am I not following along > properly? Yes, exactly. Enforce UTF-8 for text/gemini which makes implementing a minimal client that only supports utf-8, text/gemini and the gemini protocol very easy.
On 03/06/2020 14:18, Felix Quei?ner wrote: > > Yes, exactly. Enforce UTF-8 for text/gemini which makes implementing a > minimal client that only supports utf-8, text/gemini and the gemini > protocol very easy. > From the spec: If a MIME type begins with "text/" and no charset is explicitly given, the charset should be assumed to be UTF-8. Compliant clients MUST support UTF-8-encoded text/* responses.
Felix Quei?ner writes: > Simply blockpixel UNICODE art: > gemini://random-projects.net/ > (shameless self-advertising) Nice! Although I've gotta say that Quokka's capsule gemini://bleyble.com/users/quokka/ is still the coolest I've seen so far, with the text-based webcam gemini://bleyble.com/users/quokka/textcam/. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/1b49 4bf7/attachment.sig>
On Tue, Jun 02, 2020 at 08:53:51PM -0400, Sean Conner wrote: > And you are not limited to just text/gemini. I know of one blog that is > serving up text/markdown: > > gemini://alexschroeder.ch/ GUS can help with questions like these, FYI. In total, currently, there are 54 markdown pages in Geminispace (out of ~6000 pages). The blog you linked has the majority of markdown content currently in Geminispace, but there are 3 other domains serving markdown as well [0]. [0] gemini://gus.guru/search?content_type%3Amarkdown%20AND%20NOT%20domain%3Aalexschroeder (that query, without the url quoting, is "content_type:markdown AND NOT domain:alexschroeder") There's also the GUS statistics page [1], if you want an overview of all the content types, just note that it lags behind the true counts by a few days' worth of crawls for now, so its numbers can be slightly underrepresentative. [1] gemini://gus.guru/statistics
It was thus said that the Great Felix Quei?ner once stated: > > It was thus said that the Great Felix Quei?ner once stated: > > Secondly, Linux systems come with iconv. Not only is this a program, but > > it's also a library which is dead simple to use as there are only three > > functions: > > Yeah, i know these bindings and i know that libiconv is a thing. It's > still a dependency that *all* Gemini programs need to incorporate to be > *fully* compliant for displaying text/gemini files Yes, and because of the line breaking requirement of text/gemini, the Unicode Line Breaking Algorithm is *also* required---a nice document of 20,000 words: https://www.unicode.org/reports/tr14/ Your client does implement that, right? Also, what does your client do if it receives a BOM (byte order mark)? That's illegal in UTF-8. Also, what Unicode normalization forms does it support? What does it do when it encounters an illegal byte in the document? Or does it pass everything along to the operating system? > > RFC-1436 (the gopher RFC) suggests ISO Latin1 (ISO-8859-1 if I'm not > > mistaken) for 8-bit character sets and says *nothing* about UTF-8 (of > > course, it was written before UTF-8 was an RFC, three years later). But > > most of the gopher sites I hit these days are UTF-8---it's rare that I > > actually encounter anything but UTF-8. > > So, what you are saying is: > Most people already use utf-8, so there's no reason to enforce utf-8? Yes. > I think it's even more an argument to enforce UTF-8. It makes the > software way simpler and less error pronce, reducing the possibilities > of attacks via badly implemented encodings and also reduces the risk of > il-translated and badly displayed text. I don't agree fully, given some of my questions above. Also, do you filter out control sequences? MS-DOS supported control sequences to redefine the keyboard but I'm not sure if that is still the case with Windows. -spc
It was thus said that the Great Natalie Pendragon once stated: > On Tue, Jun 02, 2020 at 08:53:51PM -0400, Sean Conner wrote: > > And you are not limited to just text/gemini. I know of one blog that is > > serving up text/markdown: > > > > gemini://alexschroeder.ch/ > > GUS can help with questions like these, FYI. In total, currently, > there are 54 markdown pages in Geminispace (out of ~6000 pages). The > blog you linked has the majority of markdown content currently in > Geminispace, but there are 3 other domains serving markdown as well Since the following query isn't supported, could you check to see how many text/gemini documents have a charset? And if they do, what charset they use? -spc
plugd <plugd at thelambdalab.xyz> writes: > Petite Abeille writes: >> ? mandate >= TLS 1.3. Drop legacy support. >> >> Rational: no point dragging the burden of the past into the future. >> Gemini innovative take on TLS deserves a modern foundation. > > Is this really necessary? What's so awesome about 1.3 from a > layperson's perspective? I'm honestly asking, not just trying to be > contrary. I worry this would increase the difficulty of complience > without a real qualitative benifit. (Also, I think this would > immediately break my server, so I'm biased. :-) ) I think it would break my server, too. I'm using a library that supports 1.3, but my previous attempts to force it to use only 1.3 were unsuccessful. There are several benefits to TLS 1.3, though. There are fewer options, and thus fewer ways to mess up, and less legacy stuff to support. From an end-user perspective, the main benefit is 0-RTT session resumption. That's especially beneficial for us Geminauts, because we don't do connection keep-alive, and pay the price of a TLS negotiation every time. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada |
> On Jun 3, 2020, at 02:59, Sean Conner <sean at conman.org> wrote: > > Get a Gemini server working over wireguard. Or both wireguard *and* TLS. Wireguard [1] manifest itself as a network interface, so one can run anything over it without much fuss, e.g. curl --interface wg0 or such. No need to change anything. Rational: https://www.linode.com/community/questions/19107/using-wireguard-protocol-v s-individual-ssl-connection Or something like sshuttle is handy as well: https://github.com/sshuttle/sshuttle https://sshuttle.readthedocs.io/en/stable/usage.html [1] https://www.wireguard.com/quickstart/
> On Jun 3, 2020, at 09:01, plugd <plugd at thelambdalab.xyz> wrote: > > Sorry, you're quoting me without context Apologies. Brevity was too concise :)
> On Jun 3, 2020, at 14:29, plugd <plugd at thelambdalab.xyz> wrote: > > Nice! Although I've gotta say that Quokka's capsule > gemini://bleyble.com/users/quokka/ > is still the coolest I've seen so far, with the text-based webcam > gemini://bleyble.com/users/quokka/textcam/. Cool :) Random tools: jp2a : Converts jpg images to ASCII https://csl.name/jp2a/ https://github.com/cslarsen/jp2a And more: https://en.wikipedia.org/wiki/AAlib https://en.wikipedia.org/wiki/Libcaca Watch all of star wars in ASCII :D https://asciinema.org/a/8
> On Jun 3, 2020, at 14:41, Natalie Pendragon <natpen at natpen.net> wrote: > > [1] gemini://gus.guru/statistics Fabulous :) Thanks for such great resource.
> On Jun 3, 2020, at 18:14, Sean Conner <sean at conman.org> wrote: > > Yes, and because of the line breaking requirement of text/gemini, the > Unicode Line Breaking Algorithm is *also* required---a nice document of > 20,000 words: Stop scarring people! :D
> On Jun 3, 2020, at 20:25, mbays at sdf.org wrote: > > I do think that one way or another, it should be possible to represent any text line and any preformatted line in a gemini document. Mostly for theoretical neatness, but also for practical purposes -- e.g. precisely quoting a gemini document. Yes, one should be able to represent text/gemini in text/gemini. Say, for documentation purpose. Is there any escape character or such? E.g.: \=> \``` \# \* \\ -- escape the escape
On 6/3/20 7:16 PM, Petite Abeille wrote: > Yes, one should be able to represent text/gemini in text/gemini. Say, for documentation purpose. > > Is there any escape character or such? I would think that documenting text/gemini source in text/gemini would use the ``` block to do so. In which case, the only outlier is the ``` itself. I like a simple indenting here to get around the issue since it requires no work and is easy to discover with 5 minutes of trial and error. If that's too ugly, there's always the good old zero-width space for you crazy cats. https://en.wikipedia.org/wiki/Zero-width_space
> On Jun 3, 2020, at 21:32, James Tomasino <tomasino at lavabit.com> wrote: > > If that's too ugly, there's always the good old zero-width space for you > crazy cats. > https://en.wikipedia.org/wiki/Zero-width_space Ah, yes, another can of worms: Blacklisting in URLs ICANN rules prohibit domain names from including non-displayed characters such as zero-width space, and most browsers blacklist their use within domain names, because they can be used to create a homograph attack, where a malicious URL is visually indistinguishable from a legitimate one. http://kb.mozillazine.org/Network.IDN.blacklist_chars -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200603/d949 2f8a/attachment.htm>
Lets keep it simple please. Here are my 2p worth For any quoting of the special line prefixes: 1. put within a ``` section inside text/gemini 2. serve the content with text/plain then you can say what you want 3. for quoting ``` prefix with a space or intersperse with a space thus ` ` ` (or variant thereof) 4. Use a link to a text/plain or whatever other rich format text/gemini format does not have its own meta language in it. It is supposed to be simple, if you need something else, use something else zero width spaces and their ilk are horrible for many reasons, but security is a big one. Best wishes - Luke On 03-Jun-2020 20:43, Petite Abeille wrote: > > >> On Jun 3, 2020, at 21:32, James Tomasino <tomasino at lavabit.com >> <mailto:tomasino at lavabit.com>> wrote: >> >> If that's too ugly, there's always the good old zero-width space for you >> crazy cats. >> https://en.wikipedia.org/wiki/Zero-width_space > > Ah, yes, another can of worms: > > *Blacklisting in URLs > */ICANN rules prohibit domain names from including non-displayed > characters such as zero-width space, and most browsers blacklist their > use within domain names, because they can be used to create > a homograph attack, where a malicious URL is visually > indistinguishable from a legitimate one. > / > http://kb.mozillazine.org/Network.IDN.blacklist_chars >
On Wed, Jun 3, 2020, at 2:50 PM, Luke Emmet wrote: > Lets keep it simple please. Here are my 2p worth > > For any quoting of the special line prefixes: > > 1. put within a ``` section inside text/gemini > 2. serve the content with text/plain then you can say what you want > 3. for quoting ``` prefix with a space or intersperse with a space thus > ` ` ` (or variant thereof) > 4. Use a link to a text/plain or whatever other rich format > > text/gemini format does not have its own meta language in it. It is > supposed to be simple, if you need something else, use something else I agree with this. I can't think of a use-case where describing text/gemini formatting within a text/gemini document will need to be so flexible so that what Luke suggests won't work. Even if we implemented complex quoting rules, it's simply impossible to round-trip example documents in their own markup. Besides, I think marking examples with ``` is useful because it essentially quotes the enclosed content as an example, as opposed to actual content. If you want to copy-paste Gemini content easily, just don't filter the content before passing it on to the client. Maybe if a specific use-case could be given to where quoting would be important? ~ acdw
On Wed, Jun 03, 2020 at 12:32:23PM -0400, Sean Conner wrote:
> Since the following query isn't supported, could you check to see how many
> text/gemini documents have a charset? And if they do, what charset they
> use?
For all content types:
5529 - none
110 - utf-8
38 - us-ascii
2 - US-ASCII
1 - UTF-8
For text/gemini specifically:
3256 - none
14 - utf-8
2 - US-ASCII
1 - UTF-8
And now, in case you want to explore these data more on your own...
please be patient in case there are new bugs, but `charset` is now a
supported query filter in your own GUS searches. Consider it an early
access "beta" feature, because I still need to put more thought and
work into tokenization and indexing of the charset values. Feel free
to try it out though!
I'll also keep the aggregate counts on the statistics page [2] going
forward for easy reference.
[2] gemini://gus.guru/statistics
It was thus said that the Great Natalie Pendragon once stated: > On Wed, Jun 03, 2020 at 12:32:23PM -0400, Sean Conner wrote: > > Since the following query isn't supported, could you check to see how many > > text/gemini documents have a charset? And if they do, what charset they > > use? First off, thank you for this. > For all content types: > > 5529 - none > 110 - utf-8 > 38 - us-ascii > 2 - US-ASCII > 1 - UTF-8 Hmm ... because I know of *one* page that is text/gemini and is *not* UTF-8 encoded: gemini://gemini.conman.org/test/torture/0013 I'm guessing you don't crawl the Gemini Client Torture Test then? > For text/gemini specifically: > > 3256 - none > 14 - utf-8 > 2 - US-ASCII > 1 - UTF-8 What this tells me is that the fears of non-UTF-8 text/gemini pages are probably unfouned. For now. I'd recommend keeping the charset on text/gemini. For the exceeding rare case of a non-UTF-8 text/gemini page, a very simplistic client that doesn't want to convert the text can just report an error to the user, or at least offer an option to display and/or save the content. -spc
---
Previous Thread: [SPEC-CHANGE] Preformatted text, header and unordered list lines defined