Hi Christian- Thank you for posting this work.
My post is somewhat off topic for this list, happy to take conversation to other channels. I'm very interested in anti-silo use cases, and have been following closely the Bitcoin ecosystem- not specifically the coins-as-assets use case, more the assertions-in-a-distributed-public-ledger use cases. What has struck me as a key requirement in being able to escape from private data silos is the ability of these repositories to operate in a hostile/untrusted environment, while necessarily needing to maintain their integrity. If repositories are public, they have to be resilient to all kinds of attacks and hostile behavior. If they're private- then they're private- silos under control of an entity who themselves bears these costs in exchange for requiring user trust. The solutions in the BTC space are of course now of myriad variations on "blockchains" where individual factual assertions are cryptographically linked to individual asserters and it is either cryptographically difficult or economically expensive to perform various attacks on data integrity. Long story short, BTC has been a very interesting experiment in shifting the costs of silo data custody from massive individual players with direct control, to pools of players who only have indirect control- obviously successful in some ways and failing in others. But the anti-silo vision this architecture enables has captured the imagination of many. Your work on Replicativ refers to a "vision [that] is more ambitious by creating open data systems instead of just optimizing the privatized Internet of data silos." I'm very curious- do you have thoughts to share on these particular issues of trust and cost when it comes to data integrity? Thanks in advance! Jonah On Tue, Jan 19, 2016 at 3:28 PM, Christian Weilbach < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > after three years of laying ground-work for a cross-platform database > in form of many libraries (1), doing research about CRDTs and > stretching core.async and other libraries as far as possible, I am > happy to finally announce a first release of replikativ: > > replikativ is a replication system for confluent replicated data types > (CRDTs). It is primarily designed to work as a decentralized database > for web applications, but can be used to distribute any state durably > between different peers with different runtimes (JVM, js atm.). > Instead of programming thin web-clients around a central server/cloud, > you operate on your local data like a native application both on > client- and (if you wish to) server-side. You can also view it in > reverse as a cloud being expanded to all end-points. You can write to > CRDTs whenever you want and also access values whenever you want no > matter if the remote peer(s) (servers) is available or not. In > combination with our CDVCS datatype you can imagine it as git for data > (expressed e.g. in edn) + automatic eventual consistent replication. > > https://github.com/replikativ/replikativ > > > While there are still some issues and the design is not completely > finished, I am pretty confident from our different design iterations > and our running prototype that the current one can avoid > race-conditions and is robust to errors. The interesting standard > CRDTs are still missing, but I decided to first hear some feedback > before growing the codebase and implementing optimizations. > > Let's build more open systems and share data, > Christian > > (1) https://github.com/replikativ/ > > P.S.: The prototype https://topiq.es is currently hosted on a home > server, if it loads too slowly, I will move it, but so far I felt a > bit romantic about my basement and didn't want to spend money for an > AWS instance or something else. Feel free to host your own instances > and to connect them ;), it should be straightforward. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJWnpxRAAoJEKel+aujRZMk/uUIAMbAHVHOo0zNbbRr6QsapiLN > ohQHTVqixkj/8qS3+z6ZmEGy572t2DH+QzXpHOqtqAS3mxGMikFKk078yWAYD3W3 > QbZoxssDjgu/CGWsGAjuUetd8DoI1vI1T1oAVTo4IDo9uot5NEDHs3s5ZLB50NIX > WOjm/muSPwkTt6B+oIp8ZsEYCH6RyLzTqkK6rOXxF0OoPv2XuK+TMgQJVzskmiaI > 59Yf1TLizERN6DpyZbtFrWiVlgFF0+0K7GyW1qa7Bp7Yf9LE9yGra2WMjRwDdg7z > 3SbZb5aXc/yaGztu+yN0wq3BWFCRSZQ9fh+VjrltGMA9BfExr53/aed1bIIcAtY= > =v65c > -----END PGP SIGNATURE----- > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
