[lsd0001] branch master updated: clarify that this is about the remote storage, not the local store

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0001.

The following commit(s) were added to refs/heads/master by this push:
     new 5f9bb11  clarify that this is about the remote storage, not the local 
store
5f9bb11 is described below

commit 5f9bb11bb38398d853b487c40c2d1c2ff8f7578d
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Jul 1 00:39:35 2023 +0200

    clarify that this is about the remote storage, not the local store
---
 draft-schanzen-gns.xml | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index c960904..0e68df6 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -2667,34 +2667,35 @@ NICK: john (supplemental)
          </t>
          <t>
            While implementations following this specification will be
-           interoperable, if two implementations connect to different storages
+           interoperable, if two implementations connect to different remote 
storages
            they are mutually unreachable.
            This can lead to a state where a record exists in the global
            namespace for a particular name, but the implementation is not
-           communicating with the storage and is hence unable to resolve it.
+           communicating with the remote storage that contains the respective
+           block and is hence unable to resolve it.
            This situation is similar to a split-horizon DNS configuration.
-           Which storages are implemented usually depends on the application
+           Which remote storages are implemented usually depends on the 
application
            it is built for.
-           The storage used will most likely depend on the specific application
+           The remote storage used will most likely depend on the specific 
application
            context using GNS resolution.
            For example, one application is the resolution of hidden services
-           within the Tor network, which would suggest using Tor routers for 
storage.
+           within the Tor network, which would suggest using Tor routers for 
remote storage.
            <!-- FIXME: add non-normative reference to Tor / Tor hidden 
services here? -->
-           Implementations of "aggregated" storages are conceivable, but
+           Implementations of "aggregated" remote storages are conceivable, but
            are expected to be the exception.
          </t>
        </section>
        <section anchor="security_dht" numbered="true" toc="default">
-         <name>DHTs as Storage</name>
+         <name>DHTs as Remote Storage</name>
          <t>
            This document does not specify the properties of the underlying
-           storage which is required by any GNS implementation.
+           remote storage which is required by any GNS implementation.
            It is important to note that the properties of the underlying
-           storage are directly inherited by the
+           remote storage are directly inherited by the
            GNS implementation. This includes both security as well as
            other non-functional properties such as scalability and performance.
            Implementers should take great care when selecting or implementing
-           a DHT for use as storage in a GNS implementation.
+           a DHT for use as remote storage in a GNS implementation.
            DHTs with reasonable security and performance properties exist
            <xref target="R5N"/>.
            It should also be taken into consideration that GNS implementations

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.