commit 889e9533545dc898ddeedd1f1abedec91738290b
parent 6e2f32b7fae8debf8465c613b5504b6fc058787f
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 7 Dec 2021 15:29:17 +0100
updates
Diffstat:
1 file changed, 97 insertions(+), 61 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -199,6 +199,92 @@ Connectivity | |Underlay| |Underlay|
</dd>
</dl>
</section>
+ <section anchor="overlay" numbered="true" toc="default">
+ <name>Overlay</name>
+ <t>
+ In the DHT overlay, a peer is addressable by its Peer ID.
+ The Peer ID is the 256-bit hash of the peer public key.
+ The peer public key is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> peer private key.
+ </t>
+ <t>
+ Any implementation of this specification MUST expose the two API
+ procedures "GET" and "PUT".
+ </t>
+ <section>
+ <name>The GET procedure</name>
+ <t>
+ The GET procedure is defined as follows:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+GET(key[, options]) -> RESULTS as List
+ or
+GET(key[, options], callbackFunction)
+ ]]></artwork>
+ <t>
+ The procedure takes two arguments. The first argument is the query
+ key and is mandatory. The GET procedure may also allow the caller
+ to specifiy query options.
+ </t>
+ <t>
+ The procedure either returns a list of results or allows the caller
+ to provide a callback function which is called for any result
+ received from the DHT until the procedure is cancelled.
+ </t>
+ </section>
+ <section>
+ <name>The PUT procedure</name>
+ <t>
+ The PUT procedure is defined as follows:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+PUT(key[, options], BLOCK)
+ ]]></artwork>
+ <t>
+ The procedure takes three arguments. The first argument is the query
+ key and is mandatory. The PUT procedure may also allow the caller
+ to specifiy put options. The third argument is the payload data which
+ is to be stored under the provided put key.
+ </t>
+ </section>
+ </section>
+ <section anchor="blockstorage" numbered="true" toc="default">
+ <name>Block Storage</name>
+ <section>
+ <name>Block Types</name>
+ <t>
+ Applications can and should define their own block types.
+ The block type determines the format and handling of the block
+ payload by peers in PUT and RESULT messages.
+ Block types MUST be registered with GANA <xref target="gana"/>.
+ </t>
+ <t>
+ For bootstrapping and peer discovery, the DHT implementation uses
+ its own block type called "HELLO". A block with this block type
+ contains the peer ID of the peer initiating the GET request.
+ </t>
+ <section>
+ <name>HELLO</name>
+ <t>
+ The HELLO block type wire format is illustrated in
+ <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
+ include extended query data (xquery). Any implementation
+ encountering a HELLO block with xquery data MUST consider the
+ block invalid and ignore it.
+ </t>
+ <t>
+ A HELLO reply block MAY be empty. Otherwise, it contains the
+ HELLO URI of a peer.
+ </t>
+ <figure anchor="figure_hellobt">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+ FIXME: Wire format
+ ]]></artwork>
+ </figure>
+ </section>
+ </section>
+ </section>
+
<section anchor="underlay" numbered="true" toc="default">
<name>Underlay</name>
<t>
@@ -338,60 +424,6 @@ see how we can offer even the most minimal protections against peer
</dl>
</section>
- <section anchor="overlay" numbered="true" toc="default">
- <name>Overlay</name>
- <t>
- In the DHT overlay, a peer is addressable by its Peer ID.
- The Peer ID is the 256-bit hash of the peer public key.
- The peer public key is the public key of the corresponding
- Ed25519<xref target="ed25519" /> peer private key.
- </t>
- <t>
- Any implementation of this specification MUST expose the two API
- procedures "GET" and "PUT".
- </t>
- <section>
- <name>The GET procedure</name>
- <t>
- The GET procedure is defined as follows:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-GET(key[, options]) -> RESULTS as List
- or
-GET(key[, options], callbackFunction)
- ]]></artwork>
- <t>
- The procedure takes two arguments. The first argument is the query
- key and is mandatory. The GET procedure may also allow the caller
- to specifiy query options.
- </t>
- <t>
- The procedure either returns a list of results or allows the caller
- to provide a callback function which is called for any result
- received from the DHT until the procedure is cancelled.
- </t>
- </section>
- <section>
- <name>The PUT procedure</name>
- <t>
- The PUT procedure is defined as follows:
- </t>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-PUT(key[, options], PAYLOAD)
- ]]></artwork>
- <t>
- The procedure takes three arguments. The first argument is the query
- key and is mandatory. The PUT procedure may also allow the caller
- to specifiy put options. The third argument is the payload data which
- is to be stored under the provided put key.
- </t>
- </section>
- </section>
- <section anchor="blockstorage" numbered="true" toc="default">
- <name>Block Storage</name>
- <t>
- </t>
- </section>
<section anchor="routing" numbered="true" toc="default">
<name>Routing</name>
<section anchor="peer_selection" numbered="true" toc="default">
@@ -532,7 +564,7 @@ END
+-----+-----+-----+-----+-----+-----+-----+-----+
/ PUTPATH (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
-/ PAYLOAD (variable length) /
+/ BLOCK (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
</figure>
@@ -593,11 +625,10 @@ END
the variable-length PUT path.
The path consists of a list of PATH_LEN peer IDs.
</dd>
- <dt>PAYLOAD</dt>
+ <dt>BLOCK</dt>
<dd>
- the variable-length resource record data payload. The contents are defined
- by the
- respective type of the resource record.
+ the variable-length block payload. The contents are determined
+ by the BTYPE field.
</dd>
</dl>
@@ -706,7 +737,7 @@ END
/ GETPATH /
/ (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
-/ PAYLOAD /
+/ BLOCK /
/ (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
@@ -765,7 +796,7 @@ END
the variable-length PUT path.
The path consists of a list of PATH_LEN peer IDs.
</dd>
- <dt>PAYLOAD</dt>
+ <dt>BLOCK</dt>
<dd>
the variable-length resource record data payload.
The contents are defined by the respective type of the resource record.
@@ -773,6 +804,11 @@ END
</dl>
</section>
</section>
+ <section>
+ <name>Bootstrapping</name>
+ <t>
+ </t>
+ </section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<!-- FIXME: Here we should (again) discuss how the system is open and
