[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: storage instead of publish
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: storage instead of publish |
Date: |
Mon, 20 Dec 2021 11:50:15 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0001.
The following commit(s) were added to refs/heads/master by this push:
new ccf73e2 storage instead of publish
ccf73e2 is described below
commit ccf73e2988c0ded31845c199794fad7f4d1979ac
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Mon Dec 20 11:50:12 2021 +0100
storage instead of publish
---
draft-schanzen-gns.xml | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 0e2e28d..d06261c 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -137,13 +137,6 @@
<t>
This document defines the normative wire format of resource records,
resolution processes,
cryptographic routines and security considerations for use by
implementors.
- In general any API which allows storing a value under a key and
retrieving
- a value from the key can be used by an implementation for record storage.
- It is expected that a GNS implementation is using a distributed hash
- table (DHT).
- Specification of such a DHT is out of scope of this document but
- possible existing implementations include <xref target="RFC7363" />,
- <xref target="Kademlia" />, <xref target="R5N" /> or <xref
target="Ipfs" />.
</t>
<t>
This specification was developed outside the IETF and does not have
@@ -1119,9 +1112,26 @@ NONCE := HKDF-Expand (PRK_n, label, 32 / 8)
</section>
</section>
<section anchor="publish" numbered="true" toc="default">
- <name>Publishing Records</name>
+ <name>Record Storage</name>
+ <t>
+ In general any API which allows storing a value under a key and
retrieving
+ a value from the key can be used by an implementation for record
storage.
+ It is expected that a GNS implementation is using a distributed
+ hash table (DHT) in order to facilitate availability within a network
+ without the need of servers.
+ Specification of such a DHT is out of scope of this document but
+ possible existing implementations include <xref target="RFC7363" />,
+ <xref target="Kademlia" />, <xref target="R5N" /> or <xref
target="Ipfs" />.
+ </t>
+ <t>
+ We assume that an implementation realizes two procedures on top of a
+ storage:
+ </t>
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+PUT(key,value)
+value := GET(key)
+ ]]></artwork>
<t>
- We assume that a storage API provides two functions: GET(key) and
PUT(key,value).
In GNS, resource records are grouped by their respective labels,
encrypted and published together in a single resource records block
(RRBLOCK) in the storage under a key "q": PUT(q, RRBLOCK).
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: storage instead of publish,
gnunet <=