Re: [GNUnet-developers] Troubleshooting CADET

[ng0]

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

signature.asc
Description: PGP signature