💾 Archived View for bbs.geminispace.org › u › halscode › 20461 captured on 2024-12-17 at 15:03:00. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
First off I really don't like the use of a binary format. I see why you did it and I think it's too much. It requires a specialized tool to edit, so editing out of band via SSH, (S)FTP, or similar won't work.
It's... well it is its own protocol, I guess. It has its own goals and if it achieves those, well that's great! Simplicity is obviously not one of them.
The big ol' text file the spec is in is difficult for me to read. I think it's mostly between me and the way it's structured, but your first language isn't English, is it? I see mentions of TRON-8, which is quite an unconventional encoding that my brief googling indicates is a CJK-oriented encoding, and calling ruby text "furigana," which is a Japanese-specific term. So I'm not the target audience for this protocol. That's good to know, it wasn't very appealing to me.
It might benefit everyone to know what the actual goals of the protocol are; i.e. what is it made for, who is its target audience, what kinds of ideas do you want to adopt and avoid, etc.
Okay so what I'm gathering is that Scroll is built by a blind person, so the protocol and its corresponding text format are designed with screen readers and Braille devices as its target audience of clients. Honestly, more things need to be done that way. I do see a few things in the spec that make sense from that point of view, and others that don't.
Why are we expected to categorize our pages like it's a library? That seems a little excessive, and not useful as part of a response -- it might make sense in a directory though.
The language selection feature feels like it violates the value of simplicity, but honestly it's for a good cause. Automatic language selection would probably be a wise idea. I know how hard it is to navigate webpages and gempages in a language I don't know nor recognize. I can only imagine how bad it is for users of screen readers, which might not even know what language it's supposed to be speaking. This makes it a lot easier all around.
I don't like the way the metadata fields are presented. They seem more or less mandatory, which isn't great for things like index or home pages. The selection of fields is, well it's alright, but there's no room for change here.
I don't see it in the current version of the spec but I heard there was a separate request for metadata/abstract, which. Let's not do any extraneous requests, please and thanks. It should maybe be handled a bit differently.
I'm glad you picked UTF-8 for the protocol instead of a regional encoding like ASCII or TRON-8. UTF-8 is a good trusty international encoding.
I am thinking of "solving" some of the problems I find with Gemini, with a respectfully disagreeing approach.
One of these is Astral Markdown, which will be something between Markdown/Commonmark and Gemtext. As it's just a document type, it should be fully usable with Gemini, Scroll, maybe Scorpion, and a lot of others.
Another spec I want to develop an implementation for is Theme Packs. I already wrote the first-draft spec of it, targeted for Lagrange; theme packs will let you set site display names (maybe even a tagline), a seed color palette, a custom emoji favicon, and maybe even a menu-bar. It can apply up to the domain name or authority level, or down to specific pages or directories, such as tildes or CGI programs (i.e. Gemipedia). I'm thinking about both the main (TOML?) version and a ZIP version that contains several that can be downloaded and applied in bulk. I think this works somewhat well with the Gemini ethos as it's fully opt in and manually accessed. Once it's downloaded, that version keeps getting used until you go and update it (this should be the same behavior as Lagrange's existing font packs system).
Oct 06 · 2 months ago · 👍 clseibold
🚀 clseibold · Oct 06 at 05:38:
Sorry, I probably wasn't clear about when I talked about screen readers before. I'm not blind, I just think accessibility is important (although I'm sure there's a lot more work to do in regards to accessibility both for scroll and my software). Just wanted to clarify that.
The design goals of Scorpion are mentioned in the FAQ sections near the end. Note that many of the features are optional (or are not applicable for some uses), so is not required to implement it (I tried to be clear which features are optional; if it is unclear then you can make suggestion to improve it). (This is also true of Gemini and Scroll; some features are optional there too.) Simplicity is one of them (it is especially meant to be simpler than the complicated mess of WWW), although there are certain balances that must be made; to avoid being too simple or too complicated and to consider which features are important vs which are not as important.
Although the file format of Scorpion is a binary format, this is meant to simplify parsing it rather than editing it (like I mentioned, there is the balance of what simplicity and minimalism something is; one thing will complicate another thing, etc). However, I did write a program that can create it from a text file (allowing conversion from other character encodings (such as EUC-JP and EUC-CN), and allowing preprocessing, and other features that do not appear in the output), so that is one way to make up such a file if you want to do. An editor could also be made, I suppose. Other ways would also be possible.
The use of the word "furigana" and of TRON character encoding does not mean that it can only be used with Japanese; it is meant to be usable for other languages as well (and there is some consideration for other languages too, e.g. text direction of Hebrew and Arabic text). And, I am not actually Japanese, but I know a few things about Japanese (which is why I used the word "furigana", and other considerations relating to Japanese). Furthermore, my opinion is that Unicode is messy and is rather complicated and not really that good anyways. (I also think that it is not appropriate to use one character set for everything; many people think they do but there is many reason why the requirements are different for different uses.) (Han unification is an actual criticism of Gemini that I had seen, although it is an uncommon one.)
About Scroll, note that I get a NXDOMAIN error when trying to access it directly, so I have read a archived version, which might not be the latest version. The archived version I have read does have a separate request for metadata/abstract, and that is something that Gopher+ also does. I also think the categorization of the pages like a library is also doesn't make much sense to me, either.
About "Astral Markdown", you can make up your own specification and then we can see what it is and we can make some comments about it. Since it is a file format, probably it can be used with any protocol that can use any file format (there are possibilities that it would do something unusual that make it difficult, but such a thing is unlikely), including Gemini, Scroll, Scorpion, and HTTP, although of course the specifications of those protocols do not expect clients to implement it, nevertheless it is possible to do so. (The optional conversion file feature of Scorpion makes it potentially possible that even a browser that does not understand Astral Markdown might nevertheless be able to display it anyways, although a browser might not support the conversion file, and even if it does, it will require the user to download and install (and possibly configure) the conversion file.)
About "Theme Packs", it is possible. We will see what you will write, and make a comment of it. (I had thought of something similar (including being able to apply to arbitrary directories), although the types of data being stored are different. However, an extension could be done, that multiple types of data are possible (including Theme Packs), as well as multiple protocols (possibly including alterate services for HTTP(S), e.g. so that Mastodon links can be supported without needing to implement JavaScript and HTML). Of course not all implementations would be required to support all extensions, anyways; these are all intended to be purely optional features, that, like you said, the user installs and sets up manually.)
🚀 clseibold · Oct 06 at 05:50:
I also want to clarify a few things about Scroll really quickly:
Hopefully that clears some things up. Thanks for looking into Scroll! :)
🚲 halscode [OP] · Oct 06 at 16:20:
@clseibold At the very least, you seem to understand how they work a lot better than I do! I do care a lot about accessibility, although it's usually not the first thing that comes to mind, and I'm also not nearly knowledgeable enough about it...