We’ve had enough of digital monopolies and surveillance capitalism. We want an alternative world that works for everyone, just like the original intention of the web and net.
We seek a world of open platforms and protocols with real choices of applications and services for people. We care about privacy, transparency and autonomy. Our tools and organisations should fundamentally be accountable and resilient.
> I was thinking: does this almost reduce to the "hard AI problem?"
Detecting which nodes are malicious might not even be computable. It's the lack of verifiable information. Unless you have some trust anchors to create a frame of reference you can never tell who is defecting vs. who is lying about others defecting. And as I think about it, the only way to distinguish a targeted attack from a node being offline is to establish that it is online, which requires you to have a communications path to it, which would allow you to defeat the attack. So unless you can efficiently defeat the attack you can't efficiently detect whether one is occurring.
So I guess "detect then mitigate" is out. At least without manual intervention to identify that an attack is occurring.
> The Bitcoin network solves the trust problem by essentially trusting itself. If someone successfully mounted a 51% attack against Bitcoin, nothing would be broken as far as the network is concerned. But that's not what *we*, the sentient beings that use it, want. We want the network to do "the right thing," but what's that? How does the network know what the right thing is? As far as its concerned, when 51% of the network extends the block chain that's the right thing... right?
Another way of putting this is that the Bitcoin users solve the trust problem by trusting the majority, where resistance to a Sybil attack comes from allocating votes proportional to computing power. Which works great until some entity amasses enough computing power to vote itself God. And you can do similar with other scarce or expensive things. IPv4 public addresses come to mind. Useful for banning trolls on IRC but if your attacker has a Class A or a botnet you're screwed.
> You could solve that problem pragmatically though by shipping with acceptable defaults. If a user wanted to change them they could, but they don't have to.
> One idea I've had is a hybrid system combining a centralized database and a decentralized DHT. Both are available and they back each other. The central database can take over if the decentralized DHT comes under attack and the decentralized DHT will work if the central system fails or is blocked (e.g. in a censorship-heavy country).
I've been considering doing federation similar to that. You have some node which is essentially a dedicated DHT node and a bunch of clients which use it as a gateway to access the DHT instead of participating themselves. So you have a lot of ostensibly related clients all using the same gateway and when they want to contact each other they get one hop access and no Sybil exposure. And if the gateway is down the clients can still participate in the DHT themselves so it isn't a single point of failure.
> Everything related to TUN/TAP on every platform is nearly documentation-free. :)
The Linux implementation never gave me any trouble. https://www.kernel.org/doc/Documentation/networking/tuntap.txt says how to create one and then you configure it the same as eth0.
Maybe the trouble with TAP-Windows is that it's idiosyncratic (to be kind) in addition to undocumented. Have you discovered any good way identify your TAP-Windows interface as something not to be molested by other TAP-Windows applications like OpenVPN? There is some language in the .inf about changing the component ID which seems to imply recompiling the driver and then probably needing a code signing key from Microsoft to make it work, but there has to be some less ridiculous way of doing it than that.