Re: [GNUnet-developers] Troubleshooting CADET

[ng0]

Schanzenbach, Martin transcribed 10K bytes:
> Hi,
> 
> > On 28. Oct 2017, at 17:31, xrs <address@hidden> wrote:
> > 
> > Hello everybody,
> > 
> > I remember Martin proposing to discuss the release practice on the
> > GNUnet hacker meeting at 34C3. I find this a good idea.
> > 
> 
> Update: I will not be able to attend 34c3 this year.

At the eV meeting? No, we wanted to do this in Berlin
at the meeting/workshop we've sent out the invitation to
a couple of days ago.
I don't think the usually noisy and rushed atmosphere of a conference
is the right place to discuss this topic. We could collect ideas
so that there's already some base for the workshop and we won't
attend unprepared.

> > Still, we have 2 month left and some of us are kind of stucked.
> > 
> > This problem about the hostlist server is new, so we should be able to
> > find the cause for it. I'll do my best to find it, although I'm not so
> > familiar with the other services.
> > 
> 
> I agree that you might be able to find the issue and fix it in the code. But 
> then you will hit the actual problem: You cannot know if all the nodes in the 
> network update!
> So the core question is: Why to you need the "central" gnunet.org hostlist 
> server?
> If #1: you are currently developing some functionality, use your own testing 
> hostlist to bootstrap your own network.
> That way you also have full control over the topology and versioning. (As I 
> said before docker{-compose} is my tool of choice here)
> 
> If #2: you are interested in a prime-time-ready release channel, you are out 
> of luck atm. The "latest" stable version is 0.10.
> Such a channel should _never_ be used for development/testing, though.
> 
> This issue is organizational, not technical. As such you cannot fix it with 
> code.
> Other projects face the same problem. See updates of blockchain protocols 
> that break backwards compatibility.
> You cannot connect Bitcoin Classic with Bitcoin "standard" clients. Well, at 
> least if you do you cannot expect everything to work smoothly.

Torproject has recently introduced and worked on(?) a guideline
for longterm support of older versions of their tor software.
Or at least it was discussed this year on their mailinglist
and releases were adjusted in some form.
Maybe we should look into how other projects similar to ours
deal with this issue and develop our own strategy based on
the results of this.

> BR
> Martin
> 
> 
> > @ng0: good idea ;)
> > 
> > LynX idea to elevate the protocol version every time we make a change
> > sounds good. Does anybody know where in the code this might be done?
> > (I found version numbers for the APIs.)
> > 
> > Greets,
> > xrs
> > 
> > On Fri, 27 Oct 2017 11:02:25 +0000
> > ng0 <address@hidden> wrote:
> > 
> >> 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
> >> 
> >> 
> > 
> > _______________________________________________
> > 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