Schanzenbach, Martin transcribed 4.5K bytes: > Hi, > > I kind of agree. > > > On 26. Oct 2017, at 19:51, carlo von lynX <[email protected]> > > 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 > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > 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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
