The (Internet) Voskhod Protocol

Conventions Used in this Document

The key words “MUST”, “MUST NOT”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP14.

Abstract

The (Internet) Voskhod protocol is an internet protocol designed for fast and simple text and binary documents lookup and exchange. This document descripes the protocol and explains how to implement clients and servers for this protocol. This document will be subject to change and each of its revisions will contain a short overview of the changes at its beginning. Throughout this document, this protocol will be referred to as simply “Voskhod” or as “The Voskhod Protocol”.

1. Introduction

Voskhod is the name of the space program developed by the USSR in the mid-60s. Its development started a bit before the Gemini program in the United States. Apart from the name, this protocol has very little to do with the Gemini Protocol; it is mainly inspired by Gopher, being intended to fix the “flaws” I found in the latter.

Voskhod is a client-server protocol. It must be served over TCP/IP. Clients SHALL assume port 1964 when it is not specified and servers SHOULD listen on port 1964 and SHALL listen on an unpriviledged port. That is because 1964 is the year of the first crewed Voskhod flight — unsuprisingly before Gemini — and because unpriviledged users, for example on an academic network, should be able to run their own server.

The Voskhod Protocol should theoretically be optimal for use on an university campus or a non-massive local community. It is designed to be used on small, distributed servers, which MAY be recorded on a central registry, with a potentially recursive architecture. The Voskhod Protocol presents resources with a filesystem-like organization, with filesystem elements being text or binary files, directories, or even link to other servers.

The Voskhod Protocol presents only one kind of request, roughly similar to a Gemini request or an HTTP GET request. The clients and servers SHALL support a traditional URI syntax as defined by RFC 3986, and the “voskhod” URI scheme SHALL be used.

While the Internet Gopher Protocol specifies how search servers shall be queried and respons, the Voskhod Protocol leaves the users free to build their own tools for this purpose. See section 4, “Writing Clients” for more details.

The Voskhod Protocol allows for verification of servers using a SSH-key based “Trust On First Use” authentication system.

2. Voskhod Sessions

A typical Voskhod session goes like this:

• Client: Sends a path to the server. The path SHALL be UTF8-encoded and UTF8 SHALL be supported by both clients and servers.
• Server Sends back its public SSH keyprint
• Client:
  1. If the client already has the key associated with the server, the user SHALL NOT be prompted and the connection SHALL be accepted.
  2. If the client does not know the key, the user SHALL be prompted whether he trusts the server or not. If the user does, the key SHALL be recorded and the connection SHALL be interrupted.
• Server: Sends its response to the client and closes the connection. See section 3, “Server Responses and their Handling” for more information.
• Client: Reads as much bytes as the server announced in its response. The client MAY perform end-of-stream checks. It then processes the received data and closes the connection. Read section 3, “Server Responses and their Handling” for information on how to proceed the data.

3. Server Responses and their Handling

3.1. Server Responses

A server response is structured as follows:

• 1 byte indicating the type of document being sent to the client. See subsection 3.1.1, “Document Types” for a list of document types that SHALL be supported.
• 4 bytes indicating the number of bytes to be sent. Those bytes SHALL be big-endian encoded
• The actual body of the response. See section 3.1.2, “Body Format”for more information.

3.1.1. Document Types

Clients and servers SHALL support at least those document types:

• 00 — An error occured. The body corresponds to the detailed error. See section 3.1.2, “Body Format” for information on how errors SHALL be returned.
• 01 — A generic text file. The body SHALL be UTF8-encoded.
• 02 — An uuencode d binary file.
• 03 — A directory listing. See section 3.1.2, “Body Format”, for information on how directory listings SHALL be formatted.
• 04 — A link. See section 3.1.2, “Body FOrmat” for a list of the allowed link types and their syntax.

Upon receiving an unknown document type, clients SHALL ask the user what to do instead of displaying garbage. Different document types MAY be sent by the server, it is up to the client and the server to agree on them.

3.1.2. Body Format

3.1.2.1. Errors

Clients and server SHALL at least support the following errors. The error text SHALL be sent exactly as written.

• “Server unavailable”
• “Resource not found”
• “Rate limit exceeded”

3.1.2.2. Directory listings

Each resource in a directory listing is formatted using the following syntax:
‹TYPE›‹NAME›CRLF

‹TYPE› is the document type as defined in section 3.1.1, “ Document Types”, spanning 2 bytes. ‹NAME› is the UTF8-encoded name associated with the resource, representing the link to the resource on the server. It SHALL NOT contain any slash (‘/’, ASCII 2F) characters, as it is used to separate path stems. CRLF is an ASCII Carriage Return character (hexadecimal code 0D) followed by an ASCII Line Feed character (hexadecimal code 0A).

3.1.2.3. Links

There are 3 possible link types.

1. A relative path. It is represented with a traditional UNIX-style path missing the first slash (‘/’) character, e.g. “folder/document.txt”.
2. An absolute path. It is represented with a traditional UNIX-style path, e.g. “/documents/voskhod.txt”.
3. A link to another server using either Voskhod or another protocol. It is represented with a fully-featured URL, as defined by RFC3986 using the following syntax:
   ‹PROTOCOL›://[USERNAME[:PASSWORD]@][SUBDOMAIN.]‹SLD›.‹TLD›[:PORT][/RESOURCE]
   
   E.g., “https://my.fsf.org/join”

4. Writing Clients

Clients SHALL understand the standard URI scheme according to RFC3986.

When opening Voskhod links from a directory listing, the client SHALL follow them and SHOULD permit the user to follow the link in a new tab or window.

Clients SHOULD allow the user to specify an application to use to open “non-voskhod” links.

Clients SHOULD permit the user to open files in a specific application, either on-the-fly or depending on their types in a configuration file.

Clients SHALL display text files and SHALL by default display other files in an pager. The commands used to control the pager SHOULD by default be similar to the ones used by GNU less.

Clients MAY present an embedded search engine to the user. The said search engine SHALL ONLY present pages sorted by closeness to the query and SHALL NOT sort by commercial affiliation.

Clients SHOULD do page caching of some sort. Clients SHALL NOT cache the contents of directory listings.

If the client presents a search engine, the latter SHOULD make use of multithreading for indexing and search.

Clients SHOULD permit the user to go back and forth in the history. Clients SHOULD permit the user to view more than one resource at a time.

5. Writing Servers

Servers SHALL understand the standard URI scheme according to RFC 3986.

Servers SHOULD have an “About” plain text file in their hierarchy explaining the server's purpose and listing means of contacting the administrators.

Additional security is up to the implementers. This protocol is not intended to transmit confidential data as it exposes no means of authentication to the user. Thus, no data protection would be useful. However, servers may apply protection against, for instance, (D)DoS attacks.