design overview

prior art comparison

continuing from the rationale...

cypherspace is a place whose entryways and underpinnings lie outside of monolithic server farms, name authorities, global singletons, or any other hierarchy dwarfing any of the people who visit or inhabit it. its limits are defined solely by the choices of those who work within it, and the consent of those around them.

while all of this is great news, decentralisation, and the egalitarian agency that lies beyond it, can't be a purely network layer movement--it needs to happen at the application layer also. it needs to put people at its center.

in order to do this, we need to re-evaluate some old architectural assumptions.

old assumptions: the "client-server" model

what the "server" has to offer in the client-server model is meaningless in a decentralised space. basically, a server only gets you a few things:

• uptime
• processing power
• packaged data (in other words, an API)
• a location (in some field or geography of reputation, throughput, legal regulation)

decentralised systems typically provide these to every person within them. the actual requirements behind uptime (availability, eventual consistency) are provided by asynchronous and aggressively egalitarian propagation protocols, like gossip or torrent. processing power is provided by inexpensive general-purpose hardware (notably, driven by open standards). typically, a person who has guaranteed access to a computer has more computing power than they can use.

the place of APIs, data packaging, and location in a decentralised space is the exactly what the spaceship design aims to address.

in a spaceship, the components of the imbalanced client-server model that are kept out of your control are transformed into components that sit inside your spaceship.

• engines instead of APIs
• galaxies instead of application stacks, server clusters, and other large-scale structure to provide data
• spaceships (and their bridges and cockpits) instead of browsers or stack-bound "apps"

engines v. APIs

recall an API is basically a public commitment by a service provider to do a certain set of things if you give it the right request. usually this is "package data", but since the results can range from "update record" to "audit this human's state of mind" to "kill somebody", the whole "data" thing has gotten loose from a purely informative conception. (and anyway, physicists recognise this sort of distinction as purely conventional.)

but there's no provider in a decentralised space! there's just information in a space, and you can either see it, or you can't. (and with an async request, you can just plan to do whatever is needed in the eventuality.) moreover, what you do with the information that's been shared with is honestly up to you.

in that case, what you need is some programming that moves you through data (or moves data thru you ;). that's what an engine is. you may say "get me another page of this", or you may say "warp 8 to the happening jams"; it's all about the mechanisms you want to build in.

saying that, you can expect a fair number of common types and mechanisms to suit a lot of needs, so, just like other vehicle engines, there will be mostly a collection of standard configurations (themselves constructed of software modules as usual), with a host of tweaks to get what you want out of them.

galaxies v. conventional resource space

as i mentioned in the motivation section, the network stack that runs "the internet" is one of many sets of conventions and transmission media, and it is a centralised one, with very little actual choice or agency, just a collection of mostly profit-oriented dividuations. despite the apparent quantity of services, the same sorts of betrayals and other abrupt changes occur from platform to platform:

• twitter architecture changes such as "verified" profiles
  and algorithmic suggestions
• facebook UI being used for large-scale emotion manipulation experiments
• snapchat failing to live up to the privacy feature that constituted its sole offering
• CDNs ghettoising requestors by forcing them to perform repeated labor to view content if they come from a suspected VPN or Tor exit IP
• tumblr removing LGBT-related material
  from search indexing
• an overall trend of "bullshit minimalism" obscuring a swath of heavyweight, throwaway, "single page" javascript, written for the primary purpose of providing data to markup

in most of the above cases, basically the only recourse you have is to be a complaining consumer. you're not even a customer, because you don't have a paying arrangement (a condition for enfranchisement in a market-controlled system). and anyway, making a lot of noise in the same chamber controlled by the authority you're attempting to sway, or making insignificant consumption choices at the mercy of whatever "app" is trendy at the moment, does nothing to actually increase your agency in any way. worst of all, it reinforces a frame where attention, oration, rhetoric, and other tactical expressions are the main tools of change, where "social capital" is yet another resource to be accumulated.

it's worth it to mention that "network effects", a supposed driver of monolithic centralised services, are meaningless at the scale of lived experience. (almost by definition!) most of the hand-wringing over the market capture implied by that concept is mostly a neurosis created by capital-dependent, winner-take-all systems. "you and yours" is a good enough "market share" for a fully-lived experience. the options just haven't been flexible or satisfying enough yet.

a healthy variety of interdependent but autonomous and discoverable networks of communication that decouple global hierarchy and authority from capacity and structure offers not only this flexibility, but also the recognition and agency not afforded by centralised networks.

spacecraft v. browsers

to be honest, these days a browser is a cross between a television
and a cold war european border. its default use-case is "consume content", and getting data out of it for your own purposes (as opposed to transferring it to another consumer outlet) is a complex process of organising scripts to avoid falling afoul of CSP, exfiltrating data through a URI, and parsing it once delivered to you. even though you can see it and hear it through the browser window, you're not allowed to make it yours (for your own protection).

sadly, this trend is continuing, with this conception of "browser" informing and being informed by mobile phone operating systems, which are notoriously difficult to actually create anything with. the two things they are best at are:

• spending your money
• feeding you poorly-directed and portioned streams of market-driven content

this trend leads all the way to "browser OS", most notably exemplified by chrome OS, where "local" data is completely absent: the source of truth and matters of record is all located out of your grasp. considering that under the current state of governance you are at the mercy of your remotely located identifying data, this is no way to live.

the other extreme is to abandon mediation altogether, and just use short, transparent programs that handle data streams from the minimal interface of a terminal located in a free operating system, as in the unix philosophy and its contemporary form, suckless. this is actually less intimidating than it appears: with tools like fish, the "friendly interactive shell", this kind of interaction is arguably already a conversational UI, marketing slogans aside.

but that extreme's just not going to work for everybody. not everyone wants to use emacs, or assemble a plane from a kit, or explore life as they would the parts of a motorcycle.

if data exists in a space, and it can be made navigable and free, then people need a vehicle to do that safely with. they need a spaceship.

a spaceship is a coherent and unified collection of personal affordances with you as its subject. your ship is code that you control. your ship is an interface you can understand. your ship travels through a space that doesn't set you up to win, lose, or control others.

a spaceship has privacy and safety on the inside. yes, outside of it is an environment hostile to nearly all carbon-based life, with hazardous radiation permeating it. and yes, if you spring a leak, the privacy goes right out. but all of that is true already, and we're floating naked at the moment.

and in a spaceship, you can go anywhere.

prototypicals

ok, so that might have been a little bit abstract. here are some existing examples that approach the ideas above:

• patchwork

patchwork was the original inspiration for this design. it was intended as a demonstration of the secure-scuttlebutt protocol, with a light amount of feed-like structure (a la twitter) over the data. patchwork almost corresponds to the bridge of a spaceship, but it doesn't have good affordances for persistent group boundaries. its schema and message handling libs are a rough approximation of an engine. lastly, the "data feed" and "network sync" views provide an excellent glimpse into the visible galaxy.

• git-ssb

this is a very interesting example, because git itself is a tool for producing different subjective views of a decentralised network of data! both patchwork and git-ssb actually view overlapping sets of data provided by scuttlebot, but git-ssb provides affordances for appending git-compliant records to the scuttlebutt galaxy, as well as a github-like view with "issues" and "pull requests". issue threads can actually be viewed and replied to, using patchwork as well.

the rough architecture of git-ssb is also very close to the spaceship parts i mentioned:

• A command line tool git-ssb for managing SSB git repos
• A git remote helper git-remote-ssb for using ssb:// URLs with git
• A web server git-ssb-web for browsing repos locally

using the spaceship schema, i would label the top two as engine components, and the bottom one as part of a bridge.

• capsule

capsule is a bare one-way transmitter that exemplifies the spatial boundaries at play. its interface, installed as a browser plugin, extracts some selected portion of a WWW page and serialises it into a protocol URI for parsing and re-transmission into a galaxy (the engine component). this process is necessary to cross the borders set out by contemporary browsers, whose domain of use is the WWW.

this results in a permanent record in some galaxy like ssb that now has a completely separate life from the original web page, and can now be commented on.

• tor browser (thru hidden services only)

though they're known for privacy, obfuscation, and censorship resistance, tor hidden services are also designed to cross NAT (network address translation) boundaries. they are available at .onion addresses, which constitute their own namespace separate from the central registries (DNS) and authorities (ICANN) that regulate the WWW or "surface web" (or whatever it is they call it these days).

the tor browser bundle contains an aggressively updated and patched copy of the firefox browser, which serves as its "bridge" or "cockpit". it bundles a copy of tor which is automatically started in the background to allow connection through, and to, the namespace of onions. that serves as its "engine". naturally, the collection of relay, bridge, and hiddens service nodes (not to be confused with the spaceship bridge) constitute the onion "galaxy".