Thoughts about Scorpion & Scroll

Scorpion

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.

Scroll

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.

Selfishness

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).

🚲 halscode

2024-10-06 · 2 years ago · 👍 clseibold

4 Comments ↓

🚀 clseibold [🛂] · 2024-10-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.

🦂 zzo38 · 2024-10-06 at 05:47:

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 [🛂] · 2024-10-06 at 05:50:

I also want to clarify a few things about Scroll really quickly:

• Pages do not have to be categorized, they can remain uncategorized, and they are uncategorized by default. Categorization is optional and allows crawlers to know where to place something in an index. Categorization of pages is a problem with search engines, which is why lots of formats offer categorization, be it tags in HTML or frontmatter in markdown documents, etc. UDC classification was the latest addition to Scroll, and could change in the future.
• Scroll is more focused on documents, not pages in the traditional Gemini/HTML sense, so categorization does make sense with that explicit goal in mind. I believe Scroll, therefore, does not replace Gemini but acts in tandem with Gemini. Gemini is for apps, Scroll is for documents. That's why Scroll has more features in its markup language than is necessary for Gemini.
• I believe automatic language selection is easy to implement and use, and that it does align with the simplicity goal, which I see as very different from minimalism. Simplicity also does not just take into account implementation, but users as well.
• The data in the metadata fields are optional. The fields themselves are mandatory. This is a very important difference; you do not have to have metadata on any of your responses, but syntactically, the fields need to be there and be empty for that. It's purely a syntactical thing that prevents extensibility of the protocol in the future. Misfin(C) does a similar thing.
• The abstract idea is not about them being automatically requested. They are also not metadata requests per se, they are abstract requests, and this is an important difference between Gopher+ and Scroll. In scroll, an abstract request only happens when the user wants an abstract of the page. If they just want the page, then they already get the metadata with that page. There is almost no reason for clients to automatically request abstracts of pages unless the user wants the abstract itself. Conversely, they are useful if the client *just* wants the abstract and not the page itself.
• Minimalism and simplicity are very different, and I try to state this explicitly in my articles about Scroll. In a minimalist protocol, language selection and categorization would not align. But in a *simple* protocol, they do, because they are simple, not minimal. Minimal suggests less features, simple suggests features that are easy to implement and/or use.

Hopefully that clears some things up. Thanks for looking into Scroll! :)

🚲 halscode [OP] · 2024-10-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...