Commit edb29f8f650064eb7ff4e7303764203082e89e72
moved prototype examples into design doc
updated some remarks in schemadust committed on 4/24/2016, 2:43:53 AM
Parent: b9969c999b4a32b640beefc426e65ed5254e6653
Files changed
| README.md | changed |
| design.md | changed |
| spaceship-engines.md | changed |
| spaceship-schema.md | changed |
| README.md | ||
|---|---|---|
| @@ -12,29 +12,16 @@ | ||
| 12 | 12 … | ## contents |
| 13 | 13 … | |
| 14 | 14 … | 1. [rationale and motivation](./rationale.md) |
| 15 | 15 … | 2. [design overview](./design.md) |
| 16 … | +4. [prototypical examples](./design.md#prototypicals) | |
| 16 | 17 … | 4. [spaceship-schema](./spaceship-schema.md): a document describing the basic |
| 17 | 18 … | building blocks of the design and how they relate. |
| 18 | 19 … | 3. [spaceship-engines](./spaceship-engines.md): a document describing the basic |
| 19 | 20 … | "API-like" functions needed to realise the schema. |
| 20 | -4. [prototypical examples](#prototypicals) | |
| 21 | 21 … | 5. roadmap: [engines+bridge](#roadmap) |
| 22 | 22 … | 6. [answers to questions](./faq.md) |
| 23 | 23 … | |
| 24 | - | |
| 25 | -## prototypicals | |
| 26 | - | |
| 27 | -- [git-ssb](https://github.com/clehner/git-ssb) | |
| 28 | - | |
| 29 | -in fact this is a very interesting example, because git itself is a tool for | |
| 30 | -producing different subjective views of a decentralised network of data! | |
| 31 | - | |
| 32 | -- [tor browser](https://www.torproject.org/projects/torbrowser.html.en) (thru | |
| 33 | - hidden services only) | |
| 34 | - | |
| 35 | -- [patchwork](https://github.com/ssbc/patchwork) | |
| 36 | - | |
| 37 | 24 … | ## roadmap |
| 38 | 25 … | |
| 39 | 26 … | - [ ] reference engine implementations in: |
| 40 | 27 … | - [ ] scuttlebot |
| design.md | ||
|---|---|---|
| @@ -181,4 +181,69 @@ | ||
| 181 | 181 … | permeating it. and yes, if you spring a leak, the privacy goes right out. but |
| 182 | 182 … | all of that is true already, and we're floating naked at the moment. |
| 183 | 183 … | |
| 184 | 184 … | and in a spaceship, you can go *anywhere*. |
| 185 … | + | |
| 186 … | +## prototypicals | |
| 187 … | + | |
| 188 … | +ok, so that might have been a little bit abstract. here are some existing | |
| 189 … | +examples that approach the ideas above: | |
| 190 … | + | |
| 191 … | +- [patchwork](https://github.com/ssbc/patchwork) | |
| 192 … | + | |
| 193 … | +patchwork was the original inspiration for this design. it was intended as a | |
| 194 … | +demonstration of the secure-scuttlebutt protocol, with a light amount of | |
| 195 … | +feed-like structure (a la twitter) over the data. patchwork almost corresponds | |
| 196 … | +to the bridge of a spaceship, but it doesn't have good affordances for | |
| 197 … | +persistent group boundaries. its schema and message handling libs are a rough | |
| 198 … | +approximation of an engine. lastly, the "data feed" and "network sync" views | |
| 199 … | +provide an excellent glimpse into the visible galaxy. | |
| 200 … | + | |
| 201 … | +- [git-ssb](https://github.com/clehner/git-ssb) | |
| 202 … | + | |
| 203 … | +this is a very interesting example, because git itself is a tool for producing | |
| 204 … | +different subjective views of a decentralised network of data! both | |
| 205 … | +[patchwork](https://github.com/ssbc/patchwork) and git-ssb actually view | |
| 206 … | +overlapping sets of data provided by scuttlebot, but git-ssb provides | |
| 207 … | +affordances for appending git-compliant records to the scuttlebutt galaxy, as | |
| 208 … | +well as a github-like view with "issues" and "pull requests". issue threads can | |
| 209 … | +actually be viewed and replied to, using patchwork as well. | |
| 210 … | + | |
| 211 … | +the rough architecture of git-ssb is also very close to the spaceship parts i | |
| 212 … | +mentioned: | |
| 213 … | + | |
| 214 … | +> - A command line tool git-ssb for managing SSB git repos | |
| 215 … | +> - A git remote helper git-remote-ssb for using ssb:// URLs with git | |
| 216 … | +> - A web server git-ssb-web for browsing repos locally | |
| 217 … | + | |
| 218 … | +using the spaceship schema, i would label the top two as engine components, and | |
| 219 … | +the bottom one as part of a bridge. | |
| 220 … | + | |
| 221 … | +- [capsule](https://github.com/du5t/capsule) | |
| 222 … | + | |
| 223 … | +capsule is a bare one-way transmitter that exemplifies the spatial boundaries at | |
| 224 … | +play. its interface, installed as a browser plugin, extracts some selected | |
| 225 … | +portion of a WWW page and serialises it into a protocol URI for parsing and | |
| 226 … | +re-transmission into a galaxy (the engine component). this process is necessary | |
| 227 … | +to cross the borders set out by contemporary browsers, whose domain of use is | |
| 228 … | +the [WWW](https://en.wikipedia.org/wiki/World_Wide_Web). | |
| 229 … | + | |
| 230 … | +this results in a permanent record in some galaxy like ssb that now has a | |
| 231 … | +completely separate life from the original web page, and can now be commented | |
| 232 … | +on. | |
| 233 … | + | |
| 234 … | +- [tor browser](https://www.torproject.org/projects/torbrowser.html.en) (thru | |
| 235 … | + hidden services only) | |
| 236 … | + | |
| 237 … | +though they're known for privacy, obfuscation, and censorship resistance, tor | |
| 238 … | +hidden services are also designed to cross NAT (network address translation) | |
| 239 … | +boundaries. they are available at `.onion` addresses, which constitute their own | |
| 240 … | +namespace separate from the central registries (DNS) and authorities (ICANN) | |
| 241 … | +that regulate the WWW or "surface web" (or whatever it is they call it these | |
| 242 … | +days). | |
| 243 … | + | |
| 244 … | +the tor browser bundle contains an aggressively updated and patched copy of the | |
| 245 … | +firefox browser, which serves as its "bridge" or "cockpit". it bundles a copy of | |
| 246 … | +tor which is automatically started in the background to allow connection | |
| 247 … | +through, and to, the namespace of onions. that serves as its | |
| 248 … | +"engine". naturally, the collection of relay, bridge, and hiddens service nodes | |
| 249 … | +(not to be confused with the spaceship bridge) constitute the onion "galaxy". | |
| spaceship-engines.md | ||
|---|---|---|
| @@ -3,18 +3,18 @@ | ||
| 3 | 3 … | following the [schema](./spaceship-schema.md), a spaceship needs an engine to |
| 4 | 4 … | travel a cypherspace galaxy. an engine is constructed from a set of functions |
| 5 | 5 … | that realise the spaceship schema. this resembles an API. unlike an API though, |
| 6 | 6 … | these requirements are not set out by a central server and presented to |
| 7 | -clients--spaceships own their engines and builders may customise them as they | |
| 8 | -like. | |
| 7 … | +clients--spaceships own their engines and technicians/mechanics may customise | |
| 8 … | +them as they like. | |
| 9 | 9 … | |
| 10 | 10 … | what we present here is a limited set of functions a codebase should provide to |
| 11 | 11 … | properly function as a spaceship engine. not all of these functions need |
| 12 | 12 … | implementing on their own--many of them are easily realised as compositions. |
| 13 | 13 … | |
| 14 | 14 … | general remarks: |
| 15 | 15 … | |
| 16 | -- all spaceship identifiers (public keys) must be signed with the appropriate | |
| 16 … | +- spaceship identifiers (public keys) must be signed with the appropriate | |
| 17 | 17 … | private key or similar attestation, for every request. |
| 18 | 18 … | - where a function returns no output (for example, if it is used to modify |
| 19 | 19 … | galactic or local state), it's best to return information about the result. |
| 20 | 20 … | |
| @@ -68,11 +68,11 @@ | ||
| 68 | 68 … | filesystem, and makes them available to `listIdentifiers()`. |
| 69 | 69 … | |
| 70 | 70 … | #### notes |
| 71 | 71 … | |
| 72 | -- assuming the hardware substrate is running something like windows/posix, | |
| 73 | -identifying data should be stored in | |
| 74 | -[XDG standard directories](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). | |
| 72 … | +- assuming the spaceship's hardware substrate is running something like | |
| 73 … | + windows/posix, identifying data should be stored in | |
| 74 … | + [XDG standard directories](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). | |
| 75 | 75 … | - asymmetric-key cryptography is expected to be the most reliable form of |
| 76 | 76 … | identifier for the foreseeable future, but any implementation that combines a |
| 77 | 77 … | pilot's secret knowledge (i.e., a passphrase) with a robust stored secret (a |
| 78 | 78 … | private key) and a reusable public sigil (a public key) meets this spec. |
| @@ -214,9 +214,9 @@ | ||
| 214 | 214 … | |
| 215 | 215 … | #### notes |
| 216 | 216 … | |
| 217 | 217 … | - hailing an orbital is a good way to check for its existence before trying to |
| 218 | - create one with similar existential parametres. | |
| 218 … | + create one with similar existential parameters. | |
| 219 | 219 … | - emigrating an orbital is a good way to repudiate a public key, if the |
| 220 | 220 … | identifier has been compromised. |
| 221 | 221 … | - orbitals are just implicit collections of records, established by |
| 222 | 222 … | (cryptographically secured) recipient lists or just a single reference to an |
| spaceship-schema.md | ||
|---|---|---|
| @@ -23,11 +23,12 @@ | ||
| 23 | 23 … | |
| 24 | 24 … | **key characteristics:** |
| 25 | 25 … | |
| 26 | 26 … | - spaceships are the method by which travellers interact with cypherspace. they |
| 27 | - are the embodiment of a traveler. | |
| 27 … | + are the embodiment of a traveler as far as the galaxy is concerned. | |
| 28 | 28 … | - spaceships have an obligation to relay or mirror records they receive to other |
| 29 | - parts of the galaxy. | |
| 29 … | + parts of the galaxy. (for example, a ship that views the ssb galaxy is also | |
| 30 … | + obligated to participate in the gossip protocol that makes it work.) | |
| 30 | 31 … | |
| 31 | 32 … | **design concepts:** |
| 32 | 33 … | |
| 33 | 34 … | - spaceships as vehicles of thought, as in |
| @@ -140,9 +141,9 @@ | ||
| 140 | 141 … | spaceships. |
| 141 | 142 … | |
| 142 | 143 … | **design concepts:** |
| 143 | 144 … | |
| 144 | -- the kriptosfear of iain banks' | |
| 145 … | +- the *kriptosfear* of iain banks' | |
| 145 | 146 … | [feersum endjinn](https://en.wikipedia.org/wiki/Feersum_Endjinn) |
| 146 | 147 … | - the posthuman editable universe of |
| 147 | 148 … | [transistor](https://en.wikipedia.org/wiki/Transistor_(video_game)) |
| 148 | 149 … | |
| @@ -198,5 +199,5 @@ | ||
| 198 | 199 … | orbital-local traffic. |
| 199 | 200 … | |
| 200 | 201 … | galaxywide broadcasts are of course also possible, but unreliable at |
| 201 | 202 … | best. experiments in the centralised internet outside of cypherspace have shown |
| 202 | -them to be deeply problematic also. | |
| 203 … | +them to be problematic. | |
Built with git-ssb-web