[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0001] branch master updated: clarify that this is about the remote s
From: |
gnunet |
Subject: |
[lsd0001] branch master updated: clarify that this is about the remote storage, not the local store |
Date: |
Sat, 01 Jul 2023 00:39:39 +0200 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0001] branch master updated: clarify that this is about the remote storage, not the local store,
gnunet <=