@@ -102,8 +102,7 @@ that is sent over the wire, so be careful not to send anything too
102102massive unless you're willing to wait.
103103
104104But enough about the interface. Grepping in ames.hoon for `%wont`, we
105−find that it appears in exactly two places: at its definition in
106−`++kiss`, and in `++knob`, where it is handled. We see that we go
105+find that it appears in `++knob`. We see that we go
107106directly into `++wise:am`.
108107
109108```
@@ -152,11 +151,11 @@ This is slightly more complicated, but it's still not all that bad. Our
152151inputs, at least, are fairly obvious.
153152
154153If you glance at the code for a second, you'll see that
155−`++wind:ho:um:am` seems to be able to send a message, or `++meal`, given
154+`++wind:ho:um:am` seems to be able to send a message, or `++meal:ames`, given
156155a `++soup`. This gate, then, just sets up the things we need to for
157156`++wind` to do its job.
158157
159−We first get `rol`, which is a `++rill`, that is, a particular outbound
158+We first get `rol`, which is a `++rill:ames`, that is, a particular outbound
160159stream. This stream is specific to the path on which we're sending. If
161160the path hasn't been used before, then we create it. We let `sex` be the
162161number of messages we've already sent on this path.
@@ -171,7 +170,7 @@ crypto. At the moment, we only need our neighbor's life, which we put
171170into the meal.
172171
173172Finally, we call `++wind:ho:um:am` with the `++soup` of the path and
174−message number and the `++meal` of the payload itself. For end-to-end
173+message number and the `++meal:ames` of the payload itself. For end-to-end
175174acknowledged messages, we use `%bund`.
176175
177176```
@@ -199,7 +198,7 @@ and (3) sends any packets that are ready to be sent. Yes, our nice
199198little linear run of each gate calling exactly one other interesting
200199gate is over. We'll go in order here.
201200
202−`++zuul:lax:as:go` is the what converts a `++meal` into a list of
201+`++zuul:lax:as:go` is the what converts a `++meal:ames` into a list of
203202actual, 1KB packets.
204203
205204```
@@ -403,7 +402,7 @@ the ship names in a packet.
403402
404403Next, we construct `bod` by simply concatenating the sending ship, the
405404receiving ship, and the body of the message. Then, we get the encryption
406−mechanism from `++skin`, which may be a 0, 1, 2, or 3, and put it in
405+mechanism from `++skin:ames`, which may be a 0, 1, 2, or 3, and put it in
407406`tay`.
408407
409408Next, we concatenate together, bit by bit, some final metadata. We use
@@ -457,7 +456,7 @@ First, we put into `pyz` the id for this message and the number of its
457456packets that have not yet been acknowledged, which is of course the
458457total number of packets since we haven't even sent the packets.
459458
460−For every packet, we change three things in the state (`++shed`) of our
459+For every packet, we change three things in the state (`++shed:ames`) of our
461460packet pump: (1) we increment `nus`, the number of packets sent; (2) we
462461put the packet number into `diq` keyed by a hash of the packet; and (3)
463462we put the packet into the packet queue, with the basic metadata of its
@@ -573,11 +572,11 @@ to our neighbor. First, we get `fro` and `too`, the "canons" of ourself
573572and our neighbor, respectively.
574573
575574What is this "canon", you ask? A canon is simply a ship plus its
576−"ancestors", as defined by `++sein`. For example, the canon of
575+"ancestors", as defined by `++sein:title`. For example, the canon of
577576`~hoclur-bicrel` is:
578577
579578```
580− ~hoclur-bicrel/try=> (saxo ~hoclur-bicrel)
579+ ~hoclur-bicrel/try=> (saxo:title ~hoclur-bicrel)
581580 ~[~hoclur-bicrel ~tasruc ~tug]
582581```
583582
@@ -605,7 +604,7 @@ Now, we can finally get to `++busk:ho:um:am`.
605604```
606605
607606Thankfully, `++busk` is fairly simple. We go through the list of packets
608−and convert them to `++boon`s with `++wist:lax:as:go`. These boons are
607+and convert them to `++boon:ames`s with `++wist:lax:as:go`. These boons are
609608placed into `bin`, and they end up getting processed by `++clop` (this
610609happens in `++knob`).
611610
@@ -637,7 +636,7 @@ happens in `++knob`).
637636 :- %fast
638637 %^ cat 7
639638 p.u.yed.caq.dyr
640− (en:crua q.u.yed.caq.dyr mal)
639+ (en:crub:crypto q.u.yed.caq.dyr mal)
641640 ==
642641```
643642
@@ -648,9 +647,9 @@ First, if we are sending a message to ourself, then we simply create a
648647`%ouzo` boon with a bunted lane. Otherwise, if there are no routing
649648candidates, there is nothing we can do, so we return nil.
650649
651−Next, we get the `dore` of the first routing candidate. If we're looking
650+Next, we get the `++dore:ames` of the first routing candidate. If we're looking
652651at the neighbor to whom we're trying to send the message, then we simply
653−use the `dore` that we already have. Otherwise, we get a default `dore`.
652+use the `++dore:ames` that we already have. Otherwise, we get a default `++dore:ames`.
654653
655654If we're the first routing candidate, or if we have don't have a lane to
656655this candidate, then we skip this candidate and move on to the next one.
@@ -660,7 +659,7 @@ we also try to send on later routing candidates as well. Otherwise, we
660659only send on this one candidate.
661660
662661Finally, we create the actual `%ouzo` boon. The lane is the one from our
663−`dore`. If we're sending it directly to our intended recipient, and we
662+`++dore:ames`. If we're sending it directly to our intended recipient, and we
664663haven't been told to use a specific lane, then we just send the packet
665664directly. Otherwise, we wrap it in a little `%fore` meal, telling the
666665intermediary to whom we wish it to be sent. If we have already set up a
@@ -705,7 +704,7 @@ earlier.
705704Here, though, we call `++gnaw:am` to process the packet. The arguments
706705to `++gnaw` are the same as those to the `%hear` kiss: the lane on which
707706the packet was received and the packet itself. The other argument is
708−just `%good`, which is a `++cape` saying that we expect the packet to
707+just `%good`, which is a `++cape:ames` saying that we expect the packet to
709708succeed. If a formal error occurs, then since we have a transactional
710709event system, the `%hear` event will never be considered to have
711710actually happened, and unix will send a `%hole` kiss so that we may send
@@ -728,7 +727,7 @@ a negative acknowledgment.
728727
729728First, we check the protocol number. If it is not correct, then we
730729simply ignore the packet entirely. Otherwise, we parse the packet with
731−`++bite`, which converts a packet atom into a `cake`, that is, a triple
730+`++bite`, which converts a packet atom into a `++cake:ames`, that is, a triple
732731of the `sock` (pair of sender and receiver), the `skin` (encryption
733732type), and the data.
734733
@@ -763,7 +762,7 @@ to these cores.
763762
764763The new stuff here, then, is the `++la` core and the `++chew` arm. The
765764`++la` sets up a core for this particular packet, containing the current
766−success/failure `cape`, the lane it was sent on, the encryption type,
765+success/failure `++cape:ames`, the lane it was sent on, the encryption type,
767766and a hash of the packet, used as an id.
768767
769768`++chew` is called with the encryption type and the message itself. It
@@ -795,7 +794,7 @@ we'll go into in just a minute.
795794
796795We now do the same two checks and store the results in `eng` and `bou`.
797796If our neighbor has, like the prodigal son, returned after an extended
798−absense, then we send a `%wine` boon as the proverbial fatted calf,
797+absence, then we send a `%wine` boon as the proverbial fatted calf,
799798which is simply printed out to the console. Likewise, if we are meeting
800799one with whom we have never had the pleasure of acquainting ourselves,
801800we send a message to the console to that effect.
@@ -849,7 +848,7 @@ send the result to `++chow` for interpretation and handling.
849848 (chow(aut sin) ((hard meal) (cue (dy:q:sen:gus key bod))))
850849```
851850
852−For symmetric encryption, we first get the `hand`, which is the hash of
851+For symmetric encryption, we first get the `++hand`, which is the hash of
853852the symmetric key. We pass it to `++kuch:lax:as:go`, which returns the
854853key if we either have used it before or we have proposed it. If we have
855854proposed it, then we change its status from proposed to real. If
@@ -1024,7 +1023,7 @@ message, then we resend the ack. Note that `did.rum` is the number of
10241023packets we acknowledged, positively or negatively while `bum.rum` is a
10251024map of message numbers to negative acknowledgments. Thus, if a message
10261025number is less than `did.rum`, then if it's in `bum.rum` then it was
1027−negatively acknowledged, otherwise it's postively acknowledged. Thus, we
1026+negatively acknowledged, otherwise it's positively acknowledged. Thus, we
10281027are constant in space with the number of successful messages and linear
10291028in the number of failed messages. We'll document `++cook` later on, but
10301029suffice it to say that it sends an acknowledgment. It is to end-to-end
@@ -1054,7 +1053,7 @@ Otherwise, we're ready for a packet, so we process it.
10541053 :_ bin
10551054 :^ %mulk
10561055 [our her]
1057− `soap`[[p:sen:gus clon:diz] cha did.rum]
1056+ `soap:ames`[[p:sen:gus clon:diz] cha did.rum]
10581057 u.s.u.cun
10591058 ==
10601059```
@@ -1563,71 +1562,7 @@ involved.
15631562
15641563## Data Models
15651564
1566−### `++fort`, formal state
1567−
1568−```
1569− ++ fort :: formal state
1570− $: %0 :: version
1571− gad=duct :: client interface
1572− hop=@da :: network boot date
1573− ton=town :: security
1574− zac=(map ship corn) :: flows by server
1575− == ::
1576−```
1577−
1578−This is the state of our vane. Anything that must be remembered between
1579−calls to ames must be stored in this state.
1580−
1581−`%0` is the version of the ames state model itself. If the data model
1582−`++fort` changes, then this number needs to be incremented, and an
1583−adapter must be written to upgrade the old state into the new state.
1584−Note that this is the version number of the model itself, not the
1585−contents. When the data changes, there is of course no need to change
1586−this.
1587−
1588−`gad` is a `duct` over which we send `%send` cards to unix. This card is
1589−initialized when unix sends a `%barn` card as vere starts up. Vere
1590−treats this duct specially -- don't send anything weird over it.
1591−
1592−`hop` is the network boot date. This is set when the `%kick` card is
1593−sent by vere on start up.
1594−
1595−`ton` is a `++town`, where we store all of our security/encryption
1596−state. Note that this is shared across all ships on a pier.
1597−
1598−`zac` is a map of ships to `++corn`. This stores all the per-ship state.
1599−The keys to this map are the ships on the current pier.
1600−
1601−### `++town`, all security state
1602−
1603−```
1604− ++ town :: all security state
1605− $: lit=@ud :: imperial modulus
1606− any=@ :: entropy
1607− urb=(map ship sufi) :: all keys and routes
1608− fak=? ::
1609− == ::
1610−```
1611−
1612−This is the security state of our pier.
1613−
1614−`lit` is unused.
1615−
1616−`any` is 256 bits of entropy. This entropy is used and updated in
1617−exactly two places: when we send a `%junk` card, and when we generate a
1618−new symmetric key in `++griz:lax:as:go`. When it is updated, it is
1619−updated by a SHA-256 hash of the current time and the old value of the
1620−entropy.
1621−
1622−`urb` is a map of ships to `++sufi`. This is where we store all the
1623−per-ship state for the pier. The keys to this map are the ships on the
1624−current pier.
1625−
1626−`fak` is true if we are on a fake network. This disables certain
1627−security checks so that anyone may run a fake `~zod`. This is used only
1628−for development. To use, run vere with the `-F` option.
1629−
1630−### `++sufi`, domestic host
1565+### `++sufi:ames`, domestic host
16311566
16321567```
16331568 ++ sufi :: domestic host
@@ -1643,7 +1578,7 @@ This is the security state of a domestic server.
16431578
16441579`hoy` is a list of the ships directly above us in the hierarchy of
16451580ships. For example, for `~hoclur-bicrel`, this would be `~tasruc` and
1646−`~tug`. See `++sein`.
1581+`~tug`. See `++sein:title`.
16471582
16481583`val` is a list of our private keys.
16491584
@@ -1651,20 +1586,20 @@ ships. For example, for `~hoclur-bicrel`, this would be `~tasruc` and
16511586
16521587`seh`
16531588
1654−`hoc` is a map of ships to `++dore`. The stores all the security
1655−informatoin about foreign ships. The keys to this map are the neighbors
1589+`hoc` is a map of ships to `++dore:ames`. The stores all the security
1590+information about foreign ships. The keys to this map are the neighbors
16561591(ships we have been in contact with) of this domestic server.
16571592
1658−### `++wund`, private keys
1593+### `++wund:ames`, private keys
16591594
16601595```
16611596 ++ wund (list ,[p=life q=ring r=acru]) :: mace in action
16621597```
16631598
16641599This is a list of our own private keys, indexed by life. The key itself
1665−is the `++ring`, and the `++acru` is the encryption engine. We generate
1666−the `++acru` from the private key by calling `++weur`. Thus, we can at
1667−any time regenerate our `++wund` from a `++mace`. The current crypto is
1600+is the `++ring`, and the `++acru:ames` is the encryption engine. We generate
1601+the `++acru:ames` from the private key by calling `++weur`. Thus, we can at
1602+any time regenerate our `++wund:ames` from a `++mace:ames`. The current crypto is
16681603at the head of the list and can be accessed with `++sen:as:go`.
16691604
16701605### `++ring`, private key
@@ -1675,7 +1610,7 @@ at the head of the list and can be accessed with `++sen:as:go`.
16751610
16761611This is a private key. The first byte is reserved to identify the type
16771612of cryptography. Lower-case means public key, upper-case means public
1678−key, and the letter identifies which `++acru` to use.
1613+key, and the letter identifies which `++acru:ames` to use.
16791614
16801615### `++pass`, public key
16811616
@@ -1685,18 +1620,18 @@ key, and the letter identifies which `++acru` to use.
16851620
16861621This is a public key. The first byte is reserved to identify the type of
16871622cryptography. Lower-case means public key, upper-case means public key,
1688−and the letter identifies which `++acru` to use.
1623+and the letter identifies which `++acru:ames` to use.
16891624
1690−### `++mace`, private secrets
1625+### `++mace:ames`, private secrets
16911626
16921627```
16931628 ++ mace (list ,[p=life q=ring]) :: private secrets
16941629```
16951630
16961631This is a list of the our private keys, indexed by life. From this we
1697−can generate a `++wund` for actual use.
1632+can generate a `++wund:ames` for actual use.
16981633
1699−### `++skin`, encoding stem
1634+### `++skin:ames`, encoding stem
17001635
17011636```
17021637 ++ skin ?(%none %open %fast %full) :: encoding stem
@@ -1705,9 +1640,9 @@ can generate a `++wund` for actual use.
17051640This defines the type of encryption used for each message. `%none`
17061641refers to messages sent in the clear, `%open` refers to signed messages,
17071642`%full` refers to sealed messages, and `%fast` refers to symmetrically
1708−encrypted messages. See `++acru` for details.
1643+encrypted messages. See `++acru:ames` for details.
17091644
1710−### `++acru`, asymmetric cryptosuite
1645+### `++acru:ames`, asymmetric cryptosuite
17111646
17121647```
17131648 ++ acru :: asym cryptosuite
@@ -1738,11 +1673,10 @@ encrypted messages. See `++acru` for details.
17381673
17391674This is an opaque interface for a general asymmetric cryptosuite. Any
17401675form of asymmetric cryptography can be dropped in to be used instead of
1741−the default. Right now, there are two cryptosuites, `++crua`, which is
1742−your standard RSA, and `++crub`, which is elliptic curve crypto but is
1743−mostly stubbed out at the moment.
1676+the default. Right now, there is one cryptosuite: `++crub:crypto:crypto`,
1677+which is elliptic-curve cryptography.
17441678
1745−#### `++as:acru`, asymmetric operations
1679+#### `++as:acru:ames`, asymmetric operations
17461680
17471681```
17481682 ++ as ^? :: asym ops
@@ -1757,29 +1691,29 @@ mostly stubbed out at the moment.
17571691This is the core that defines the standard asymmetric cryptography
17581692operations.
17591693
1760−`++seal:as:acru` allows us to send a message encrypted with someone's
1694+`++seal:as:acru:ames` allows us to send a message encrypted with someone's
17611695public key so that only they may read it. If Alice seals a message with
17621696Bob's public key, then she can be sure that Bob is the only one who can
1763−read it. This is associated with the `++skin` `%full`.
1697+read it. This is associated with the `++skin:ames` `%full`.
17641698
1765−`++sign:as:acru` allows us to sign a message with our private key so
1699+`++sign:as:acru:ames` allows us to sign a message with our private key so
17661700that others can verify that we sent the message. If Alice signs a
17671701message with her private key, then Bob can verify with her public key
17681702that it was indeed Alice who sent it. This is associated with the
1769−`++skin` `%open`.
1703+`++skin:ames` `%open`.
17701704
1771−`++sure:as:acru` is the dual to `++sign:as:acru`. It allows us to verify
1705+`++sure:as:acru:ames` is the dual to `++sign:as:acru:ames`. It allows us to verify
17721706that a message we have received is indeed from the claimed sender. If
17731707Alice sends a message with her private key, then Bob can use this arm to
17741708verify that it was indeed Alice who sent it. This is associated with the
1775−`++skin` `%open`.
1709+`++skin:ames` `%open`.
17761710
1777−`++tear:as:acru` is the dual to `++seal:as:acru`. It allows us to read a
1711+`++tear:as:acru:ames` is the dual to `++seal:as:acru:ames`. It allows us to read a
17781712message that we can be sure is only read by us. If Alice seals a message
17791713with Bob's public key, then Bob can use this arm to read it. This is
1780−associated with the `++skin` `%full`.
1714+associated with the `++skin:ames` `%full`.
17811715
1782−#### `++de:acru`, `++dy:acru`, and `++en:acru`, symmetric encryption/decryption
1716+#### `++de:acru:ames`, `++dy:acru:ames`, and `++en:acru:ames`, symmetric encryption/decryption
17831717
17841718```
17851719 ++ de |+([a=@ b=@] *(unit ,@)) :: symmetric de, soft
@@ -1787,18 +1721,18 @@ associated with the `++skin` `%full`.
17871721 ++ en |+([a=@ b=@] _@) :: symmetric en
17881722```
17891723
1790−Symmetric encryption is associated with the `++skin` `%fast`.
1724+Symmetric encryption is associated with the `++skin:ames` `%fast`.
17911725
1792−`++de:acru` decrypts a message with a symmetric key, returning `~` on
1726+`++de:acru:ames` decrypts a message with a symmetric key, returning `~` on
17931727failure and `[~ u=data]` on success.
17941728
1795−`++dy:acru` decrypts a message with a symmetric key, crashing on
1729+`++dy:acru:ames` decrypts a message with a symmetric key, crashing on
17961730failure. This should almost always be defined as, and should always be
17971731semantically equivalent to, `(need (de a b))`.
17981732
1799−`++en:acru` encrypts a message with a symmetric key.
1733+`++en:acru:ames` encrypts a message with a symmetric key.
18001734
1801−#### `++ex:acru`, exporting data
1735+#### `++ex:acru:ames`, exporting data
18021736
18031737```
18041738 ++ ex ^? :: export
@@ -1809,18 +1743,18 @@ semantically equivalent to, `(need (de a b))`.
18091743 --
18101744```
18111745
1812−`++fig:ex:acru` is our fingerprint, usually a hash of our public key.
1746+`++fig:ex:acru:ames` is our fingerprint, usually a hash of our public key.
18131747This is used, for example, in `++zeno`, where every carrier owner's
18141748fingerprint is stored so that we can ensure that carriers are indeed
18151749owned by their owners
18161750
1817−`++pac:ex:acru` is our default passcode, which is unused at present.
1751+`++pac:ex:acru:ames` is our default passcode, which is unused at present.
18181752
1819−`++pub:ex:acru` is the `++pass` form of our public key.
1753+`++pub:ex:acru:ames` is the `++pass` form of our public key.
18201754
1821−`++sec:ex:acru` is the `++ring` form of our private key.
1755+`++sec:ex:acru:ames` is the `++ring` form of our private key.
18221756
1823−#### `++nu:acru`, reconstructors
1757+#### `++nu:acru:ames`, reconstructors
18241758
18251759```
18261760 ++ nu ^? :: reconstructors
@@ -1830,21 +1764,17 @@ owned by their owners
18301764 --
18311765```
18321766
1833−These arms allow us to reconstruct a `++acru` from basic data.
1767+These arms allow us to reconstruct a `++acru:ames` from basic data.
18341768
1835−`++pit:nu:acru` constructs a `++acru` from the width of our intended key
1769+`++pit:nu:acru:ames` constructs a `++acru:ames` from the width of our intended key
18361770and seed entropy. This is usually used in the initial construction of
1837−the `++acru`.
1771+the `++acru:ames`.
18381772
1839−`++nol:nu:acru` constructs a `++acru` from a "naked ring", meaning a
1840−`++ring` without the initial byte identifying the type of crypto. There
1841−is often a helper arm that that wraps this; see `++weur` for `++crua`
1842−and `++wear` for `++crub`.
1773+`++nol:nu:acru:ames` constructs a `++acru:ames` from a "naked ring", meaning a
1774+`++ring` without the initial byte identifying the type of crypto.
18431775
1844−`++com:nu:acru` constructs a `++acru` from a "naked pass", meaning a
1845−`++ring` without the initial byte identifying the type of crypto. There
1846−is often a helper arm that that wraps this; see `++haul` for `++crua`
1847−and `++hail` for `++crub`.
1776+`++com:nu:acru:ames` constructs a `++acru:ames` from a "naked pass", meaning a
1777+`++ring` without the initial byte identifying the type of crypto.
18481778
18491779### `++will`, certificate
18501780
@@ -1874,7 +1804,7 @@ issued \~tasruc's deed).
18741804that the carrier fingerprints are correct. This allows us to create fake
18751805networks for development without interfering with the real network.
18761806
1877−### `++step`, identity stage
1807+### `++step:ames`, identity stage
18781808
18791809```
18801810 ++ step ,[p=bray q=gens r=pass] :: identity stage
@@ -1890,7 +1820,7 @@ lives.
18901820
18911821`r` is the public key for this stage in the identity.
18921822
1893−### `++bray`
1823+### `++bray:ames`
18941824
18951825```
18961826 ++ bray ,[p=life q=(unit life) r=ship s=@da] :: our parent us now
@@ -1898,7 +1828,7 @@ lives.
18981828
18991829XXX
19001830
1901−### `++gens`, general identity
1831+### `++gens:ames`, general identity
19021832
19031833```
19041834 ++ gens ,[p=lang q=gcos] :: general identity
@@ -1910,7 +1840,7 @@ localized based on this.
19101840
19111841`q` is the description of the ship.
19121842
1913−### `++gcos`, identity description
1843+### `++gcos:ames`, identity description
19141844
19151845```
19161846 ++ gcos :: id description
@@ -1949,7 +1879,7 @@ negligible, so submarines are not issued by any ship. They must simply
19491879assert their presence, and they are all considered children of \~zod.
19501880This is the underworld of Urbit, where anonymity reigns supreme.
19511881
1952−### `++what`, logical destroyer identity
1882+### `++what:ames`, logical destroyer identity
19531883
19541884```
19551885 ++ what :: logical identity
@@ -1973,7 +1903,7 @@ A `%lord` is a male person. The name used here should be a real name.
19731903
19741904A `%punk` is a person who is identified only by a handle.
19751905
1976−### `++whom`, real person
1906+### `++whom:ames`, real person
19771907
19781908```
19791909 ++ whom ,[p=@ud q=govt r=sect s=name] :: year/govt/id
@@ -1990,7 +1920,7 @@ information that could be observed with the briefest of interactions.
19901920
19911921`s` is the real name of the person.
19921922
1993−### `++govt`
1923+### `++govt:ames`
19941924
19951925```
19961926 ++ govt path :: country/postcode
@@ -1998,7 +1928,7 @@ information that could be observed with the briefest of interactions.
19981928
19991929This is the location of the user, usually of the form "country/zip".
20001930
2001−### `++sect`
1931+### `++sect:ames`
20021932
20031933```
20041934 ++ sect ?(%black %blue %red %orange %white) :: banner
@@ -2006,7 +1936,7 @@ This is the location of the user, usually of the form "country/zip".
20061936
20071937XXX
20081938
2009−### `++name`
1939+### `++name:ames`
20101940
20111941```
20121942 ++ name ,[p=@t q=(unit ,@t) r=(unit ,@t) s=@t] :: first mid/nick last