-- Leo's gemini proxy
-- Connecting to scrollprotocol.us.to:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
Publish Date: 2024-03-23T16:54:06Z
Modification Date: 2024-05-10T09:06:30Z
Scheme: scroll://
Port: 5699
Naming Theme: Libraries and Scrolls
The Scroll Protocol is a new document-retrieval protocol on port 5699, inspired by Gemini and Gopher+. It focuses on quality-of-life additions, particularly internationalization. It adds more metadata to responses, the ability to request pages in a specific language, and a new metadata request, similar to Gopher+'s metadata request. It tries to offer a power-to-weight balance by providing basic metadata and relational data in documents with minimal effort and additions.
The additional metadata added to each response is the author, publish date, and modification date. Abstracts of resources are also provided with *metadata requests* only.
Request strings now include an additional parameter that allows the client to specify a list of desired languages. The server will respond with the document in one of the desired languages, or the default language if the requested languages are unavailabe. The language of the response is given in the mimetype.
No ads and tracking
No scripting on pages (No JS, WASM, Flash, or Java)
No insecure markup features like iframes, cookies, user-agents
Simplicity for writers and developers
User-focused content - the writer provides the content, the user determines most of the styling
Offer simpler alternatives to HTML Semantic Markup and Open Graph Tags with a Markdown and AsciiDoc inspired markup language
Multi-media that doesn't interfere with your reading or browsing experience
Document-oriented rather than page-oriented
Email me at christian.seibold32@outlook.com or via misfin at clseibold@auragem.letz.dev to add your host(s) to this list.
There are currently two client and two server implementations for the Scroll Protocol. You can find binaries of each of these on the Precompiled Binaries page.
Profectus is a new GUI browser built in SDL to rival lagrange in terms of performance, visual design, and features. It is currently in beta 1.1 and supports nex, gemini, spartan, and scroll, as well as music streaming (mp3, vorbis, flac, and wav), animated images (gif, apng, jpeg xl, avif, and webp), downloading YT videos, and piping videos into mpv, ffplay, or vlc.
The Reference Scroll Terminal Client also supports Gemini and Nex, and has audio streaming support. It was somewhat modelled after Solderpunk's AV-98.
The Reference Scroll Server is a very simplified version of SIS that only supports serving static files over the Scroll Protocol. It does support virtual hosting. CGI is coming soon. This one is recommended over SIS at the moment as it's easier to use and set up.
SIS is a larger suite of servers that allows users to setup gemini, nex, spartan, gopher, and scroll servers on different ports and hostnames. It is currently in an unfinished state.
One client library is available in Golang and is used by both the reference terminal client and Profectus.
There are no proxies currently.
I originally wasn't going to create any new protocols that mimic much of the same functionality as Gemini or Titan or Gopher. What changed my mind then?
The Scroll Protocol takes some inspiration from Gopher+. I read mozz's journal entry about Gopher+ recently:
This led me to reading the Gopher+ spec:
And while reading this, even though there were a lot of convoluted things that Scroll deliberately does not take from Gopher+ (a scripts section?! yuck!!), there were a couple of interesting things that jumped out as being useful, particularly the metadata requests and the concept of abstracts.
In Gemini there is a lack of semantic detail. Gemtext files don't have a standardized way of getting the publication date or modification date or even an author metadata field. However, we got around this by using gemsub feeds, but it is very often that I come across gemlog pages where the publication date is on the gemsub feed but *not* in the gemlog page itself! And what about other filetypes that also don't include this metadata information, particularly text files? What if we just added these three extremely common metadata fields to all responses?
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 does distinguish 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. Gemini ends up using the same markup for directories and documents; however, the distinction is still present: a gemtext directory is usually constructed differently than a gemtext document. There are some cases, however, 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. 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.
Contextual information lends itself towards semantic information when linking between pages. This is one of the few things that search engines really need but that nobody has effectively created a solution for: how do search engines know when a link to a page implies a positive or negative relationship? Search Engines that use pagerank currently assume all links imply a positive relationship. Scrolltext adds a very simple tag to the end of all links to identify these relationships. It is done in a human-readable way so that they are useful to users, and so that they don't distract too much when the browser doesn't support these tags.
Lastly, and the biggest addition to scroll that I think justifies and warrants its existance, is internationalization, which Gemini and Gopher sorely lack. Gemini offers a lang parameter on responses, and allows UTF-8, which is already more than Gopher does, but there is no way to *request* resources of a particular language without creating a whole different link to the resource adding some language tag to the beginning of the link's path. Scroll solves this by adding a field to all requests for the languages the user desires, and then the server responds with a match for one of the languages, or a fallback if no matches.
I chose this method because the language should not be in links but be requested by the user's client. Links assume everyone reads in the same language as the one who posted the link. Rather, it should be the client, not the content, that decides what language is requested, *and* clients can offer up multiple languages in the request instead of just one language if the user speaks multiple languages. This is such an easy addition that I think will vastly improve internationalization. It also means all error messages may be internationalized by the server!
For all of the reasons above, I felt that these additions were very simple additions, and yet powerful enough, to warrant the creation of a new protocol.
Scroll - a page via scroll.
Scrollery - a collection of scrolls; a scroll site.
Comparison: gemini:// vs. spartan:// vs. scroll:// vs. nex://
gemini spartan scroll nex
------ ------- ------ ---
naming scheme space sparta/greece scrolls & libraries cityscape & highways
transport TCP + TLS TCP TCP + TLS TCP
request structure full URL hostname & path full URL path
request encoding utf-8 us-ascii utf-8 utf-8
status codes 18 4 18 0
document type text/gemini text/gemini text/scroll text/plain
input prompt 1x status "=:" prompt line 1x status none
data upload limited yes limited no
mimetypes yes yes yes no
virtual hosting yes yes yes no
same-site redirects yes yes yes no
cross-site redirects yes no yes no
proxy requests yes no yes no
"lang" response parameter yes no yes no
lang request parameter no no yes no
response metadata heuristic heuristic yes heuristic
abstract/metadata requests no no yes no
link relationships heuristic heuristic yes heuristic
list nesting no no yes heuristic
heuristic means clients must try to interpret the information from the text of the default document format due to a lack of standard.
This scrollery is powered by SIS:
-- Response ended
-- Page fetched on Fri May 10 11:54:11 2024