I wrote a patch for gnunet-secushare.git that fixes the config files that gnunet-arm will read. The @UNIXONLY@ stuff is removed since that causes a parse error.
Tobias On Thu, 2021-09-23 at 11:56 +0200, TheJackiMonster wrote: > On Thu, 2021-09-23 at 11:39 +0200, carlo von lynX wrote: > > On Thu, Sep 23, 2021 at 11:05:06AM +0200, carlo von lynX wrote: > > > The circular topology of end points *does* satisfy the secushare > > > expectations on privacy and metadata privacy in particular > > > AFAICT, > > > so that's very cool. > > > > Whoopsa I'm posting faster than I am thinking, sorry. No, without > > any form of obfuscation such a scheme is not metadata-safe, just > > like multicast without onion routing wouldn't be. > > > > A few thoughts on metadata protection in the case of ring > > topologies. > > > > For maximum metadata protection we would need an onion routing > > layer below CADET which would hide any communication between two > > participants, or we could be having a second API-compatible CADET > > which actually has onion routing inside.. an ORCADET. > > I think it should be possible to use onion routing on the transport > layer below CADET. So CADET would still use peer identities for its > connections but the actual host behind it stays anonymous. Then the > messenger service can hide identities on a user-level. > > If we get an awesome app out of this also depends a lot on the user > interface. I'm currently working towards a resposive GUI application > which aims to be comparable to Telegram in terms of design but > Threema > in terms of transparency. For example the status of verification for > contacts should be visible and understandable to users. File sharing > inside of groups is also possible in a similar way as Threema > implements it but using the FS submodule of GNUnet instead of central > file servers. > > > > > I'm wondering if we can also achieve a reasonable degree of > > metadata > > protection by using less optimal ring structures and rather have > > multiple shared secrets on an existing ring. It still makes it > > clear which social bubbles exist, just not who exactly is talking > > to whom. > > > > If we enlarge such circles the metadata protection improves as the > > social bubble blurs, but in exchange the reliability and speed of > > the ring is reduced, possibly to the point of not satisfying the > > job. > > > > Reminds me of the shards of Bitmessage - they were approaching the > > problem from the opposite side, starting out with a broadcast > > strategy, then reducing the broadcasts to slices of the totality. > > > > There may be some in-between constellation that works well enough > > to achieve plausible metadata protection and there may be > > mathematical > > ways of modeling the architecture to prove how deep we need to dig. > > > > For things that aren't time-critical (the secushare higher layers > > would know) Jeff's good-ole Mixes might come into play... > > > > >
diff --git a/src/multicast/multicast.conf.in b/src/multicast/multicast.conf.in index 97a5413..df255e2 100644 --- a/src/multicast/multicast.conf.in +++ b/src/multicast/multicast.conf.in @@ -6,7 +6,6 @@ UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-multicast.sock UNIX_MATCH_UID = YES UNIX_MATCH_GID = YES -@UNIXONLY@PORT = 2109 HOSTNAME = localhost ACCEPT_FROM = 127.0.0.1; ACCEPT_FROM6 = ::1; diff --git a/src/psyc/psyc.conf.in b/src/psyc/psyc.conf.in index 764ccfa..dd90686 100644 --- a/src/psyc/psyc.conf.in +++ b/src/psyc/psyc.conf.in @@ -6,7 +6,6 @@ UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-psyc.sock UNIX_MATCH_UID = YES UNIX_MATCH_GID = YES -@UNIXONLY@PORT = 2115 HOSTNAME = localhost ACCEPT_FROM = 127.0.0.1; ACCEPT_FROM6 = ::1; diff --git a/src/psycstore/psycstore.conf.in b/src/psycstore/psycstore.conf.in index 3905db1..43c2038 100644 --- a/src/psycstore/psycstore.conf.in +++ b/src/psycstore/psycstore.conf.in @@ -6,7 +6,6 @@ UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-psycstore.sock UNIX_MATCH_UID = YES UNIX_MATCH_GID = YES -@UNIXONLY@PORT = 2111 HOSTNAME = localhost ACCEPT_FROM = 127.0.0.1; ACCEPT_FROM6 = ::1; diff --git a/src/social/social.conf.in b/src/social/social.conf.in index 3fe754c..6ccb3d6 100644 --- a/src/social/social.conf.in +++ b/src/social/social.conf.in @@ -7,7 +7,6 @@ UNIXPATH = $GNUNET_USER_RUNTIME_DIR/gnunet-service-social.sock UNIX_MATCH_UID = YES UNIX_MATCH_GID = YES -@UNIXONLY@PORT = 2116 HOSTNAME = localhost ACCEPT_FROM = 127.0.0.1; ACCEPT_FROM6 = ::1;
