XaviP
commented
7 years ago Good! I've been searching for a while and I've found that the psycopg2 driver (the one we're using in ocp for python->postgresql) is supported: https://www.cockroachlabs.com/docs/build-a-python-app-with-cockroachdb.html But, at the same time, it seems that django orm has not complete support: https://gist.github.com/pirate/f2931acd97d52242756d85d52b42e8bd It seems that the cockroach team has priorized SQLAlchemy orm.
Thanks for the info !!
Hey guys (:
Just going to log this here to start gathering info & investigating the feasibility of such an update, as an interim or replacement solution for a full blockchain-like Ceptr / Scuttlebutt / Ethereum / EOS backend.
So, a bunch of ex-Google engineers have released CockroachDB, heavily inspired by Google's Spanner. It is super fast, highly available, highly distributed, and allows multi-master replication as well as selective replication logic. It also seems you can configure it to run in an append-only manner. Best of all, it is also binary-compatible with Postgresql :D
As such, swapping the OCP database out for Cockroach would be (in theory) a trivial SQL dump and import. We could then use it in a mutable-blockchainish way to have many OCP instances running worldwide, all sharing the same data store. This would also improve system durability a lot.
The only barrier (in my view) is personal data- we'd probably want to encrypt that before storing to really enable it to be used as a permission-less system where anyone anywhere could run a node and be part of the network. Or, we could simply only provide access to trusted parties and do nothing more. But I digress.
Interested to hear from the core devs what effort would be involved in adding such encryption- are there many DB fields where this would be necessary? Some consideration should also be given to how the decryption process would work- my first thoughts are that you would only keep a user's decryption keys on the server "native" to that user, and this instance would be responsible for all automated processes involving that user- I'm not sure what these might be, either- but it could well be limited to sending notification emails. There may also be a need to implement an "events" system of sorts where servers can respond to updates in the database that happen outside of their own webserver requests. Again, this probably depends on the necessity to trigger actions that can't be shown to users simply by refreshing the page.
Depending on how aggressive we want to be with the encryption, we might also want to encrypt names; in which case you'd probably end up with a system where users running on other servers would be shown pseudonymously (eg. you might display
user149398instead of their real name).In future it could also be achievable to have a key export / import functionality so that a user can transfer their account between servers, though this does sound like a bit of a security headache to be honest!