-- Leo's gemini proxy
-- Connecting to auragem.letz.dev:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
Recently I read Mozz's post about Gopher+, which became the inspiration for my new Scroll Protocol:
A few things from Gopher+ jumped out at me, particularly the new Gopher+ requests, which I will be calling "metadata requests". Gopher+'s approach to these requests and abstracts has, to me, made a greater case for the choice Gemini took in having gemtext directories rather than simple menus (like what Gopher had originally intended). One might call Gemini's approach Document Directories, but I argue that the distinction between Gopher and Gemini is the distinction between Uncontextualized Directories and Contextualized Directories.
Gopher+'s Metadata requests are really interesting because they allow you to just get the metadata of a resource without actually getting that resource. This is actually really useful for browsers displaying information *before* getting the whole resource. This is even particularly useful for Search Engines and Crawlers to just check the existance of a resource, or whether it has been updated even, or to get its content type, before getting the actual file.
Gopher+ also adds in these "abstracts" to the Metadata requests. Abstracts offer a description of the file. This lets someone get a brief description of a file before spending resources downloading it. Abstracts in Scroll also offer the title of the resource so browsers and crawlers can get the title before downloading the resource. One use of an abstract could be to list the currently playing song of an audio stream within the abstract, and AuraGem's public radio does just this.
All of the above, however, introduces a new concept: a distinction between contextual information and non-contextual information. When you link to a resource from a page, you title the link in a way that it's contextual to that page. However, resource metadata is non-contextual; it doesn't depend on the context of another page.
Both contextual and non-contextual information is useful, and this to me justifies the use of documents like in Gemini over file listings like in Gopher. Documents give information about files within the context of the rest of the document. File listings presumably give non-contextual information. However, gopher already blurs this boundary by allowing you to link to outside resources from a menu! And thus, links that should be non-contextual, like in a filesystem, become contextual as file links are placed in groups, categorized, and even duplicated among multiple menus. And yet gopher's "i" itemtype that would explain this context, that would explain how a link relates to the rest of the links in the menu, is non-standard and frowned upon. Gemini makes the correct decision in allowing the already-blurred lines to be clarified by contextualizing links with text. Gemtext documents are better menus than gopher menus ever were for this simple reason: groupings of links (menus) can be contextualized and explained with text.
Mozz had it only partially right when he talked about the distinction of Documents and Directories in 2019:
It is true that Gopher distinguishes between menus and documents, whereas the web does not. In the modern web, every page has become a document to the point that directories hardly even exist anymore. Gopher has "directories" that are more like groupings of links, aka. menus. However, Gopher already blurs the lines some by allowing groupings of links to outside sources and to elsewhere within the "filesystem". This categorization that is inherent in link groupings is already content itself - the content is the menu itself, the collection of links, the organization, the categorization. It goes beyond simple directories by relating links to each other in a menu.
Gemini ends up using the same markup for directories and documents, but the distinction is still present: a gemtext directory is usually constructed differently than a gemtext document. Gemini directories, just like in Gopher, becomes a form of content. It goes beyond a simple directory by allowing categorization, organization, collection, etc. The content of a Gemini directory is this categorization. However, Gemini allows you to *explain* the categorization, to contextualize links, to describe links, to create headings to further subdivide the organization of the "directory" (or rather, *menu*). Of course there are now some cases where the lines are becoming a bit more blurred like they became in the web, and this mainly comes from the social media and other interactive capsules.
It should be pointed out that Gopher does have contextualized directories if one adopts the use of "i" itemtypes. However, there is clearly still a subset of users within Geminispace who are still a bit resistant to informational itemtypes, and the original creators of Gopher seemed to have been resistant to them as well. With this itemtype, Gopher can act more like Gemini, but it offers an even greater distinction between directories and documents by making menus even more limited, and by limiting the purpose of menus/gophermaps to just menus. Of course, people can still abuse these itemtypes by making their actual documents into gopher menus.
Regardless, I think the distinction between the two still remains within Geminispace, probably because the distinction is actually quite natural, and the limitations of gemtext probably lend toward the distinction as well. For example, my devlog is still a gemtext directory/menu of links to individual gemtext posts. There is still a distinction.
Scroll takes much the same approach as Gemini, but it tries to reintroduce the distinction between directories and documents through convention (see the "Structure of Content" section in the spec), particularly the convention of what is expected of super-directories in URLs.
Here are the next articles in this series:
-- Response ended
-- Page fetched on Tue May 7 03:05:53 2024