On 01.11.22 12:35, accounts-gnunet@holbrook.no wrote:
On Tue, Nov 01, 2022 at 09:19:38AM +0000, t3sserakt wrote:
------------------------------
Message: 2
Date: Mon, 31 Oct 2022 15:45:15 +0000
From:accounts-gnunet@holbrook.no
To: Martin Schanzenbach<mschanzenbach@posteo.de>
Cc:accounts-gnunet@holbrook.no,help-gnunet@gnu.org
Subject: Re: network from scratch
Message-ID:<Y1/tixoD6+DkbxHV@holbrook.no>
Content-Type: text/plain; charset=us-ascii
Aha so adding -f to the gnunet-peer -s -g makes it output the hello.
And that URI is accepted by gnunet-peer -p
Now the peer is listed with gnunet-peer (-f)
Now peer A and B has both peer A and B in their peerinfo lists.
However, the peer A is still not being sent by the hostlist
(after retstarting
the nodes), still only the Y924 is being sent.
Then I changed the URIs fromgnunet://hello-friend tognunet://hello.
Now the peers get sent with the hostlist.
I do not get why - in F2F mode - you are doing that. What is the
content of
friends.txt?
AFAIU, the friends.txt file is supposed to hold one public key per
line
of nodes that one allows connections from.
Means peer A has the hello of peer B in its friends.txt and vice
versa?!
Can you please elaborate more on your use case.
Simply to bootstrap a fully private network.
What made it problematic was the forced connection of the bundled
peer.
That's why I tried F2F mode, but it turns out that comes with its
own caveats in
terms of how the modules behave.
The solution was to, as Martin suggested, delete the entry in the
$PREFIX/share/gnunet/hellos/* dir. When starting two peers from
scratch
they automatically find each other (at least when running on the same
interface, that's what i tried so far). I don't think the hellos
dir is clearly
documented, or if it is, I missed it...
My expectation was, that theĀ entries in the friends.txt should be
sufficient and no hostlist server is needed. I will check in the code.