[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Troubleshooting CADET
From: |
Julius Bünger |
Subject: |
Re: [GNUnet-developers] Troubleshooting CADET |
Date: |
Fri, 27 Oct 2017 09:03:51 +0200 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
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
------------------------------------------------------------------------
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 <=
- Re: [GNUnet-developers] Troubleshooting CADET, Schanzenbach, Martin, 2017/10/27
- Re: [GNUnet-developers] Troubleshooting CADET, ng0, 2017/10/27
- 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