commit 01f5773ea7bede7adcf8a055cd9baec3aaa52897
parent 0d3e488f04bed7685b759621f2c17fe8a51ad637
Author: Julius Bünger <buenger@mytum.de>
Date: Thu, 7 Mar 2024 16:11:00 +0100
cong: be more verbose over different sections
Diffstat:
1 file changed, 95 insertions(+), 56 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -10,11 +10,13 @@ CONG (COre Next Generation) is the name of the project redesigns the CORE
service. Here we document the design decisions and parts that are about to
change.
+..
+ TODO write a short overview
-Design goals
-------------
+..
+ Design goals
+ ------------
-TODO
Key exchange
------------
@@ -58,10 +60,10 @@ Reasoning
- why this decision (and not others?)
- (scenarios to understand whether it makes sense)
-This change was introduced in order to stop tracking of more mobile peers.
-For example a more mobile peer (laptop) that logs into the network at different
-places can be easily tracked by everyone just by recording the different
-addresses that are tied to that peer id over time.
+This change was introduced in order to stop tracking of more mobile peers
+across the network. For example a more mobile peer (laptop) that logs into the
+network at different places can be easily tracked by everyone just by recording
+the different addresses that are tied to that peer id over time.
..
TODO
@@ -115,7 +117,7 @@ addresses can be fully tracked.
Implications
^^^^^^^^^^^^
-Here we spell out the implications for different parts of the framework. This
+Here we present the implications for different parts of the framework. This
should help get a grasp of the implications of the change.
.. TODO poor phrasing?
@@ -126,7 +128,9 @@ DHT
The DHT uses the peer id such that it determines which buckets a peer is
responsible for. So each time the peer id changes, the peer becomes responsible
-for different data.
+for different data. This means that each time a peer changes address, it leaves
+and re-enters the DHT, changes its and other peer's neighbors and changes the
+stored data.
.. _Scope-of-Peer-ID-for-higher-Layers:
@@ -157,8 +161,6 @@ When addresses (and with those the peer id) of a peer change, all core
connections need to be torn down and with them all higher-layer connections.
This affects the layers above CADET as follows:
-TODO lookup rst lists!
-
- Revocation: Is not really affected as it is only connected to direct CADET
neighbors and makes no use of CADET's routing, only of its flow and
congestion control.
@@ -219,6 +221,35 @@ Details on how
Open questions
^^^^^^^^^^^^^^
+..
+ TODO (open questions)
+
+..
+ overall for this "peer id" section
+ Notes from the meeting:
+ - higher-layer roll-over
+ - problem in practice 'phone call not interrupted by change of
+ location'
+ - solved by gns entries? and re-connect?
+ - cadet search for peer id - search in dht and via gns
+ - caching-problem for gns
+ - no signaling for roll-over
+ - estimated reconnect within 15 minutes
+ - change of address/peerid results in unclear state (down? lost
+ connection, ....?)
+ - cadet needs to regularily check gns entries
+ - how signal the change of addresses?
+ - do we signal trear-down?
+ - scenario address change in internet cafe?
+ - choice between privacy and connectivity
+ - sense of changing ids for cadet?
+ - -> rendez-vous peer (more stable)
+ - tracking via gns?
+ - only for people who are connected/known (tracking might be
+ ok for this)
+ - requires pir for gns
+ - tracking impossible/hard for others
+
.. _Core's-Ownership-of-Peer-IDs:
@@ -227,10 +258,12 @@ Core's Ownership of Peer IDs
When the peer id was static, all parts of gnunet had a simple way to interface
with it. Once it becomes dynamic, it makes a lot of sense that a single part
-takes control/responsibility for it. Core is the most suitable layer for this.
+takes control/responsibility/ownership for it. Core is the most suitable layer
+for this.
..
TODO why is it?
+ - encryption layer above transport
.. _Implications-onwnership_PeerIDs:
@@ -251,59 +284,53 @@ applicable rather hashes of data or such.
Transport
"""""""""
-..
- - transport creates and signs hello (w peer id)
- - all other parts of gnunet that simply read the peer id from a file and
- assume its continuity
+Up until now transport still creates, signs and puts the peer ids into the
+peerstore. When core takes ownership of peer ids, transport will need to ask
+core for signing the hellos before putting it into the peerstore. With libp2p
+as alternative/additional underlay in mind, everything related to hellos needs
+to move to core eventually as libp2p is oblivious about that part of gnunet.
-.. _Details-on-how_ownership_PeerIDs:
+.. _Other:
-Details on how
-^^^^^^^^^^^^^^
+Other
+"""""
-..
- signing functionality as api call (only sign hashes? - load on ipc)
+Generally, all parts that so far read the peer id from a file into local
+memory, will need to ask core for it. All services that sign/encrypt something
+with the peer id now will need to ask core to do it.
-..
- Notes from the meeting:
- - higher-layer roll-over
- - problem in practice 'phone call not interrupted by change of
- location'
- - solved by gns entries? and re-connect?
- - cadet search for peer id - search in dht and via gns
- - caching-problem for gns
- - no signaling for roll-over
- - estimated reconnect within 15 minutes
- - change of address/peerid results in unclear state (down? lost
- connection, ....?)
- - cadet needs to regularily check gns entries
- - how signal the change of addresses?
- - do we signal trear-down?
- - scenario address change in internet cafe?
- - choice between privacy and connectivity
- - sense of changing ids for cadet?
- - -> rendez-vous peer (more stable)
- - tracking via gns?
- - only for people who are connected/known (tracking might be
- ok for this)
- - requires pir for gns
- - tracking impossible/hard for others
+.. _Details-on-how_ownership_PeerIDs:
-.. _Protocol_002dVersioning:
+Details on how
+^^^^^^^^^^^^^^
-Protocol-Versioning
--------------------
+In order to provide the needed functionality, core needs to expose it via its
+api:
+
+ - a call to receive the current peer id
+ - registering a handler that informs about new peer ids
+ - signing data with the peer id
-TODO
.. _libp2p-Underlay:
libp2p Underlay
---------------
-TODO
+Get gnunet to work on libp2p. This includes the FFI with rust, converting
+address formats, signaling metadata (traffic class and priority, as far as
+libp2p supports it) and signalling connectivity changes.
+This is a first attempt to technically link the two projects. Therefore the
+feasibility is quite uncertain and the milestones might have to be re-evaluated
+after the report on the needs and feasibility. Should it turn out that the
+needed resources are beyond the capabilities of this project, a detailed report
+on the requirements and roadmap of and for the realisation shall be written and
+published.
+
+..
+ TODO this generally needs more love
..
- addresses from underlay in string representation go into core
@@ -312,6 +339,19 @@ TODO
- hellos should be handled by core
+.. _Protocol_002dVersioning:
+
+Protocol-Versioning
+-------------------
+
+Currently applications signal to core which message types they support. For
+this milestone we will implement proper protocol versioning where higher-level
+applications can signal a range of protocol versions which they support (min,
+max) and exchange messages at the CONG layer between peers to determine common
+protocols.
+
+
+
.. _Open_Design_Questions:
Open Design Questions
@@ -395,14 +435,13 @@ Peer ID
^^^^^^^
The peer id has been used throughout gnunet as a very convenient means for many
-purposes. Here we collect the intended purposes and use cases and also point
-out some uses for which it was not intended and point to other means to achieve
-it.
+purposes. It was used as globally unique and stable identifier of a peer. From
+now on it should rather be treated as something more volatile and fitting for
+its layer: an ip address. Below we collect the intended purposes and use cases
+and also point out some uses for which it was not intended and point to other
+means to achieve it.
..
- TODO
- - e2e connectivity?
- - analogy: ip address
- address change: shutdown vs. standby vs. ...
