NGI Pointer application

[Bernd Fix]

Hi all.

Last year we (Martin, Christian and I) successfully applied for a NGI
Discovery grant (through NLnet) to write an RFC draft and to
re-implement GNS in Golang (as well as some GNUnet packaging for
distros) - which worked out pretty well and improved GNUnet crypto and
other things.

We are now in the process of re-applying for a NGI Pointer grant; the
idea is to do the same thing for the DHT. As the grant is covering for
much more work, we would like more people to participate.

If you are interested in joining the application, we would be happy to
receive your input. What we basically need as information is the following:

  - Name:
  - Gender: (m/f/d/-)
  - Role/Responsibility: (what you can/want to do, see section below)
  - CV/Background: (link or pdf)
  - Commitment: (How much time you can spend over the next 12 month)

Please read the following text we are going to apply with; if you are
interested in joining, we need your reply as soon as possible (latest is
Saturday noon) as we have to submit the application by then.

I apologize that this is on very short notice; we thought it would be
sufficient to apply as GNUnet e.V. and sort out the task assignment
later, but decided it would improve our chances of getting accepted if
we list people that want to participate in application itself.

Of course we are just applying and there is no garantee that we will get
funded - but chances are not that bad after our last successful project...

Regards, Bernd.

-------------------------------------

# DHT

## Basic Information

### Name

R5N-DHT

## Project

### Tagline (280c)

Specifying and implementing a resilient DHT: Enabling new concepts for
decentralized name resolution, network governance and content management
through distributed privacy-preserving and censorship-resistant
key-value stores.

### Brief description (1000c)

Tomorrows internet will still have to rely and run on todays physical
infrastructure which at its core is hierarchically organized, owned and
operated by just a few global actors.  Decentralization is therefore
becoming a major building block to strengthen the values of freedom and
informational self-determination against the particular interests of
such actors that are not driven by the idea of the commons, but by
for-profit or nationalist interests.  Distributed Hash Tabes (DHTs) are
at the foundation of many of these new decentralized applications today
- from alternative naming systems to self-organized routing to content
sharing, social media and IoT management.  Based on the DHT
implementation (R5N) in GNUnet the project is set to provide a
specification (as an RFC draft submitted to the IETF) and two
independent FLOSS implementations (C/C++ and Go) for common use.  The
project will extent the work on GNS (funded by the NGI Discovery
programme) by the same project team.

## Excellence

### Problem Need (1000c):

Distributed hash tables (DHTs) are at the core of many decentralized
applications on P2P networks like BitTorrent, FreeNet, the GNU Name
System, Tor hidden services, RetroShare, I2P, IPFS and many other
experimental designs.  Most P2P networks deploy their own version of a
DHT, limiting not only interoperability across P2P networks, but also
frequently resulting in sub-par DHT designs, especially with respect to
security, privacy preservation, censorship resistance and resilience
against denial-of-service attacks.  The lack of standardization
(although there are some RFCs that try to cover at least some specific
DHT uses-cases or protocols) and the academic nature of DHT designs
(which usually only provide a simplistic key-value store without even
the ability to verify whether values stored under a particular key are
well-formed) are a limiting factor in a broader acceptance and
deployment of DHTs across plattforms and application domains where DHT
middleware would be beneficial.

### Ambition (1000c):

The goal of this project is (a) to draft a RFC standard paper for
distributed hash tables that satisfies a wide range of needs from
various applications, among others including censorship-resistant
key-value lookup (as needed by decentralized naming systems),
privacy-preserving lookups (as needed by anonymity-enabling services),
scalability (as needed by content distribution, social media federations
and IoT management) and build-in path discovery (as needed by
decentralized routing) -- and (b) to provide two independent FLOSS
implementations of the specification (in C/C++ and Go) than can be used
by domain architects.  The DHT will offer self-organized routing in
O(log n) hops that degrades gracefully in the presence of Byzantine
failures.  We will alo include a test suite and test vectors to allow
others to more quickly develop additional interoperable applications and
services based on DHTs.  The project will use the R5N DHT from GNUnet as
a starting point for its work.

### Technical approach (1000c):

The R5N DHT (as used in GNUnet) is an improvement over the first DHT
with self-organized and decentralized routing (Freenet; based on a
design from Oskar Sandberg's PhD thesis).  The GNUnet developers found
(and solved) serious security issues with the Freenet design (see
https://freenetproject.org/pages/about.html, including the "Pitch Black"
reference), and with R5N proposed a more resilient alternative.
However, the whole design and the actual protocol of R5N is not
specified in a consistant way, so the only "protocol specification"
today is the reference  implementation itself. Our goal is to provide a
full binary network protocol specification and the network size
estimation protocol of the R5N DHT, as well as a second interoperable
implementation of these components in Go. Furthermore, we intend to
carefully review the R5N design for potential improvements and attack
surface reduction e.g. mitigating the risk of rogue nodes spreading
false path information.

## Impact

### Impact 1 Internet Archtecture Renovation (1000c):

DHTs can help solve the decade-old problem of secure routing on the
internet.  The approaches around BGP (certifying ownership of IP address
blocks to certify routes, e.g. ETH Zurich's SCION architecture) are
resulting in a re-nationalization and balkanziation of networks.  In
contrast to this top-down authoritarian approach to routing, distributed
hash-tables follow a bottom-up self-organizing methodology that utilize
adverserial learning, self-healing and self-stabilization mechanisms
instead of administrative configuration and policies.  Beyond routing,
DHTs also offer decentralized storage, a major building block for
content centric networks (Web3) that are believed to be the successor to
today's Web.  The GNU Name System, a proposed privacy-enhancing
successor for DNS, also depends on a censorship-resistant and performant
DHT.  Various blockchain/distributed ledger implementations (such as
libp2p) also include a DHT to facilitate efficient key-value lookups.

### Impact 2 Open source contributions (1000c):

We will release all documentation, specification, source code, test
cases and benchmarking tools under the GNU Affero General Public License
and/or Creative Commons License where applicable.  We will contribute to
and engage with the standardization process of the IETF trust under the
canonical public license for RFCs.  We will also submit proposals for
talks about the project to European hacker and tech conferences.

### Impact 3 Standardization and roll-out potential (1000c):

The main objective of the project is to specify and submit a RFC draft
to IETF describing the R5N protocol in detail and to provide a second
reference implementation of R5N to satisfy the IETF requirement of two
independent interoperable implementations for any standard. The initial
roll-out will be useful for the GNU Name System (partly funded by the
NGI Discovery Programme); later roll-outs are expected to be used by the
P≡P foundation (routing message traffic with the help of a DHT) and
other projects that have already voiced their interest, e.g. the
developers of qTox that are considering using R5N in the future (see
https://github.com/TokTok/c-toxcore/issues/517).  The potential for a
DHT standard to have a broader impact is highlighted by the multitude of
projects that already use some DHT, often roughly based on the various
DHTs proposed in the literature (CAN, Chord, Kademlia, etc.) but
ultimately not interoperable and often with sub-optimal results.

## Implementation

### Team introduction (500c):

The project will be located under the umbrella of GNUnet e.V. (München,
Germany), supported and officially approved by the management board of
GNUnet e.V. and the GNU maintainers. Various members of the association
will work on different work packages; Bernd Fix will act as project lead
for the whole project. Various contributors are expected to assist with
the writing of the specification, improving the GNUnet C reference
implementation and to work on testing and benchmarking.

### Team motivation (500c):

Bernd Fix has been involved with a privacy-preserving Internet as part
of his duties at the Wau Holland foundation, which supports research,
development and education in this domain. Bernd has been instrumental in
furthering the standardization process for the GNU Name System, an
privacy-enhanced alternative to DNS. DHTs play a crucial role for
performance, availability and privacy in many P2P architectures,
motivating Bernd to work on improving the state of the art in this
important domain.

[For all members]:

* Coordinator:
  - Name: Bernd Fix
  - Gender: male
  - Role: Lead Developer
  - CV: https://hoi-polloi.org/~brf/download/CV.Bernd_Fix.en.short.pdf
  - Background (link to previous project): https://hoi-polloi.org/~brf/

* Member:
  - Name:
  - Gender:
  - Role:
  - CV:
  - Background (link to previous project):

* Comittment: between 20% and full time (depending on role)
* Gender balance (y/n):
* New to H2020: N
* NGI funds: Y, "GNU Name Service" (NLnet grant #2019-02-022)

#### Work plan with major milestones (1000c):

- Specification extraction
- Enhance reference C-implementation with signatures on paths
- Re-implementation in Go
- Interoperability test
- Performance/resilience evaluation
- submitting a RFC draft