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