Fork me on GitHub
#datahike
<
2023-10-25
>
favila12:10:16

Hello! Unsure where to post this, but datahike is a replikativ project so this seemed ok. I noticed the https://replikativ.io/ cert expired on september 1st.

timo12:10:00

thanks, I will try to pass it on

whilo05:10:55

Thanks for reporting, i did not check lately.

favila12:10:59

I’m also curious about what happened to replikativ itself (i.e. the p2p crdt and replication bits, https://github.com/replikativ/replikativ). Attention seems to have moved to datahike, although I realize many replikativ support libaries are shared between the two projects (konserve, kabel, etc)

timo12:10:37

I think @U1C36HC6N is still very much into this and with the new distributed capabilities it made a step in this direction again.

whilo05:10:46

@U09R86PA4 Yes, in fact there is an underlying unified lattice based perspective on Datalog and replikativ. On a practical side kabel and replikativ need to be dependency updated and then integrated with the way Datahike is storing data. I have worked on a variant of https://speakerdeck.com/ept/data-structures-as-queries-expressing-crdts-using-datalog?slide=22 for CRDTs as well. What are you interested in in particular in replikativ?

favila15:10:33

My interest was in using it as a framework for local-first (webapp platform, with cloud replicas) tenanted datasources with peer synchronization and replication. I stopped following the project about 4 years ago because my job and the problems I was working on changed. I recently had reason to be reminded of replikativ, and then serendipitously the next day there was a big Datahike release, so I reached out.

whilo22:10:47

Nice. Yes, Datahike in a sense is a bit more pragmatic, since it allows you to cover distributed read scaling with a well behaving data retrieval model through Datalog queries. replikativ is more general, but requires more upfront investment into building a CRDT data model for your domain. Being able to share read-only data in a unified query language environment (distributed index space as I coined it) is a good intermediate step to better distributed programming, I think.