[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] Troubleshooting CADET
From: |
Schanzenbach, Martin |
Subject: |
Re: [GNUnet-developers] Troubleshooting CADET |
Date: |
Fri, 27 Oct 2017 09:18:39 +0200 |
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 <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
> ------------------------------------------------------------------------
>
signature.asc
Description: Message signed with OpenPGP
- [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 <=
- 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