commit c0eb84cd8a9f782201ec8478d6c99bf1809b142b
parent 750c9059ef51891737ccb22bc71cb0ddd9b31161
Author: Julius Bünger <buenger@mytum.de>
Date: Tue, 12 Mar 2024 14:53:06 +0100
cong: new pils service
Diffstat:
1 file changed, 35 insertions(+), 24 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -254,19 +254,29 @@ Open questions
- tracking impossible/hard for others
-.. _Core's-Ownership-of-Peer-IDs:
+.. _Ownership-of-Peer-IDs:
-Core's Ownership of Peer IDs
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+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/ownership for it. Core is the most suitable layer
-for this.
+takes control/responsibility/ownership for it. A new service is created for
+this purpose. A name suggestion was "peer id lifecycle service" - PILS.
-..
- TODO why is it?
- - encryption layer above transport
+The reasons for this new service:
+
+ - Good encapsulation (which is even more important as it is a component deals
+ with crucial cryptographic operation).
+ - Avoidance of circular subscriptions of core and transport.
+ - Avoidance of callback api hell between core and transport.
+ - Using peerstore for this would be really messy.
+
+The reasons against this new service:
+ - Having yet another service.
+
+Core will be the responsible service to provide addresses to pils for the
+switching of peer ids.
.. _Implications-onwnership_PeerIDs:
@@ -274,12 +284,10 @@ for this.
Implications
^^^^^^^^^^^^
-Core needs to take ownership. It is responsible for generating, changing and
-publishing the peer id to the peersore (?). As other parts still rely on the
-usage of the peer id, it needs to provide an interface for those systems: It
-needs to inform about current id, inform about changes and sign data on
-request. To be gentle on the ipc, it should not sign big amounts of data - if
-applicable rather hashes of data or such.
+Pils needs to take ownership. It is responsible for generating, changing of
+peer ids, informing subscribers of changes and signing with the current peer
+id. (To be gentle on the ipc, it should not sign big amounts of data - if
+applicable rather hashes of data or such.)
.. _Transport:
@@ -287,11 +295,12 @@ applicable rather hashes of data or such.
Transport
"""""""""
-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.
+Up until now transport still creates, signs and puts hellos into the peerstore.
+When pils takes ownership of peer ids, transport will need to ask it 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. Core
+will have to create and provide the hellos. See libp2p-Underlay_ below.)
.. _Other:
@@ -300,8 +309,8 @@ Other
"""""
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.
+memory, will need to ask pils for it. All services that sign/encrypt something
+with the peer id now will need to ask pils to do it.
.. _Details-on-how_ownership_PeerIDs:
@@ -309,10 +318,12 @@ with the peer id now will need to ask core to do it.
Details on how
^^^^^^^^^^^^^^
-In order to provide the needed functionality, core needs to expose it via its
+In order to provide the needed functionality, pils needs to expose it via its
api:
- - a call to receive the current peer id
+ - a call to provide the current set of addresses, so the generation of the
+ peer id can be triggered.
+ - a call to obtain the current peer id
- registering a handler that informs about new peer ids
- signing data with the peer id
@@ -338,7 +349,7 @@ published.
..
- addresses from underlay in string representation go into core
- libp2p can't handle hellos/peerstore
- - address signaling btw. transport and core
+ - address signaling between transport and core
- hellos should be handled by core
