Re: [GNUnet-developers] Troubleshooting CADET

[ng0]

Schanzenbach, Martin transcribed 7.0K bytes:
> Hi,
> 
> to clarify: having a (public) git hostlist server makes little sense because 
> git can break compatibility at any time (better: with every commit).

Sure, I agree.

> 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.

This sounds reasonable, and we could talk about it at the meeting.
I think dvn had ideas with regards to this, or at least how
CI and CD could be used in a better way.
Having a protocol stable branch would be a good start.

On my end, I've been interupting peoples build with some texinfo
errors, I should've moved this development to a branch aswell.

> 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 <address@hidden> 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 <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
> > 
> > 
> > 
> >> _______________________________________________
> >> GNUnet-developers mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> > 
> > 
> > --
> > 
> > ------------------------------------------------------------------------
> >           I prefer to communicate via GPG-encrypted email.
> >           Key: D4E5F972B413F3B3     Keyserver: pgp.mit.edu
> > ------------------------------------------------------------------------
> > 
> 



> _______________________________________________
> 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