commit 51c3bc6a6092f6842958c8832d3617d497bcb6f3
parent 26ae12e462ec74bcf858135a69c6ad32bfcfbd6b
Author: Julius Bünger <buenger@mytum.de>
Date: Tue, 12 Mar 2024 16:57:25 +0100
cong: clean up smaller bits (comments, wordings, ...)
Diffstat:
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -19,6 +19,7 @@ change.
..
Design goals
------------
+ - limit tracking
Key exchange
@@ -158,7 +159,7 @@ Scope of Peer ID for higher Layers
""""""""""""""""""""""""""""""""""
When peer ids stop to be unique over time, the framework is in lack of a
-globally unique identifier. Higher layers may rely (have reliede) on the
+globally unique identifier. Higher layers may rely (have relied) on the
uniqueness of the ids. This means gnunet has to use other means for this
purpose. The Reconnects_ section below is concerned with the specific impact on
reconnects for different higher-layer services. In general gns/identity offers
@@ -168,7 +169,7 @@ As peer ids cease to be unique over time, this might be a good point to review
the scope of its and other elements' usage and terminology. (See
Open_Design_Questions_)
-FIXME This section overlaps in scope with the next section.
+.. FIXME This section overlaps in scope with the next section.
.. _Reconnects:
@@ -195,24 +196,16 @@ This affects the layers above CADET as follows:
changes ahead of time to communicate a switch between IDs to other peers.
For other reconnections via GNS lookups are required.
- Conversation: The call would be interrupted until the new peer id of the
- other has been found via GNS.
+ other has been found (potentially via GNS).
-TODO: question: is gns needed for a reconnect? couldn't the peer with the new
-id simply 'call back' the other peer?
+Open question: is gns needed for a reconnect? Could the peer with the new
+id not simply 'call back' the other peer? Of course this would only work if
+only one peer changes its peer id. If both change their peer id at the same
+time, an external mechanism would be needed.
See Open_Design_Questions_ for thoughts on good designs to handle address
changes more smoothly.
-..
- - disconnects -> cadet
- - revocation (directly connected neighbor, don't use routing, only
- congestion/flow control)
- - file sharing (non-anonymous): lookup peer and cadet port in dht
- (continue looking for other peers meanwhile)
- - messenging/messenger: not too bad, continue the lookup of the peer
- (gns)
- - conversation
-
.. _Messenger-Implications:
@@ -241,9 +234,6 @@ Open questions
^^^^^^^^^^^^^^
..
- TODO (open questions)
-
-..
overall for this "peer id" section
Notes from the meeting:
- higher-layer roll-over
@@ -397,6 +387,10 @@ In this section we list design question that are not decided on, yet.
- 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?
.. _Peer-ID-changes-and-connectivity:
