NEX AND SMALL NET

Nex takes a lot of inspiration from Gemini and Gopher. I'd 
like to acknowledge that both these protocols have helped 
me understand what a different way to consume internet 
could be. They've also reminded me how fun it is to think 
about the fundamentals of exchanging information.

Nex's main goal is to be as small as possible while being 
useful enough to be used by individuals to share their 
personal sites. It's an experiment in how useful a protocol 
can be if you remove most of the things that are part of 
protocols such as media types, response codes or the 
ability to post (vs only read).

Both Gemini and Gopher are mainly used for consuming pages. 
Technically, Gemini allows its users to submit content as 
well. In Nex, it's not possible to publish content. The 
protocol is read-only. There are many ways to create files 
such as connecting through SSH or via SFTP. Tools like 
email are a great way to contact people and connect. 
Everyone is encouraged to leave their email address on 
their nex stop for this reason.

One thing I appreciate about both Gemini and Gopher is that 
the protocols are simple enough to allow anyone to build 
their own browser. That's been a big goal when creating 
nex. Keeping the protocol simple has tradeoff on security: 
nex doesn't rely on TLS like Gemini does. The information 
one publishes on nex should be public information and there 
won't be ways to identify a user. In that regard, nex is 
closer to Gopher. It's a way to browse remote directories 
as if the internet was one big hard drive.

While Gemini allows to set a content-type, Gopher has a 
different approach. The user can decide how to read a 
specific selector by setting an item-type. These are often 
set in gophermaps directly. On nex, there are no content 
type nor item-types. Instead, browser assume that a 
selector finishing with a / is a directory. All the rest is 
served as plain text. This doesn't prevent nex from serving 
images, music or anything else: it's up to the browser to 
decide what to do with a specific file extension.

All of the above make building a nex browser very 
straightforward. In fact, here's a one-line browser:

echo $2 | nc $1 1900 | less

Another difference between Gemini and nex is that on nex, 
only directories are expected to have links. This is 
intentional. The expectation is for directories to be used 
as a map that connects to relevant resources, while 
individual files are written in a standalone way. Writing 
like that forces the author to include relevant context in 
documents, and ultimately helps against the document 
becoming stale. It also keeps documents simple: no need to 
worry about adding a link back or keeping a navigation 
system.

Another subtle difference is on the links themselves. While 
the Gemini syntax for links allows to add a descriptive 
label, on Nex, all text after the URL is ignored. That's by 
design: we want to make sure to have explicit file and 
directory names.

So here it is, a very bare protocol. There isn't much we 
can do with it. Yet, do we need more?