gnunet-handbook

commit fbf7c59763680363231b7bd1b4b3f77e9e7a5d36
parent 559ef9bc97a1672bfe64cf3c0515f4c4bc471fb0
Author: Julius Bünger <buenger@mytum.de>
Date:   Tue, 12 Mar 2024 17:22:00 +0100

cong: clean up comments

Diffstat:
M
developers/apis/cong.rst
 | 
27
++++++++++++++++-----------

1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -392,16 +392,9 @@ In this section we list design question that are not decided on, yet.
 
 ..
  - scope of peer ids and other such elements (gns/identity, ...)
- - terminology of peer ids
  - resolve gns to pid on lower layer? (cadet or even core)
     - convenience api: cadet connection to domain name
- - not one id per set of addresses, but per single address?
-    - multiple peer ids per peer
-    - tracking even harder
-    - comes closer to equivalent of ip addresses
-    - possibly helps with roll-overs
-    - we ceased having unique peer ids over time, why not cease to have a
-      single address at a time?
+    - -> not the scope of cong
 
 
 .. _Peer-ID-changes-and-connectivity:
@@ -431,9 +424,21 @@ Other more evolved ideas include using multiple peer ids per peer: Either an
 additional address-independent peer id that will 'survive' address changes and
 serve as means to link to the address-based peer id after a change. It would
 just be sent to connected peers and reset once all connections have been
-re-established. Alternatively (maybe in addition) peers could use multiple
-address-based peer ids - one per address. Thus some peer ids might stay
-unchanged while others go offline.
+re-established.
+
+Alternatively (maybe in addition) peers could use multiple address-based peer
+ids - one per address. Thus some peer ids might stay unchanged while others go
+offline.
+
+..
+    - tracking even harder
+    - comes closer to equivalent of ip addresses
+    - possibly helps with (privacy-preserving) roll-overs
+    - we ceased having unique peer ids over time, why not cease to have a
+      single address at a time?
+    - might serve as an 'onion-address light'?
+    - cleaner, less messy abstraction
+
 
 Another idea to address this challenge is to keep peer ids in use on
 connections which are still in use, but don't publish those ids anymore.