commit 0d3e488f04bed7685b759621f2c17fe8a51ad637
parent f88a389426a665df222486b0563e5a91e77a7045
Author: Julius Bünger <buenger@mytum.de>
Date: Thu, 7 Mar 2024 14:52:27 +0100
cong: fix warnings
- proper spacing between paragraphs
- fix duplicate link names
Diffstat:
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -97,6 +97,7 @@ A way to circumvent this tracking mechanism would be for an attacker to exploit
the means for consistently connect to the same peer.
For example gns. With the knowledge of the gns entry, its peer ids and thus its
addresses can be fully tracked.
+
..
TODO explain that this limits the attack, is all we can do on this level and
that onion routing/mix networking is supposed to circumvent this
@@ -109,7 +110,7 @@ addresses can be fully tracked.
- region (country, city, building, ...)
-.. _Implications:
+.. _Implications-PeerIDs:
Implications
^^^^^^^^^^^^
@@ -192,7 +193,7 @@ changes more smoothly.
- conversation
-.. _Messenger:
+.. _Messenger-Implications:
Messenger
"""""""""
@@ -201,7 +202,7 @@ The current implementation of messenger heavily relies on a globally unique
peer id. The change requires messenger to account for peer id changes.
-.. _Details-on-how:
+.. _Details-on-how_PeerIDs:
Details on how
^^^^^^^^^^^^^^
@@ -232,7 +233,7 @@ takes control/responsibility for it. Core is the most suitable layer for this.
TODO why is it?
-.. _Implications:
+.. _Implications-onwnership_PeerIDs:
Implications
^^^^^^^^^^^^
@@ -256,7 +257,7 @@ Transport
assume its continuity
-.. _Details-on-how:
+.. _Details-on-how_ownership_PeerIDs:
Details on how
^^^^^^^^^^^^^^
@@ -425,7 +426,7 @@ CADET
TODO
-.. _Messenger:
+.. _Messenger-scenarios:
Messenger
^^^^^^^^^
