The conceptual model for the Alph server is that media resources should act like smart media objects: resources that not only deliver their content payload (plain texts, images, audiovisual streams, HTML documents, links, ...) but which are also capable of responding to queries about their metadata and their connections/relations to other resources in the network.
Easy Publishing
It should be trivially easy for people to put stuff on the Web. With Alph.py, it is. Just browse to the directory you want to publish something into, select a file from your computer, give it the name you want it to have on the network and hit 'upload'. Easy peasy.
This can be done via the index pages that Alph.py generates, or via the Docuplextron (or via curl, etc.).
Metadata
It must be a core feature of any global hypertext system that resources can be queried to provide authorship/ownership information – at the very least. Of course, all sorts of other interesting metadata can be made available too.
The Alph server advertises its media resources as Linked Data Platform Resources (and its directories as Linked Data Platform Containers). What this means is that if you send an HTTP GET request to a resource with the Accept: header set to "*", then you'll get the content payload of that resource; if you set the Accept: header to "application/ld+json" (or another appropriate RDF serialization) then you'll get a Linked Data document with metadata about the resource. I'm using the schema.org ontology as well as the http://alph.io/terms namespace for properties and types that are specific to this application/system.
The JSON-LD metadata is also available by sending a "?describe" query to the resource.
Interface Discovery/Advertisement
One of the metadata that you'll see delivered with media resources from the server is an "interface" property, the value of which will be the following collection of URIs:
I've already mentioned what the ?describe interface is for, and I'll briefly touch upon the other two in a moment. If you want more detail on these interfaces, well, follow the URLs to read about them!
Two-Way Linking
There's an explainer that goes into more detail on what I mean by two-way linking, but in brief: when resource X is linked to resource Y, you should be able to see (or discover) the existence of that link when only viewing one resource. This can be achieved on the client side (the Docuplextron does this), or it can be achieved on the network side.
Alph.py implements network-side two-way linking like this: when a resource receives a GET request, it tries to fetch the document given in the request's Referer: header (if there is one), and scan that document for links-to or transclusions-of itself. If it finds any, it keeps a record of them on the server.
If a resource is sent a GET with the ?link query, it will return a JSON-LD graph containing all of the links that it has discovered about itself. The "?link" query can take some parameters to filter the returned graph (which, theoretically, could end-up being very large).
Fragmentary Retrieval
Because xanalogical documents are based entirely on the transclusion of media fragments, it's a fundamental capability of a server in this type of system to be able to only transmit the portions of media needed to fulfill the transclusions in a document.
Fragmentary retrieval is also tied to the idea of micropayments, which are beyond the scope of this project — although I'm open to some day integrating an opt-in content syndication system if the implementation isn't too onerous.
By sending a ?fragment query to the server with a fragment selection parameter that it understands, the server will return only the requested portion of the resource.
Index Pages
Index pages aren't very exciting, but I believe that they're critical to discoverability on the Web, and their disappearance has led to a far less surfable Web than when I was a kid.
So, Alph.py automatically generates some pretty vanilla index pages on directories, which the user can either augment by including some descriptive text/HTML to be inserted at the top of the index page, or by creating their own index.html document to override the generated index entirely.
The nice thing about the automatically-generated index pages is that they use the "description" and "name" properties in a resource's metadata to provide a more useful index than just a file listing. No image thumbnails, though. This can be added later, but it's not a priority right now.
Implementation
Alph.py is a steaming pile of Python spaghetti that runs on top of Apache. If you've got access to cheap shared hosing that lets you run Python CGI scripts and use .htaccess files, and you've got some basic utilities installed (and the 'rdflib' Python library), you can set-up a server. I'm running it on a few machines in the wild, including the SDF Public Access Unix System cluster, and it's reasonably easy to do.