d277c47 · urbit.org · git.iko.soy

git.iko.soy/urbit.org

on master help sign in

Merge pull request #368 from urbit/zuse-update

d277c47David Kerschner8 years ago

learn/arvo/arvo-internals/ames.udon+74−144

compare with master

unifiedsplit

@@ -102,8 +102,7 @@ that is sent over the wire, so be careful not to send anything too

102massive unless you're willing to wait.

103

104But enough about the interface. Grepping in ames.hoon for `%wont`, we

105−find that it appears in exactly two places: at its definition in

105+find that it appears in `++knob`. We see that we go

106−`++kiss`, and in `++knob`, where it is handled. We see that we go

107directly into `++wise:am`.

106directly into `++wise:am`.

108

107

109```

108```

@@ -152,11 +151,11 @@ This is slightly more complicated, but it's still not all that bad. Our

152inputs, at least, are fairly obvious.

151inputs, at least, are fairly obvious.

153

152

154If you glance at the code for a second, you'll see that

153If 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

156a `++soup`. This gate, then, just sets up the things we need to for

155a `++soup`. This gate, then, just sets up the things we need to for

157`++wind` to do its job.

156`++wind` to do its job.

158

157

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

160stream. This stream is specific to the path on which we're sending. If

159stream. This stream is specific to the path on which we're sending. If

161the path hasn't been used before, then we create it. We let `sex` be the

160the path hasn't been used before, then we create it. We let `sex` be the

162number of messages we've already sent on this path.

161number 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

171into the meal.

170into the meal.

172

171

173Finally, we call `++wind:ho:um:am` with the `++soup` of the path and

172Finally, 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

175acknowledged messages, we use `%bund`.

174acknowledged messages, we use `%bund`.

176

175

177```

176```

@@ -199,7 +198,7 @@ and (3) sends any packets that are ready to be sent. Yes, our nice

199little linear run of each gate calling exactly one other interesting

198little linear run of each gate calling exactly one other interesting

200gate is over. We'll go in order here.

199gate is over. We'll go in order here.

201

200

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

203actual, 1KB packets.

202actual, 1KB packets.

204

203

205```

204```

@@ -403,7 +402,7 @@ the ship names in a packet.

403

402

404Next, we construct `bod` by simply concatenating the sending ship, the

403Next, we construct `bod` by simply concatenating the sending ship, the

405receiving ship, and the body of the message. Then, we get the encryption

404receiving 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

407`tay`.

406`tay`.

408

407

409Next, we concatenate together, bit by bit, some final metadata. We use

408Next, 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

457packets that have not yet been acknowledged, which is of course the

456packets that have not yet been acknowledged, which is of course the

458total number of packets since we haven't even sent the packets.

457total number of packets since we haven't even sent the packets.

459

458

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

461packet pump: (1) we increment `nus`, the number of packets sent; (2) we

460packet pump: (1) we increment `nus`, the number of packets sent; (2) we

462put the packet number into `diq` keyed by a hash of the packet; and (3)

461put the packet number into `diq` keyed by a hash of the packet; and (3)

463we put the packet into the packet queue, with the basic metadata of its

462we 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

573and our neighbor, respectively.

572and our neighbor, respectively.

574

573

575What is this "canon", you ask? A canon is simply a ship plus its

574What 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

577`~hoclur-bicrel` is:

576`~hoclur-bicrel` is:

578

577

579```

578```

580− ~hoclur-bicrel/try=> (saxo ~hoclur-bicrel)

579+ ~hoclur-bicrel/try=> (saxo:title ~hoclur-bicrel)

581 ~[~hoclur-bicrel ~tasruc ~tug]

580 ~[~hoclur-bicrel ~tasruc ~tug]

582```

581```

583

582

@@ -605,7 +604,7 @@ Now, we can finally get to `++busk:ho:um:am`.

605```

604```

606

605

607Thankfully, `++busk` is fairly simple. We go through the list of packets

606Thankfully, `++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

609placed into `bin`, and they end up getting processed by `++clop` (this

608placed into `bin`, and they end up getting processed by `++clop` (this

610happens in `++knob`).

609happens in `++knob`).

611

610

@@ -637,7 +636,7 @@ happens in `++knob`).

637 :- %fast

636 :- %fast

638 %^ cat 7

637 %^ cat 7

639 p.u.yed.caq.dyr

638 p.u.yed.caq.dyr

640− (en:crua q.u.yed.caq.dyr mal)

639+ (en:crub:crypto q.u.yed.caq.dyr mal)

641 ==

640 ==

642```

641```

643

642

@@ -648,9 +647,9 @@ First, if we are sending a message to ourself, then we simply create a

648`%ouzo` boon with a bunted lane. Otherwise, if there are no routing

647`%ouzo` boon with a bunted lane. Otherwise, if there are no routing

649candidates, there is nothing we can do, so we return nil.

648candidates, there is nothing we can do, so we return nil.

650

649

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

652at the neighbor to whom we're trying to send the message, then we simply

651at 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`.

654

653

655If we're the first routing candidate, or if we have don't have a lane to

654If we're the first routing candidate, or if we have don't have a lane to

656this candidate, then we skip this candidate and move on to the next one.

655this 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

660only send on this one candidate.

659only send on this one candidate.

661

660

662Finally, we create the actual `%ouzo` boon. The lane is the one from our

661Finally, 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

664haven't been told to use a specific lane, then we just send the packet

663haven't been told to use a specific lane, then we just send the packet

665directly. Otherwise, we wrap it in a little `%fore` meal, telling the

664directly. Otherwise, we wrap it in a little `%fore` meal, telling the

666intermediary to whom we wish it to be sent. If we have already set up a

665intermediary to whom we wish it to be sent. If we have already set up a

@@ -705,7 +704,7 @@ earlier.

705Here, though, we call `++gnaw:am` to process the packet. The arguments

704Here, though, we call `++gnaw:am` to process the packet. The arguments

706to `++gnaw` are the same as those to the `%hear` kiss: the lane on which

705to `++gnaw` are the same as those to the `%hear` kiss: the lane on which

707the packet was received and the packet itself. The other argument is

706the 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

709succeed. If a formal error occurs, then since we have a transactional

708succeed. If a formal error occurs, then since we have a transactional

710event system, the `%hear` event will never be considered to have

709event system, the `%hear` event will never be considered to have

711actually happened, and unix will send a `%hole` kiss so that we may send

710actually happened, and unix will send a `%hole` kiss so that we may send

@@ -728,7 +727,7 @@ a negative acknowledgment.

728

727

729First, we check the protocol number. If it is not correct, then we

728First, we check the protocol number. If it is not correct, then we

730simply ignore the packet entirely. Otherwise, we parse the packet with

729simply 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

732of the `sock` (pair of sender and receiver), the `skin` (encryption

731of the `sock` (pair of sender and receiver), the `skin` (encryption

733type), and the data.

732type), and the data.

734

733

@@ -763,7 +762,7 @@ to these cores.

763

762

764The new stuff here, then, is the `++la` core and the `++chew` arm. The

763The new stuff here, then, is the `++la` core and the `++chew` arm. The

765`++la` sets up a core for this particular packet, containing the current

764`++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,

767and a hash of the packet, used as an id.

766and a hash of the packet, used as an id.

768

767

769`++chew` is called with the encryption type and the message itself. It

768`++chew` is called with the encryption type and the message itself. It

@@ -795,7 +794,7 @@ we'll go into in just a minute.

795

794

796We now do the same two checks and store the results in `eng` and `bou`.

795We now do the same two checks and store the results in `eng` and `bou`.

797If our neighbor has, like the prodigal son, returned after an extended

796If 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,

799which is simply printed out to the console. Likewise, if we are meeting

798which is simply printed out to the console. Likewise, if we are meeting

800one with whom we have never had the pleasure of acquainting ourselves,

799one with whom we have never had the pleasure of acquainting ourselves,

801we send a message to the console to that effect.

800we send a message to the console to that effect.

@@ -849,7 +848,7 @@ send the result to `++chow` for interpretation and handling.

849 (chow(aut sin) ((hard meal) (cue (dy:q:sen:gus key bod))))

848 (chow(aut sin) ((hard meal) (cue (dy:q:sen:gus key bod))))

850```

849```

851

850

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

853the symmetric key. We pass it to `++kuch:lax:as:go`, which returns the

852the symmetric key. We pass it to `++kuch:lax:as:go`, which returns the

854key if we either have used it before or we have proposed it. If we have

853key if we either have used it before or we have proposed it. If we have

855proposed it, then we change its status from proposed to real. If

854proposed 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

1024packets we acknowledged, positively or negatively while `bum.rum` is a

1023packets we acknowledged, positively or negatively while `bum.rum` is a

1025map of message numbers to negative acknowledgments. Thus, if a message

1024map of message numbers to negative acknowledgments. Thus, if a message

1026number is less than `did.rum`, then if it's in `bum.rum` then it was

1025number 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

1028are constant in space with the number of successful messages and linear

1027are constant in space with the number of successful messages and linear

1029in the number of failed messages. We'll document `++cook` later on, but

1028in the number of failed messages. We'll document `++cook` later on, but

1030suffice it to say that it sends an acknowledgment. It is to end-to-end

1029suffice 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.

1054 :_ bin

1053 :_ bin

1055 :^ %mulk

1054 :^ %mulk

1056 [our her]

1055 [our her]

1057− `soap`[[p:sen:gus clon:diz] cha did.rum]

1056+ `soap:ames`[[p:sen:gus clon:diz] cha did.rum]

1058 u.s.u.cun

1057 u.s.u.cun

1059 ==

1058 ==

1060```

1059```

@@ -1563,71 +1562,7 @@ involved.

1563

1562

1564## Data Models

1563## Data Models

1565

1564

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

1631

1566

1632```

1567```

1633 ++ sufi :: domestic host

1568 ++ sufi :: domestic host

@@ -1643,7 +1578,7 @@ This is the security state of a domestic server.

1643

1578

1644`hoy` is a list of the ships directly above us in the hierarchy of

1579`hoy` is a list of the ships directly above us in the hierarchy of

1645ships. For example, for `~hoclur-bicrel`, this would be `~tasruc` and

1580ships. For example, for `~hoclur-bicrel`, this would be `~tasruc` and

1646−`~tug`. See `++sein`.

1581+`~tug`. See `++sein:title`.

1647

1582

1648`val` is a list of our private keys.

1583`val` is a list of our private keys.

1649

1584

@@ -1651,20 +1586,20 @@ ships. For example, for `~hoclur-bicrel`, this would be `~tasruc` and

1651

1586

1652`seh`

1587`seh`

1653

1588

1654−`hoc` is a map of ships to `++dore`. The stores all the security

1589+`hoc` is a map of ships to `++dore:ames`. The stores all the security

1655−informatoin about foreign ships. The keys to this map are the neighbors

1590+information about foreign ships. The keys to this map are the neighbors

1656(ships we have been in contact with) of this domestic server.

1591(ships we have been in contact with) of this domestic server.

1657

1592

1658−### `++wund`, private keys

1593+### `++wund:ames`, private keys

1659

1594

1660```

1595```

1661 ++ wund (list ,[p=life q=ring r=acru]) :: mace in action

1596 ++ wund (list ,[p=life q=ring r=acru]) :: mace in action

1662```

1597```

1663

1598

1664This is a list of our own private keys, indexed by life. The key itself

1599This 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

1600+is the `++ring`, and the `++acru:ames` is the encryption engine. We generate

1666−the `++acru` from the private key by calling `++weur`. Thus, we can at

1601+the `++acru:ames` from the private key by calling `++weur`. Thus, we can at

1667−any time regenerate our `++wund` from a `++mace`. The current crypto is

1602+any time regenerate our `++wund:ames` from a `++mace:ames`. The current crypto is

1668at the head of the list and can be accessed with `++sen:as:go`.

1603at the head of the list and can be accessed with `++sen:as:go`.

1669

1604

1670### `++ring`, private key

1605### `++ring`, private key

@@ -1675,7 +1610,7 @@ at the head of the list and can be accessed with `++sen:as:go`.

1675

1610

1676This is a private key. The first byte is reserved to identify the type

1611This is a private key. The first byte is reserved to identify the type

1677of cryptography. Lower-case means public key, upper-case means public

1612of 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.

1679

1614

1680### `++pass`, public key

1615### `++pass`, public key

1681

1616

@@ -1685,18 +1620,18 @@ key, and the letter identifies which `++acru` to use.

1685

1620

1686This is a public key. The first byte is reserved to identify the type of

1621This is a public key. The first byte is reserved to identify the type of

1687cryptography. Lower-case means public key, upper-case means public key,

1622cryptography. 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.

1689

1624

1690−### `++mace`, private secrets

1625+### `++mace:ames`, private secrets

1691

1626

1692```

1627```

1693 ++ mace (list ,[p=life q=ring]) :: private secrets

1628 ++ mace (list ,[p=life q=ring]) :: private secrets

1694```

1629```

1695

1630

1696This is a list of the our private keys, indexed by life. From this we

1631This 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.

1698

1633

1699−### `++skin`, encoding stem

1634+### `++skin:ames`, encoding stem

1700

1635

1701```

1636```

1702 ++ skin ?(%none %open %fast %full) :: encoding stem

1637 ++ skin ?(%none %open %fast %full) :: encoding stem

@@ -1705,9 +1640,9 @@ can generate a `++wund` for actual use.

1705This defines the type of encryption used for each message. `%none`

1640This defines the type of encryption used for each message. `%none`

1706refers to messages sent in the clear, `%open` refers to signed messages,

1641refers to messages sent in the clear, `%open` refers to signed messages,

1707`%full` refers to sealed messages, and `%fast` refers to symmetrically

1642`%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.

1709

1644

1710−### `++acru`, asymmetric cryptosuite

1645+### `++acru:ames`, asymmetric cryptosuite

1711

1646

1712```

1647```

1713 ++ acru :: asym cryptosuite

1648 ++ acru :: asym cryptosuite

@@ -1738,11 +1673,10 @@ encrypted messages. See `++acru` for details.

1738

1673

1739This is an opaque interface for a general asymmetric cryptosuite. Any

1674This is an opaque interface for a general asymmetric cryptosuite. Any

1740form of asymmetric cryptography can be dropped in to be used instead of

1675form of asymmetric cryptography can be dropped in to be used instead of

1741−the default. Right now, there are two cryptosuites, `++crua`, which is

1676+the default. Right now, there is one cryptosuite: `++crub:crypto:crypto`,

1742−your standard RSA, and `++crub`, which is elliptic curve crypto but is

1677+which is elliptic-curve cryptography.

1743−mostly stubbed out at the moment.

1744

1678

1745−#### `++as:acru`, asymmetric operations

1679+#### `++as:acru:ames`, asymmetric operations

1746

1680

1747```

1681```

1748 ++ as ^? :: asym ops

1682 ++ as ^? :: asym ops

@@ -1757,29 +1691,29 @@ mostly stubbed out at the moment.

1757This is the core that defines the standard asymmetric cryptography

1691This is the core that defines the standard asymmetric cryptography

1758operations.

1692operations.

1759

1693

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

1761public key so that only they may read it. If Alice seals a message with

1695public key so that only they may read it. If Alice seals a message with

1762Bob's public key, then she can be sure that Bob is the only one who can

1696Bob'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`.

1764

1698

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

1766that others can verify that we sent the message. If Alice signs a

1700that others can verify that we sent the message. If Alice signs a

1767message with her private key, then Bob can verify with her public key

1701message with her private key, then Bob can verify with her public key

1768that it was indeed Alice who sent it. This is associated with the

1702that it was indeed Alice who sent it. This is associated with the

1769−`++skin` `%open`.

1703+`++skin:ames` `%open`.

1770

1704

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

1772that a message we have received is indeed from the claimed sender. If

1706that a message we have received is indeed from the claimed sender. If

1773Alice sends a message with her private key, then Bob can use this arm to

1707Alice sends a message with her private key, then Bob can use this arm to

1774verify that it was indeed Alice who sent it. This is associated with the

1708verify that it was indeed Alice who sent it. This is associated with the

1775−`++skin` `%open`.

1709+`++skin:ames` `%open`.

1776

1710

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

1778message that we can be sure is only read by us. If Alice seals a message

1712message that we can be sure is only read by us. If Alice seals a message

1779with Bob's public key, then Bob can use this arm to read it. This is

1713with 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`.

1781

1715

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

1783

1717

1784```

1718```

1785 ++ de |+([a=@ b=@] *(unit ,@)) :: symmetric de, soft

1719 ++ de |+([a=@ b=@] *(unit ,@)) :: symmetric de, soft

@@ -1787,18 +1721,18 @@ associated with the `++skin` `%full`.

1787 ++ en |+([a=@ b=@] _@) :: symmetric en

1721 ++ en |+([a=@ b=@] _@) :: symmetric en

1788```

1722```

1789

1723

1790−Symmetric encryption is associated with the `++skin` `%fast`.

1724+Symmetric encryption is associated with the `++skin:ames` `%fast`.

1791

1725

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

1793failure and `[~ u=data]` on success.

1727failure and `[~ u=data]` on success.

1794

1728

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

1796failure. This should almost always be defined as, and should always be

1730failure. This should almost always be defined as, and should always be

1797semantically equivalent to, `(need (de a b))`.

1731semantically equivalent to, `(need (de a b))`.

1798

1732

1799−`++en:acru` encrypts a message with a symmetric key.

1733+`++en:acru:ames` encrypts a message with a symmetric key.

1800

1734

1801−#### `++ex:acru`, exporting data

1735+#### `++ex:acru:ames`, exporting data

1802

1736

1803```

1737```

1804 ++ ex ^? :: export

1738 ++ ex ^? :: export

@@ -1809,18 +1743,18 @@ semantically equivalent to, `(need (de a b))`.

1809 --

1743 --

1810```

1744```

1811

1745

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.

1813This is used, for example, in `++zeno`, where every carrier owner's

1747This is used, for example, in `++zeno`, where every carrier owner's

1814fingerprint is stored so that we can ensure that carriers are indeed

1748fingerprint is stored so that we can ensure that carriers are indeed

1815owned by their owners

1749owned by their owners

1816

1750

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.

1818

1752

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.

1820

1754

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.

1822

1756

1823−#### `++nu:acru`, reconstructors

1757+#### `++nu:acru:ames`, reconstructors

1824

1758

1825```

1759```

1826 ++ nu ^? :: reconstructors

1760 ++ nu ^? :: reconstructors

@@ -1830,21 +1764,17 @@ owned by their owners

1830 --

1764 --

1831```

1765```

1832

1766

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.

1834

1768

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

1836and seed entropy. This is usually used in the initial construction of

1770and seed entropy. This is usually used in the initial construction of

1837−the `++acru`.

1771+the `++acru:ames`.

1838

1772

1839−`++nol:nu:acru` constructs a `++acru` from a "naked ring", meaning a

1773+`++nol:nu:acru:ames` constructs a `++acru:ames` from a "naked ring", meaning a

1840−`++ring` without the initial byte identifying the type of crypto. There

1774+`++ring` without the initial byte identifying the type of crypto.

1841−is often a helper arm that that wraps this; see `++weur` for `++crua`

1842−and `++wear` for `++crub`.

1843

1775

1844−`++com:nu:acru` constructs a `++acru` from a "naked pass", meaning a

1776+`++com:nu:acru:ames` constructs a `++acru:ames` from a "naked pass", meaning a

1845−`++ring` without the initial byte identifying the type of crypto. There

1777+`++ring` without the initial byte identifying the type of crypto.

1846−is often a helper arm that that wraps this; see `++haul` for `++crua`

1847−and `++hail` for `++crub`.

1848

1778

1849### `++will`, certificate

1779### `++will`, certificate

1850

1780

@@ -1874,7 +1804,7 @@ issued \~tasruc's deed).

1874that the carrier fingerprints are correct. This allows us to create fake

1804that the carrier fingerprints are correct. This allows us to create fake

1875networks for development without interfering with the real network.

1805networks for development without interfering with the real network.

1876

1806

1877−### `++step`, identity stage

1807+### `++step:ames`, identity stage

1878

1808

1879```

1809```

1880 ++ step ,[p=bray q=gens r=pass] :: identity stage

1810 ++ step ,[p=bray q=gens r=pass] :: identity stage

@@ -1890,7 +1820,7 @@ lives.

1890

1820

1891`r` is the public key for this stage in the identity.

1821`r` is the public key for this stage in the identity.

1892

1822

1893−### `++bray`

1823+### `++bray:ames`

1894

1824

1895```

1825```

1896 ++ bray ,[p=life q=(unit life) r=ship s=@da] :: our parent us now

1826 ++ bray ,[p=life q=(unit life) r=ship s=@da] :: our parent us now

@@ -1898,7 +1828,7 @@ lives.

1898

1828

1899XXX

1829XXX

1900

1830

1901−### `++gens`, general identity

1831+### `++gens:ames`, general identity

1902

1832

1903```

1833```

1904 ++ gens ,[p=lang q=gcos] :: general identity

1834 ++ gens ,[p=lang q=gcos] :: general identity

@@ -1910,7 +1840,7 @@ localized based on this.

1910

1840

1911`q` is the description of the ship.

1841`q` is the description of the ship.

1912

1842

1913−### `++gcos`, identity description

1843+### `++gcos:ames`, identity description

1914

1844

1915```

1845```

1916 ++ gcos :: id description

1846 ++ gcos :: id description

@@ -1949,7 +1879,7 @@ negligible, so submarines are not issued by any ship. They must simply

1949assert their presence, and they are all considered children of \~zod.

1879assert their presence, and they are all considered children of \~zod.

1950This is the underworld of Urbit, where anonymity reigns supreme.

1880This is the underworld of Urbit, where anonymity reigns supreme.

1951

1881

1952−### `++what`, logical destroyer identity

1882+### `++what:ames`, logical destroyer identity

1953

1883

1954```

1884```

1955 ++ what :: logical identity

1885 ++ what :: logical identity

@@ -1973,7 +1903,7 @@ A `%lord` is a male person. The name used here should be a real name.

1973

1903

1974A `%punk` is a person who is identified only by a handle.

1904A `%punk` is a person who is identified only by a handle.

1975

1905

1976−### `++whom`, real person

1906+### `++whom:ames`, real person

1977

1907

1978```

1908```

1979 ++ whom ,[p=@ud q=govt r=sect s=name] :: year/govt/id

1909 ++ 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.

1990

1920

1991`s` is the real name of the person.

1921`s` is the real name of the person.

1992

1922

1993−### `++govt`

1923+### `++govt:ames`

1994

1924

1995```

1925```

1996 ++ govt path :: country/postcode

1926 ++ govt path :: country/postcode

@@ -1998,7 +1928,7 @@ information that could be observed with the briefest of interactions.

1998

1928

1999This is the location of the user, usually of the form "country/zip".

1929This is the location of the user, usually of the form "country/zip".

2000

1930

2001−### `++sect`

1931+### `++sect:ames`

2002

1932

2003```

1933```

2004 ++ sect ?(%black %blue %red %orange %white) :: banner

1934 ++ sect ?(%black %blue %red %orange %white) :: banner

@@ -2006,7 +1936,7 @@ This is the location of the user, usually of the form "country/zip".

2006

1936

2007XXX

1937XXX

2008

1938

2009−### `++name`

1939+### `++name:ames`

2010

1940

2011```

1941```

2012 ++ name ,[p=@t q=(unit ,@t) r=(unit ,@t) s=@t] :: first mid/nick last

1942 ++ name ,[p=@t q=(unit ,@t) r=(unit ,@t) s=@t] :: first mid/nick last

learn/arvo/arvo-internals/clay.udon+46−46

@@ -1,4 +1,4 @@

1−:- :~ navhome/'/docs/'

1+rang:clay`case:clay`:- :~ navhome/'/docs/'

2 navuptwo/'true'

3 next/'true'

4 sort/'3'

@@ -478,7 +478,7 @@ at least skimming, this so that you get a rough idea of how our state is

478organized.

479

480The types that are certainly worth reading are `++raft`, `++room`,

481−`++dome`, `++ankh`, `++rung`, `++rang`, `++blob`, `++yaki`, and `++nori`

481+`++dome:clay`, `++ankh:clay`, `++rung:clay`, `++rang:clay`, `++blob:clay`, `++yaki:clay`, and `++nori:clay`

482(possibly in that order). All in all, though, this section isn't too

483long, so many readers may wish to quickly read through all of it. If you

484get bored, though, just skip to the next section. You can always come

@@ -562,7 +562,7 @@ ducts from where the subscriptions requests came. The results will be

562produced along these ducts. The values are a description of the

563requested information.

564

565−#### `++rave`, general subscription request

565+#### `++rave:clay`, general subscription request

566

567```

568 ++ rave :: general request

@@ -585,7 +585,7 @@ When we store a request, we store subscriptions with a little extra

585information so that we can determine whether new versions actually

586affect the path we're subscribed to.

587

588−#### `++mood`, single subscription request

588+#### `++mood:clay`, single subscription request

589

590```

591 ++ mood ,[p=care q=case r=path] :: request in desk

@@ -595,7 +595,7 @@ This represents a request for the state of the desk at a particular

595commit, specfied by `q`. `p` specifies what kind of information is

596desired, and `r` specifies the path we are requesting.

597

598−#### `++moat`, range subscription request

598+#### `++moat:clay`, range subscription request

599

600```

601 ++ moat ,[p=case q=case r=path] :: change range

@@ -611,12 +611,12 @@ by the path or to any of its children.

611 ++ moot ,[p=case q=case r=path s=(map path lobe)] ::

612```

613

614−This is just a `++moat` plus a map of paths to lobes. This map

614+This is just a `++moat:clay` plus a map of paths to lobes. This map

615represents the data at the node referenced by the path at case `p`, if

616we've gotten to that case (else null). We only send a notification along

617the subscription if the data at a new revision is different than it was.

618

619−### ` `++care`, clay submode

619+### `++care:clay`, clay submode

620

621```

622 ++ care ?(%u %v %w %x %y %z) :: clay submode

@@ -625,11 +625,11 @@ the subscription if the data at a new revision is different than it was.

625This specifies what type of information is requested in a subscription

626or a scry.

627

628−`%u` requests the `++rang` at the current moment. Because this

628+`%u` requests the `++rang:clay` at the current moment. Because this

629information is not stored for any moment other than the present, we

630−crash if the `++case` is not a `%da` for now.

630+crash if the `++case:clay` is not a `%da` for now.

631

632−`%v` requests the `++dome` at the specified commit.

632+`%v` requests the `++dome:clay` at the specified commit.

633

634`%w` requests the revsion number of the desk.

635

@@ -647,7 +647,7 @@ if `q:ankh` is null), then this produces null.

647 ++ arch ,[p=@uvI q=(unit ,@uvI) r=(map ,@ta ,~)] :: fundamental node

648```

649

650−This is analogous to `++ankh` except that the we have neither our

650+This is analogous to `++ankh:clay` except that the we have neither our

651contents nor the ankhs of our children. The other fields are exactly the

652same, so `p` is a hash of the associated ankh, `u.q`, if it exists, is a

653hash of the contents of this node, and the keys of `r` are the names of

@@ -655,7 +655,7 @@ our children. `r` is a map to null rather than a set so that the

655ordering of the map will be equivalent to that of `r:ankh`, allowing

656efficient conversion.

657

658−#### `++case`, specifying a commit

658+#### `++case:clay`, specifying a commit

659

660```

661 ++ case :: ship desk case spur

@@ -669,9 +669,9 @@ A commit can be referred to in three ways: `%da` refers to the commit

669that was at the head on date `p`, `%tas` refers to the commit labeled

670`p`, and `%ud` refers to the commit numbered `p`. Note that since these

671all can be reduced down to a `%ud`, only numbered commits may be

672−referenced with a `++case`.

672+referenced with a `++case:clay`.

673

674−#### `++dome`, desk data

674+#### `++dome:clay`, desk data

675

676```

677 ++ dome :: project state

@@ -695,7 +695,7 @@ commit.

695the total number of numbered commits.

696

697`hit` is a map of numerical ids to hashes of commits. These hashes are

698−mapped into their associated commits in `hut:rang`. In general, the keys

698+mapped into their associated commits in `hut:rang:clay`. In general, the keys

699of this map are exactly the numbers from 1 to `let`, with no gaps. Of

700course, when there are no numbered commits, `let` is 0, so `hit` is

701null. Additionally, each of the commits is an ancestor of every commit

@@ -805,14 +805,14 @@ satisfied.

805`fod` is the same set as `bom`, but from a different perspective. In

806particular, the values of `fod` are the same as the values of `bom`, and

807the `p` out of the values of `bom` are the same as the keys of `fod`.

808−Thus, we can map ducts to their associated request number and `++rave`,

808+Thus, we can map ducts to their associated request number and `++rave:clay`,

809−and we can map numbers to their associated duct and `++rave`.

809+and we can map numbers to their associated duct and `++rave:clay`.

810

811`haw` is a map from simple requests to their values. This acts as a

812cache for requests that have already been made. Thus, the second request

813−for a particular `++mood` is nearly instantaneous.

813+for a particular `++mood:clay` is nearly instantaneous.

814

815−#### `++rang`, data store

815+#### `++rang:clay`, data store

816

817```

818 ++ rang $: hut=(map tako yaki) ::

@@ -825,25 +825,25 @@ is stored, but it is only meaningful if we know the hash of what we're

825looking for.

826

827`hut` is a map from hashes to commits. We often get the hashes from

828−`hit:dome`, which keys them by logical id. Not every commit has an id.

828+`hit:dome:clay`, which keys them by logical id. Not every commit has an id.

829

830`lat` is a map from hashes to the actual data. We often get the hashes

831from a `++yaki`, a commit, which references this map to get the data.

832−There is no `++blob` in any `++yaki`. They are only accessible through

832+There is no `++blob:clay` in any `++yaki:clay`. They are only accessible through

833this map.

834

835−#### `++tako`, commit reference

835+#### `++tako:clay`, commit reference

836

837```

838 ++ tako ,@ :: yaki ref

839```

840

841−This is a hash of a `++yaki`, a commit. These are most notably used as

841+This is a hash of a `++yaki:clay`, a commit. These are most notably used as

842−the keys in `hut:rang`, where they are associated with the actual

842+the keys in `hut:rang:clay`, where they are associated with the actual

843−`++yaki`, and as the values in `hit:dome`, where sequential ids are

843+`++yaki:clay`, and as the values in `hit:dome:clay`, where sequential ids are

844associated with these.

845

846−#### `++yaki`, commit

846+#### `++yaki:clay`, commit

847

848```

849 ++ yaki ,[p=(list tako) q=(map path lobe) r=tako t=@da] :: commit

@@ -858,24 +858,24 @@ practice merges have exactly two parents. This may change in the future.

858For commit 1, there is no parent.

859

860`q` is a map of the paths on a desk to the data at that location. If you

861−understand what a `++lobe` and a `++blob` is, then the type signature

861+understand what a `++lobe:clay` and a `++blob:clay` is, then the type signature

862here tells the whole story.

863

864`r` is the hash associated with this commit.

865

866`t` is the date at which this commit was made.

867

868−#### `++lobe`, data reference

868+#### `++lobe:clay`, data reference

869

870```

871 ++ lobe ,@ :: blob ref

872```

873

874−This is a hash of a `++blob`. These are most notably used in `lat:rang`,

874+This is a hash of a `++blob:clay`. These are most notably used in `lat:rang:clay`,

875−where they are associated with the actual `++blob`, and as the values in

875+where they are associated with the actual `++blob:clay`, and as the values in

876−`q:yaki`, where paths are associated with their data in a commit.

876+`q:yaki:clay`, where paths are associated with their data in a commit.

877

878−#### `++blob`, data

878+#### `++blob:clay`, data

879

880```

881 ++ blob $% [%delta p=lobe q=lobe r=udon] :: delta on q

@@ -993,7 +993,7 @@ This space intentionally left undocumented. This stuff is not known to

993work, and will likely change when we get a well-typed clay. Also, this

994is not a complicated type; it is not difficult to work out the meaning.

995

996−#### `++nori`, repository action

996+#### `++nori:clay`, repository action

997

998```

999 ++ nori :: repository action

@@ -1009,7 +1009,7 @@ we can apply a label to a commit.

1009In the `|` case, we will simply label the current commit with the given

1010label. In the `&` case, we will apply the given changes.

1011

1012−#### `++soba`, delta

1012+#### `++soba:clay`, delta

1013

1014```

1015 ++ soba ,[p=cart q=(list ,[p=path q=miso])] :: delta

@@ -1021,7 +1021,7 @@ of changes keyed by the file they're changing. Thus, the paths are paths

1021to files to be changed while `miso` is a description of the change

1022itself.

1023

1024−#### `++miso`, ankh delta

1024+#### `++miso:clay`, ankh delta

1025

1026```

1027 ++ miso :: ankh delta

@@ -1037,7 +1037,7 @@ We can delete a file, in which case `p` is the contents of the old file.

1037Finally, we can mutate that file, in which case the `udon` describes the

1038changes we are applying to the file.

1039

1040−#### `++mizu`, merged state

1040+#### `++mizu:clay`, merged state

1041

1042```

1043 ++ mizu ,[p=@u q=(map ,@ud tako) r=rang] :: new state

@@ -1051,7 +1051,7 @@ are to be inserted. The keys to this should always be the numbers from

1051commits and data. Since these are merged into the current state, no old

1052commits or data need be here.

1053

1054−#### `++riff`, request/desist

1054+#### `++riff:clay`, request/desist

1055

1056```

1057 ++ riff ,[p=desk q=(unit rave)] :: request/desist

@@ -1062,7 +1062,7 @@ contains a `rave`, then this opens a subscription to the desk for that

1062data. If `q` is null, then this tells clay to cancel the subscription

1063along this duct.

1064

1065−#### `++riot`, response

1065+#### `++riot:clay`, response

1066

1067```

1068 ++ riot (unit rant) :: response/complete

@@ -1072,7 +1072,7 @@ A riot is a response to a subscription. If null, the subscription has

1072been completed, and no more responses will be sent. Otherwise, the

1073`rant` is the produced data.

1074

1075−#### `++rant`, response data

1075+#### `++rant:clay`, response data

1076

1077```

1078 ++ rant :: namespace binding

@@ -1103,7 +1103,7 @@ of a desk. This allows us to easily keep track of a remote repository --

1103all the new information we need is contained in the `nako`.

1104

1105`gar` is a map of the revisions in the range to the hash of the commit

1106−at that revision. These hashes can be used with `hut:rang` to find the

1106+at that revision. These hashes can be used with `hut:rang:clay` to find the

1107commit itself.

1108

1109`let` is either the last revision number in the range or the most recent

@@ -1115,7 +1115,7 @@ revision number, whichever is smaller.

1115

1116As with all vanes, there are exactly two ways to interact with clay.

1117`%clay` exports a namespace accessible through `.^`, which is described

1118−above under `++care`. The primary way of interacting with clay, though,

1118+above under `++care:clay`. The primary way of interacting with clay, though,

1119is by sending kisses and receiving gifts.

1120

1121```

@@ -1150,7 +1150,7 @@ changes to the filesystem. Whenever we add, remove, or edit a file, one

1150of these cards is sent. The `p` is the ship whose filesystem we're

1151trying to change, the `q` is the desk we're changing, and the `r` is the

1152request change. For the format of the requested change, see the

1153−documentation for `++nori` above.

1153+documentation for `++nori:clay` above.

1154

1155When a file is changed in the unix filesystem, vere will send a `%into`

1156kiss. This tells clay that the duct over which the kiss was sent is the

@@ -1184,7 +1184,7 @@ filesystem for a ship.

1184This is called to perform a merge. This is most visibly called by

1185:update to update the filesystem of the current ship to that of its

1186sein. The `p` and `q` are as in `%info`, and the `r` is the description

1187−of the merge. See `++mizu` above.

1187+of the merge. See `++mizu:clay` above.

1188

1189XX

1190`XX [%wake ~] :: timer activate XX`

@@ -1209,7 +1209,7 @@ it into a `%warp`.

1209

1210This is a request for information about a particular desk. This is, in

1211its most general form, a subscription, though in many cases it is the

1212−trivial case of a subscription -- a read. See `++riff` for the format of

1212+trivial case of a subscription -- a read. See `++riff:clay` for the format of

1213the request.

1214

1215## Lifecycle of a Local Read

@@ -1433,7 +1433,7 @@ than the present. Since we don't store that information for any other

1433time, we can't produce it in a referentially transparent manner for any

1434time other than the present.

1435

1436−Then, we try to read the requested `mood` `p.rav`. If we can't access

1436+Then, we try to read the requested `mood:clay` `p.rav`. If we can't access

1437the request data right now, we call `++duce` to put the request in our

1438queue to be satisfied when the information becomes available.

1439

@@ -1555,7 +1555,7 @@ stored in `arvo/clay.hoon`. We examine `++case-to-aeon:ze`.

1555 ==

1556```

1557

1558−We handle each type of `case` differently. The latter two types are

1558+We handle each type of `case:clay` differently. The latter two types are

1559easy.

1560

1561If we're requesting a revision by label, then we simply look up the

learn/arvo/arvo-internals/ford.udon+3−3

@@ -545,11 +545,11 @@ Wide-form `/#` does not need a delimiter:

545At the moment, only HTTP requests forwarded by `%eyre` contain any extra arguments,

546and using this rune outside of that context will cause an error. Requests from `%eyre`

547contain an argument representing the query string, which can be parsed using the

548−standard library gate `++fuel`.

548+standard library gate `++fuel:html`.

549

550Example:

551```

552−/= gas /$ fuel

552+/= gas /$ fuel:html

553::

554:*

555 %who {<(~(get ju aut.ced.gas) 0)>}

@@ -560,7 +560,7 @@ Example:

560produces: [%who '~zod' %where /ford/pages/web %case 60]

561

562Wide-form `/$` takes its arguments inside brackets, like `/~`:

563−`/=gas=/$[fuel]`

563+`/=gas=/$[fuel:html]`

564

565### `/%` propagate extra arguments into renderers

566

learn/arvo/arvo-internals/gall.udon+2−2

@@ -768,7 +768,7 @@ be null here because we aren't doing any authentication; a mark, in this

768case the http request mark `&httr`; and some data in the form of a

769`cage`, which is a `[mark vase]`. This is confusing, so the mold in the

770code quoted above includes a bunch of otherwise unnecessary faces for

771−the purpose of illustration. Compare: `[%hiss p=(unit iden) q=mark

771+the purpose of illustration. Compare: `[%hiss p=(unit user) q=mark

772r=cage]` from `zuse`.

773

774> You can grep zuse.hoon and arvo.hoon for most of these definitions. However, beware the ambiguity surrounding "hiss": there's ++hiss in section 3bI of `zuse` ("Arvo structures"), and there's `%hiss` the move that is sent to %eyre to make our HTTP request happen. Here we're talking about the latter. See `++kiss-eyre` in `zuse`.

@@ -2002,7 +2002,7 @@ Thus, we're producing our state unchanged.

2002

2003Our list of moves is the result of a call to `++turn`. `++turn` is what many

2004languages call "map" -- it runs a function on every item in a list and collects

2005−the results in a list. The list is `(prey /example-path bow)` and the function

2005+the results in a list. The list is `(prey:pubsub:userlib /example-path bow)` and the function

2006is the `|=` line right after it.

2007

2008`prey:pubsub:userlib` is a standard library function defined in `zuse.hoon`. It takes a path

reference/library/2q.udon+1−1

@@ -105,7 +105,7 @@ which is a day atom and a time.

105

106#### Discussion

107

108−See also: [`year`](../3c), [`yore`](../3c) [`stud`](../2q), [`dust`](../2q)

108+See also: [`year`](../3c), [`yore`](../3c)

109

110---

111### `++knot`

reference/library/5f.udon+5−7

@@ -13,7 +13,7 @@

13XML name

15An XML name (tag name or attribute name) with an optional namespace. Parsed by

16−`++name` within `++poxa`, rendered by `++name` within `++poxo`.

16+`++name:de-xml:html` in `zuse.hoon`, rendered by `++name:en-xml:html` in `zuse.hoon`.

18#### Source

@@ -41,7 +41,7 @@ See also: `++sail`

42XML node.

44−Parsed by `++apex` within `++poxa`, rendered by `++poxo`.

44+Parsed by `++apex` within `++apex:de-xml:html` in `zuse.hoon`, rendered by `++apex:en-xml:html` in `zuse.hoon`.

46#### Source

@@ -72,13 +72,12 @@ A list of `++manx`.

75−

76---

75---

77### `++mars`

76### `++mars`

79XML CDATA

78XML CDATA

81−Implicitly produced by `++chrd` within `++poxa`

80+Implicitly produced by `++chrd` within `++chrd:de-xml:html`

83#### Source

82#### Source

@@ -98,7 +97,7 @@ List of XML attributes

98Each `++mart` is a list of pairs of `++mane` and

97Each `++mart` is a list of pairs of `++mane` and

99`++tape`.

98`++tape`.

100

101−Parsed by `++attr` within `++poxa`, rendered by `++attr` within `++poxo`

100+Parsed by `++attr:de-xml:html` in `zuse.hoon`, rendered by `++attr:en-xml:html` in `zuse.hoon`.

102

101

103#### Source

102#### Source

104

103

@@ -109,14 +108,13 @@ Parsed by `++attr` within `++poxa`, rendered by `++attr` within `++poxo`

109#### Examples

108#### Examples

110

109

111

110

112−

113---

111---

114### `++marx`

112### `++marx`

115

113

116XML tag

114XML tag

117

115

118A `++marx` is a pair of a tag name, `++mane` and a list of attributes,

116A `++marx` is a pair of a tag name, `++mane` and a list of attributes,

119−`++mart`. Parsed by `++head` `++poxa`, rendered within `++poxo`.

117+`++mart`. Parsed by `++head:de-xml:html` in `zuse.hoon`, rendered within `++de-xml:html` in `zuse.hoon`.

120

118

121#### Source

119#### Source

122

120