A bitmessage client written in C. Designed to run on a linux mail server and interface bitmessage to mail. Has no UI, intended to be used with the linux mail UI.
Unfortunately, setting up a linux mail server is a pain in the ass. Needs the Zooko UI.
But its library contains everything you need to share data around a group of people, many of them behind NATs.
Does not implement NAT penetration. Participants behind a NAT are second class unless they implement port forwarding, but participants with unstable IPs are not second class.
A reliable udp library with congestion control which has vastly more development work done on it than any other reliable udp networking library, but which is largely used to work with Steam gaming, and Steam’s closed source code. Has no end of hooks to closed source built into it, but works fine without those hooks.
Written in C++. Architecture overly specific and married to Steam. Would have to be married to Tokio to have massive concurrency. But you don’t need to support hundreds of clients right away.
Well, perhaps I do, because in the face of DDOS attack, you need to keep a lot of long lived inactive connections around for a long time, any of which could receive a packet at any time. I need to look at the GameNetworkingSockets code and see how it listens on lots and lots of sockets. If it uses overlapped IO, then it is golden. Get it up first, and it put inside a service later.
The nearest equivalent Rust application gave up on congestion control, having programmed themselves into a blind alley.
Too hard, intolerably steep learning curve, no one is ever quite able to get their brain around it.
Tokio is a Rust framework for writing highly efficient highly scalable services. Writing networking for a service with large numbers of clients is very different between Windows and Linux, and I expect Tokio to take care of the differences.
Unfortunately rust async is beyond human comprehension, because the borrow checker does not really know or understand what the runtime is is up to, and the task of explaining the runtime to the borrow checker is dropped on the shoulders of the long suffering programmer.
There really is not any good C or C++ environment for writing services except Wt, which is completely specialized for the case of writing a web service whose client is the browser, and which runs only on Linux.
wxWidgets has basic networking capability built in and integrated with its event loop, but it is a bit basic, and is designed for a gui app, not for a server – though probably more than adequate for initial release. It only supports http, but not https and websockets. LibSourcery is a far more powerful networking library, which supports https and websockets, and is designed to interoperate with nginx and node.js. But integrating it with wxWidgets is likely to be nontrivial.
WxWidgets sample code for sockets is in %WXWIN%/samples/sockets. There is a recently updated version on github. Their example code supports TCP and UDP. But some people argue that the sampling is insufficiently responsive - you really need a second thread that damned well sits on the socket, rather than polling it. And that second thread cannot use wxSockets.
Programming sockets and networking in C is a mess. The much praised guide to sockets goes on for pages and pages describing a “simple” example client server. Trouble is that C, and old type Cish C++ exposes all the dangly bits. The QT client server example, on the other hand, is elegant, short, and self explanatory.
The code project has example code written in C++, but it is still mighty intimidating compared to the QT client server example. I have yet to look at the wxWidgets client server examples – but looking for wxWidgets networking code has me worried that it is a casual afterthought, not adequately supported or adequately used.
ZeroMQ is Linux, C, and Cish C++.
Boost Asio is highly praised, but I tried it, and concluded its architecture is broken, trying to make simplicity and elegance where it cannot be made, resulting in leaky abstractions which leak incomprehensible complexity the moment you stray off the beaten path – I feel they have lost control of their design, and are just throwing crap at it trying to make something that cannot work, work. I similarly found the Boost time libraries failed, leaking complexity that they tried to hide, with the hiding merely adding complexity.
cpp-httplib is wonderful in its elegance, simplicity, and ease of integration. You just include a single header. Unfortunately, it is strictly http/https, and we need something that can deal with the inherently messy lower levels.
Poco does everything, and is C++, but hey, let us first see how far we can get with wxWidgets.
Further, the main reason for doing https integration with the existing browser web ecosystem, whose security is fundamentally broken, due the state’s capacity to seize names, and the capacity of lots of entities to intercept ssl. It might well be easier to fork opera or embed chromium. I notice that Chromium has features supporting payment built into it, a bunch of “PaymentMethod*****Event”
The best open source browser, and best privacy browser, is Opera, in that it comes from an entity less evil than Google.
Opera needs to be configured with a bunch of privacy add ons HTTPS Everywhere Add-on, uBlock, DisconnectMe, Privacy-Badger, AdBlock Plus, AdBlock for YouTube, two tracker blockers, and three ad blockers.
It would be great if we could make our software another addon, possibly chatting by websocket to the wallet.
The way it would work be to add another protocol to the browser: ro://name1.name2.name3/directory/directory/endpoint. When you connect to such an endpoint, your wallet, possibly a wallet with no global name, connects to the named wallet, and gets IP, a port, a virtual server name, a cookie unique for your wallet, and the hash of the valid ssl certificate for that name, and then the browser makes a connection to the that server, ignoring the CA system and the DNS system. The name could be a DNS name and the certificate a CA certificate, in which case the connection looks to the server like any other, except for the cookie which enables it to send messages, typically a payment request, to the wallet.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.