Re: [GNUnet-developers] Troubleshooting CADET

[Schanzenbach, Martin]

Hi,

to clarify: having a (public) git hostlist server makes little sense because 
git can break compatibility at any time (better: with every commit).
Maybe if we had a system like other projects where we branch the development 
off to another branch and "freeze" the protocol in master or a release 
candidate branch this would be reasonable.
But a "git head"-hostlist server is bound to advertise all kinds of 
incompatible peers. Inherently.

=> Better test git head/master in a local/dedicated testbed tied to the head 
revision or your respective branch or you will get undefined results.
=> GNUnet has a testbed built-in (I never used it though)

BR

> On 27. Oct 2017, at 09:03, Julius Bünger <address@hidden> wrote:
> 
> I assumed it was already the case. Just that the recen release was a
> while ago.
> 
> There is v10.gnunet.org/hostlist for the last release and
> gnunet.org/hostlist for git.
> (At least that's the way I read it.)
> 
> 
> On Fri, Oct 27, 2017 at 06:56:44 +0000, ng0 wrote:
>> Schanzenbach, Martin transcribed 4.5K bytes:
>>> Hi,
>>> 
>>> I kind of agree.
>>> 
>>>> On 26. Oct 2017, at 19:51, carlo von lynX <address@hidden> wrote:
>>>> 
>>>> On Thu, Oct 26, 2017 at 05:42:45PM +0200, Christian Grothoff wrote:
>>>>> 2) Yes, running in the 'global' network with outdated peers is likely to
>>>>> cause all kinds of fun problems, as the DHT may or may not work, or in
>>>>> the worst case the DHT discovers a path which then does not work on the
>>>>> CADET layer because some hop speaks just enough of the DHT protocol but
>>>>> not enough of the CADET protocol.
>>>> 
>>>> Maybe the basics of protocol design aren't as
>>>> exciting as inventing new crypto paradigms, but
>>>> could we please increment the protocol number
>>>> each time a change is introduced that will not
>>>> be compatible with the past?
>>> 
>>> Oh that is a problem in general in the OSS community and the reason Linux 
>>> lost the Desktop as well.
>>> 
>>>> Yes, I know that
>>>> only parts are incompatible - but I don't care.
>>>> There is nobody out there that we have to be
>>>> backward compatible for. We can increment the
>>>> protocol version identifier for each edit of
>>>> any CADET file for another year before the
>>>> whole thing is stable - and then, for the next
>>>> release we can just revert it to your favorite
>>>> number.
>>> 
>>> I think we should not confuse development with the current GNUnet release 
>>> topology.
>>> I know that those two are unfortunately mixed right now, but this is mostly 
>>> due to the lack of a recent release.
>>> 
>>> I guess we need periodical releases with each release having a new hostlist 
>>> server for that release under [hostlist]:
>>> Example:
>>> SERVERS = http://gnunet.org/<releasever>/hostlist
>>> 
>>> , thus ensuring a "pure" bootstrap.
>>> 
>>> IMO development versions (i.e. from git master) should never ever connect 
>>> to the "main" network of any release version and expect it to work.
>>> You need to bootstrap our own test topology if you want to test (e.g. with 
>>> docker).
>>> For "production" use you'd need to wait for the next release anyway.
>> 
>> What about an addition development hostlist server, would that work?
>> For example defined via
>> 
>> ~~~
>> [hostlist]
>> SERVERS = https://gnunet.org/git/hostlist
>> ~~~
>> 
>> or instead of git "dev". To record this version string would be easy.
>> 
>>>> 
>>>> Also, shouldn't all those "misbehaving" old nodes
>>>> be automatically bypassed thanks to our amazing
>>>> detection of sybil attacks?
>>>> 
>>> 
>>> I didn't even know we had that. But such a feature makes somebody with a 
>>> git version to appear like an attacker, not the other way around.
>>> 
>>>> Half a year ago we had a working CADET and a
>>>> frequently working gnunet-social. Why do we have
>>>> to go three steps back?
>>> 
>>> 
>>> We need a release at some point soon-ish (when is that meeting planned 
>>> again? ;).
>> 
>> It's in December (eV) and early/middle of January.
>> 
>>> But if you are still developing I strongly suggest docker/docker-compose.
>>> If people are interested how to do that I can make a quick write-up.
>>> 
>>> BR
>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> GNUnet-developers mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>>> 
>> 
>> 
>> 
>>> _______________________________________________
>>> GNUnet-developers mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>> 
>> 
>> --
>> ng0
>> GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
>> GnuPG: https://dist.ng0.infotropique.org/dist/keys/
>> https://www.infotropique.org https://ng0.infotropique.org
> 
> 
> 
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 
> 
> --
> 
> ------------------------------------------------------------------------
>           I prefer to communicate via GPG-encrypted email.
>           Key: D4E5F972B413F3B3     Keyserver: pgp.mit.edu
> ------------------------------------------------------------------------
>

signature.asc
Description: Message signed with OpenPGP