Our aim is to replace lots of components (eg. the web server used for JSON RPC API access) with standard, well-known, secure libraries.
Why?
Because epee is *not* known-good, *not* well-reviewed, *not* used anywhere except Monero. It is much higher risk to keep epee around, or to roll our own stuff, than to replace it with stuff that is widely reviewed.
Why?
Because epee is *not* known-good, *not* well-reviewed, *not* used anywhere except Monero. It is much higher risk to keep epee around, or to roll our own stuff, than to replace it with stuff that is widely reviewed.
Rolling your own can be better if you are talking about complexity getting dragged in with the standard component. If you need something simple, it is often possible to achieve exceptional levels of confidence in the correctness if the component when you control it. You can use declarative systems which are provable, and compile into c++, for example. The upstream being uncontrolled adds a maintenance issue, but it is a much lower-order factor.
What is the preferred venue for such threads?
We're talking about components that require some complexity and extensibility. We're currently so heavily reliant on the Boost libraries that we literally can't get more complex by using other components.
We're also not talking about components used by one project - issues in something like Boost or 0MQ or netcpplib would affect thousands and tens-of-thousands of projects, and so they handle their efforts with care. We take similar precautions by statically compiling these in, and not updating to potentially broken versions until they're reasonable to consider safe.
There's no fixed venue, if you have a concern about a choice that the dev community has made then open a GitHub issue. That said, the contributors (ie. those that have actually submitted pull requests) are generally in the best position to know the code, so if you want your opinion to matter and not be discarded then you need to start pushing code;)
Attending the dev meetings every second week would also go a long way towards that. Opinions on design decisions from non-contributors are not discarded, but they typically won't be considered as strongly precisely to prevent interference by the sort of third-parties you'd be worried about. It's much easier for someone to make a lot of noise about a decision than to push code, which leads to loud-voices-from-non-contributors simply not being enough to affect design and architectural decisions.
" in red, but should change to something green when it successfully stores the wallet. 
How could a bad tor exit node learn your private key? mymonero.com is https encrypted.
