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 <[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 > _______________________________________________ > GNUnet-developers mailing list > [email protected] > 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: PGP signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
