I spent most of the last week reading the source code of the current C++ implementation, especially the Routing and RUDP parts. The event-based nature of the code and the concurrency-handling parts make it hard for me to follow the core logic of the algorithms. That will probably come with usage and experience. I recon though, that the two main advantages of the current C++ implementation are its ultimate performance potential, and the security of depending on the least amount of trusted code.
On the other hand, I find it hard to inspect the code to convince myself of the correctness of the algorithms, and the running system to get an intuition of its behaviour during execution. Since I am trying to produce a presentation that will introduce the core ideas of the system, its would seem useful to have an implementation of the same algorithms that might run in a web page using event-based JavaScript and WebRTC for peer-to-peer communication (which would replace rudp). The implementation might compromise on (1) security by leaking some meta-data information about connections between peers, (2) performance by running everything in a single-event loop in JavaScript, and (3) have left-over ācentralizedā components that are required to established connections between peers, but would otherwise implement the exact same algorithms. That would probably simplify the implementation and make it easier to inspect the dynamic behaviour of nodes, by leveraging all the JavaScript frameworks for visualization (such as D3.js).
In addition, by aiming for full API-compatibility with the C++ +JavaScript bridge implementation, that would probably allow Web Application Developers to start developing their apps faster, before the ārealā network is live.
I am thinking of reimplementing the Routing library as a first step, and maintaining compatibility with the Routing API, as defined in ārouting_api.hā. That could be used to develop a first chat application. All information that would need to be persisted would be stored on the server that is used to established the peer connections. Needless to say, that would be highly insecure so no important user data should be stored.
One major advantage of that implementation, would be to demo the changes in the state of the network as nodes are added, removed, and communicate with one another. The second major advantage would be to make it a lot easier to deploy for web app developers, since a single library would need to be added to their one-page web application. As long as the API is fully compatible, it would mean they would simply have to change the library being used when the real network will be up.
Let me know what you guys think of such a project. I would like to make sure it is seen as a complementary implementation and not a hostile āforkā.