[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Troubleshooting CADET
From: |
ng0 |
Subject: |
Re: [GNUnet-developers] Troubleshooting CADET |
Date: |
Fri, 27 Oct 2017 11:02:25 +0000 |
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
- [GNUnet-developers] Troubleshooting CADET, peter, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, peter, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, Christian Grothoff, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, carlo von lynX, 2017/10/26
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, ng0, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, Julius Bünger, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET,
ng0 <=
- Re: [GNUnet-developers] Troubleshooting CADET, xrs, 2017/10/28
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/30
- Re: [GNUnet-developers] Troubleshooting CADET, ng0, 2017/10/30