gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Troubleshooting CADET


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Troubleshooting CADET
Date: Fri, 27 Oct 2017 08:02:24 +0200

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.

> 
> 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? 
;).
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

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]