quinthar

Expensify.cash end-to-end encryption proposal

Hi! I'm one of the developers behind Expensify.cash (and the CEO/founder of the company -- chat with me on Twitter @dbarrett) and these are some quick notes on how we might add end-to-end encryption. I'm generally familiar with the basics of encryption, and have read quite a bit on the Signal protocol, but am no expert so am eager to get advice from those who are. In particular, I would like to build a system optimized for simplicty and security against very plausible real world attacks people care about, without overengineering against exotic attacks that are unlikely to happen in the real world.

tl;dr

In short, I think this design can make Expensify.cash provide very strong protection against Your Friends, Your Boss, and Lawyers. And I also think it will protect you from The Cops, Hackers, and The Feds for all but the most severe concerns. **But no amount of encryption will protect you fro

quinthar

Explanation of how a cluster might do multi-leader replicated transactions using vector clocks

BedrockDB is a highly distributed, WAN-replicated, fault-tolerant database: read BedrockDB.com for more. Of particular relevance to this Gist, the design is such that the client (eg, webserver) sends every "command" (ie, to trigger a stored procedure written in C++ on the Bedrock node) to any node in the cluster -- the client needn't treat any node special. However, in practice one of the nodes is very special: it is the "leader", which coordinates distributed two-phase commit transactions.

Problem:

In practice the extra burden upon the leader isn't normally material: most commands that generate write activity generate roughtly the same number of "extra" queries on the leader and follower -- after all, anything that changes the database needs to be replicated out to followers using the same queries. However, there are some write commands that do a tremendous amount of "extra