<p>There are two new proposed messages, <ttclass="docutils literal"><spanclass="pre">announce_item</span></tt> and <ttclass="docutils literal"><spanclass="pre">get_item</span></tt>.
Every valid item that is announced, should be stored.</p>
<divclass="section"id="terminology">
<h1>terminology</h1>
<p>In this document, a <em>storage node</em> refers to the node in the DHT to which
an item is being announce. A <em>subscribing node</em> refers to a node which
makes look ups in the DHT to find the storage nodes, to request items
from them.</p>
</div>
<divclass="section"id="linked-lists">
<h1>linked lists</h1>
<p>Items are chained together in a geneal singly linked list. A linked
list does not necessarily contain RSS items, and no RSS related items
are mandatory. However, RSS items will be used as examples in this BEP:</p>
<preclass="literal-block">
key = SHA1(name + key)
+---------+
| head | key = SHA1(bencode(item))
| +---------+ +---------+
| | next |-------->| item | key = SHA1(bencode(item))
| | key | | +---------+ +---------+
| | name | | | next |------->| item |
| | seq | | | key | | +---------+
| | ... | | | ... | | | next |--->0
| +---------+ | +---------+ | | key |
| sig | | sig | | | ... |
+---------+ +---------+ | +---------+
| sig |
+---------+
</pre>
<p>The <ttclass="docutils literal"><spanclass="pre">next</span></tt> pointer is at least 20 byte ID in the DHT key space pointing to where the next
item in the list is announced. The list is terminated with an ID of all zeroes.</p>
<p>The ID an items is announced to is determined by the SHA1 hash of the bencoded representation
of the item iteself. This contains all fields in the item, except the signature.
The only mandatory fields in an item are <ttclass="docutils literal"><spanclass="pre">next</span></tt>, <ttclass="docutils literal"><spanclass="pre">key</span></tt> and <ttclass="docutils literal"><spanclass="pre">sig</span></tt>.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">key</span></tt> field MUST match the public key of the list head node. The <ttclass="docutils literal"><spanclass="pre">sig</span></tt> field
MUST be the signature of the bencoded representation of <ttclass="docutils literal"><spanclass="pre">item</span></tt> or <ttclass="docutils literal"><spanclass="pre">head</span></tt> (whichever
is included in the message).</p>
<p>All subscribers MUST verify that the item is announced under the correct DHT key
and MUST verify the signature is valid and MUST verify the public key is the same
as the list-head. If a node fails any of these checks, it must be ignored and the
chain of items considered terminated.</p>
<p>Each item holds a bencoded dictionary with arbitrary keys, except two mandatory keys:
<ttclass="docutils literal"><spanclass="pre">next</span></tt> and <ttclass="docutils literal"><spanclass="pre">key</span></tt>. The signature <ttclass="docutils literal"><spanclass="pre">sig</span></tt> is transferred outside of this dictionary
and is the signature of all of it. An implementation should stora any arbitrary keys that
are announced to an item, within reasonable restriction such as nesting, size and numeric
range of integers.</p>
</div>
<divclass="section"id="skip-lists">
<h1>skip lists</h1>
<p>The <ttclass="docutils literal"><spanclass="pre">next</span></tt> key stored in the list head and the items is a string of at least length
20 bytes, it may be any length divisible by 20. Each 20 bytes are the ID of the next
item in the list, the item 2 hops away, 4 hops away, 8 hops away, and so on. For
simplicity, only the first ID (1 hop) in the <ttclass="docutils literal"><spanclass="pre">next</span></tt> field is illustrated above.</p>
<p>A publisher of an item SHOULD include as many IDs in the <ttclass="docutils literal"><spanclass="pre">next</span></tt> field as the remaining
size of the list warrants, within reason.</p>
<p>These skip lists allow for parallelized lookups of items and also makes it more efficient
to search for specific items. It also mitigates breaking lists missing some items.</p>
<p>Figure of the skip list in the first list item:</p>
<p>These are the messages to deal with linked lists.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">id</span></tt> field in these messages has the same semantics as the standard DHT messages,
i.e. the node ID of the node sending the message, to maintain the structure of the DHT
network.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">token</span></tt> field also has the same semantics as the standard DHT message <ttclass="docutils literal"><spanclass="pre">get_peers</span></tt>
and <ttclass="docutils literal"><spanclass="pre">announce_peer</span></tt>, when requesting an item and to write an item respectively.</p>
<p><ttclass="docutils literal"><spanclass="pre">nodes</span></tt> and <ttclass="docutils literal"><spanclass="pre">nodes6</span></tt> has the same semantics as in its <ttclass="docutils literal"><spanclass="pre">get_peers</span></tt> response.</p>
<p>When requesting a list-head the <ttclass="docutils literal"><spanclass="pre">target</span></tt> MUST always be SHA-1(<em>feed_name</em> + <em>public_key</em>).
<ttclass="docutils literal"><spanclass="pre">target</span></tt> is the target node ID the item was written to.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">n</span></tt> field is the name of the list. If specified, It MUST be UTF-8 encoded string
and it MUST match the name of the feed in the receiving node.</p>
<p>A client receiving a <ttclass="docutils literal"><spanclass="pre">get_item</span></tt> response MUST verify the signature in the <ttclass="docutils literal"><spanclass="pre">sig</span></tt>
field against the bencoded representation of the <ttclass="docutils literal"><spanclass="pre">item</span></tt> field, using the <ttclass="docutils literal"><spanclass="pre">key</span></tt> as
the public key. The <ttclass="docutils literal"><spanclass="pre">key</span></tt> MUST match the public key of the feed.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">item</span></tt> dictionary MAY contain arbitrary keys, and all keys MUST be stored for
<p>Strings are printed in hex for printability, but actual encoding is binary.</p>
<p>Note that <ttclass="docutils literal"><spanclass="pre">target</span></tt> is in fact SHA1 hash of the same data the signature <ttclass="docutils literal"><spanclass="pre">sig</span></tt>
<p>The reason to use <aclass="reference external"href="http://cr.yp.to/ecdh.html">curve25519</a> instead of, for instance, RSA is compactness. According to
<aclass="reference external"href="http://cr.yp.to/">http://cr.yp.to/</a>, curve25519 is free from patent claims and there are open implementations
