Add BPASE state of the art

[qstokkink]

Some recent advancements in key fragmentation (pyUmbral) and proofing (Bulletproofs) can be integrated into IPv8's ID framework for large performance gain.

[qstokkink]

Bulletproofs turned out to be way too slow.

[synctext]

Related work similar to IPv8 overlay (not identity part) :

• IPFS/ Libp2p https://github.com/libp2p/specs/blob/master/3-requirements.md

• Pulsar Apache pub-sub https://github.com/apache/incubator-pulsar

• FreeLAN https://raw.githubusercontent.com/freelan-developers/freelan/master/fscp.txt

• ToX https://toktok.ltd/spec.html#goals

• UDP punching https://github.com/vi/udpnat

• Telehash http://telehash.org/

• OpenOverlayRouter https://github.com/OpenOverlayRouter/oor

• Maidsafe Crust https://github.com/maidsafe/crust/blob/master/README.md

Our design philosophy is to enable trustworthy any-to-any communication. We want a very light-weight approach. For instance, libp2p is a much more heavy and broader approach. See their feature set:

• Enable the use of various:
  • transports: TCP, UDP, SCTP, UDT, uTP, QUIC, SSH, etc.
  • authenticated transports: TLS, DTLS, CurveCP, SSH
• Make efficient use of sockets (connection reuse)
• Enable communications between peers to be multiplexed over one socket (avoiding handshake overhead)
• Enable multiprotocols and respective versions to be used between peers, using a negotiation process
• Be backwards compatible
• Work in current systems
• Use the full capabilities of current network technologies
• Have NAT traversal
• Enable connections to be relayed
• Enable encrypted channels
• Make efficient use of underlying transports (e.g. native stream muxing, native auth, etc.)

We have a similar Design Philosophy to Telehash. Theirs is copied here

The primary idea that drove the creation and development of telehash IPv8 is the belief that any application instance should be able to easily and securely talk to any other application instance or device, whether they are two instances of the same application, or completely different applications. They should be able to do so directly, and in any environment, from servers to mobile devices down to embedded systems and sensors.

By enabling this freedom for developers as a foundation for their applications, telehash IPv8 enables the same freedom for the people using them - that the user can connect, share, and communicate more easily and with control of their privacy. The challenges and complexity today in connecting applications via existing technologies such as APIs, OAuth, and REST are only increasing, often forcing fundamentally insecure, centralized, and closed/gated communication platforms. By adopting telehash, an application immediately has a powerful set of open tools for its own needs, but can also easily enable connectivity to and from applications created by others. These tools include the ability to have friends, sharing, feeds, tagging, search, notifications, discovery, transactions, and other social patterns.

telehash IPv8 has a fundamental requirement to remain simple and lightweight in order to support applications running on networked devices and sensors. The design goals also include not forcing any specific architectural pattern such as client-server, centralized/federated/distributed, polling/push, REST, streaming, publish-subscribe, or message passing... any can be used, as telehash simply facilitates secure reliable connectivity between any two or more applications in any networking environment.

[qstokkink]

I've taken the time to investigate in-depth and read through the code; I concluded that the technology is interesting, but not interesting and/or mature enough to include in its current form.

As I see no immediate gain, I will close this issue. We can open other issues as new solutions surface.