notes on http://urbit.org/docs/theory/whitepaper now at https://raw.githubusercontent.com/urbit/docs/3a121b1a47d99b4e56b9de8c814bd6bd2e509bd4/docs/theory/whitepaper.md
see also Nock and Hoon notes.
'operating function'; each node's state should be a function on the history of all messages received. Urbit (Urbit's 'Arvo' component, actually) consumes events and produces actions.
Although Urbit is event-driven, and its components communicate with each other by sending events to each other, each event contains a 'call stack' that provides an chain of addresses to return values. Events/actions are stored as a struct of the form [return_path data] ('ovum...an ovum is a cell [wire card]'). When a function returns a value, it pops the head off of the return path to see who to send the return value to, and then it sends back [tail_return_path return_value]; the receiving function (the caller) now has the return path needed to determine who it should send its own return value to later on. In addition to events, Urbit's various components export a (global, monotonic) namespace (using the 'scry' system). There is also a 'mark' type system, which is like a MIME-type "Marks are like MIME types, if MIME types came with with executable specifications which defined how to validate, convert, diff, and patch content objects.".
The main components of Urbit ('vanes') (that is, main components aside from Nock and Hoon and the overarching framework Arvo), are:
- networking ("ames")
- storage/filesystem/versioning ("clay"). Described as a simplified/lightweight typed git (see description in whitepaper for why it is lightweight, i didn't completely understand it). It uses the 'mark' type system to know how to diff and patch non-text files. In addition to allowing 'pulling' like git, it can do 'push' synchronization.
- build system ("ford"). "It builds applications, resources, content type conversions, filter pipelines, more or less any functional computation specified at a high level. Also, it caches repeated computations and exports a dependency tracker, so that %ford users know when they need to rebuild." "With every build, %ford exports a dependency key that its customers can subscribe to, so that they get a notification when a dependency changes. For example, %gall uses this feature to auto-reload applications." "Finally, both for loading internal resources in a build and as a vane service (notably used by the web vane %eyre), %ford defines a functional namespace which is mapped over the static document space in /doc." If we request a resource from %ford that does not correspond to a file in /doc, we search in /fab for the longest matching prefix of the path. The fabricator receives as its sole argument that part of the path not part of the matching prefix."
- user-space application system ("gall"). "Other than convenience and sanity checks, the principal value add of %gall is its inter-application messaging protocol. %gall messaging supports two communication patterns: a one-way message with a success/error result (%poke), and classic publish and subscribe (%peer). %peer is designed for synchronizing state. The subscriber specifies a path which defines an application resource, and receives a stream... total and incremental updates." "...all %gall messages carry a mark and are validated by the receiver. Marks are not absolute and timeless - %ford needs a beak (plot, desk, version) to load the mark source."
- http
- terminal interface
- timers
- secret storage
![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
