commit 9d49141d0a856c91ce1a4f46217092b7a577c795
parent 7d0092c19a6c97b110a781bf18a154ba7651b5ea
Author: Julius Bünger <buenger@mytum.de>
Date: Tue, 29 Oct 2024 15:18:17 +0100
-cong: architectural comments for integration of libp2p
Diffstat:
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -618,15 +618,20 @@ api:
libp2p Underlay
---------------
-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.
+Get gnunet to work on libp2p. This includes the FFI with rust (or binding to
+implementations in other languages), 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.
+
+For a lot of practical purposes it would be a lot easier to add a new
+communicator for libp2p instead of integrating it as an underlay below core,
+next to transport. The downside would be that there might be a lot of
+duplication of functionality.
..
TODO this generally needs more love
