Clojurians Log v2

Just to give some perspective. @cjsauer Is any of that helpful for your framework?

@whilo yes absolutely, very helpful, thank you. I’ll be watching that video soon and will return with questions :) >I designed them to be UUIDs because they should not accidentally clash globally Makes sense. I’ve been devouring any replikativ material I can find, and the concepts are starting to become clearer. > hasch.core/uuid can map values to unique UUIDs. What is the difference here from normal UUID generation? Does this mean that the resulting UUID is somehow content-addressable? > user-id is supposed to refer to an external identity system that can be used to authenticate users Authentication is still where my understanding is lacking. I’ve been reading through kabel-auth source, and am having trouble fitting my understanding with this distributed paradigm. Does kabel-auth still imply a central server authority, correct? The server is “special” in the sense that it can hand out auth tokens, and is in control of certain data mutations. How does authorization work in these systems? For example, what prevents me from seeing/mutating someone’s potentially private data? >Are you aware of datsync? Yes! I stumbled across datsync a while back, and it has been great inspiration. Tightrope attempted a slightly different approach, specifically around entity IDs and schema sharing (datsync is a bit more sophisticated here). >We are currently working on import utilities from Datomic to datahike This would be great to avoid “lock in”, but sounds non-trivial. One of the hard parts about these “datom-based” dbs that I’ve encountered is that they’re all slightly incompatible in nuanced ways. For example, I recently contributed unique-identity-cardinality-many attributes to datascript in 0.18.7, but the discussion to do the same in Datomic was mostly ignored. So now the two diverge even further…I would love to see a shared protocol for these databases that we could all adhere to, but that seems very unlikely given datomic’s proprietary model. Datahike being forked from datascript tho is very promising. It’d be great to see them retain equivalent semantics. >And ncg is working on 3DF Ah yes, I saw Nikolas’s talk at Conj 2018 about 3DF. Incredible stuff. > A problem is to prioritize things and getting some help I’m certainly interested in contributing where I can. Mainly I’d love to see these ideas/experiments all aggregated into an off-the-shelf Clojure app framework. I think that could do really great things for Clojure’s popularity. I think too that it could really help developers transition into this more distributed architecture/paradigm, which admittedly still hasn’t “sunk in” for me personally (hence my questions above).

Yes, exactly it is content addressable. The idea was to have public private key authentication and link that to other identifiers, e.g. by accepted authorities or trust networks.

Yes we would like to stay compatible with DataScript. So far we have not had any discussion with Nikita yet though.

👍 for a unified framework, I would say a unified, reactive datalog programming model would be ground breaking.

> The idea was to have public private key authentication and link that to other identifiers, e.g. by accepted authorities or trust networks. I just finished watching the talk you linked. Thanks for that. The piece regarding authentication that stuck out to me is when you mentioned “a single CRDT for app state”; does this necessitate some form of consensus, or am I thinking about that incorrectly? If I were to build a more traditional web stack with replikativ today, and wanted to authorize data access (and mutation), it seems I would have to split the app state into several CRDTs, and then guard against unauthorized subscriptions/changes to them.

“Consensus” meaning something like Tendermint, as you mentioned in your talk. Reading up on that now…

Looking into swarm.js, it seems they do indeed fracture the app state up into “nodes”, each being a CRDT

> For example, I recently contributed unique-identity-cardinality-many attributes to datascript in 0.18.7, but the discussion to do the same in Datomic was mostly ignored. @cjsauer This is already possible in Datomic. In fact, this is how you can "alias/rename" an attribute; It's possible to have multiple :db/ident assignments for a given entity.

@metasoarous interesting. Is :db/ident a special built-in in some sense? I’m referring specifically to the constraint that :db.unique/identity attributes must also be :db.cardinality/one. Datomic’s documentation states this explicitly. What’s interesting tho is that it works exactly as one would anticipate, but this is apparently an “accident” and not officially supported. There’s a very brief forum post about this here: https://forum.datomic.com/t/unique-cardinality-many-attributes-why-not/1208

Datascript also had this constraint, and so when attempting to upsert entities using a unique-card-many attribute whose value was a collection, you’d get an exception. That is no longer the case. Datascript will now reduce over that collection and ensure that each value does indeed resolve to the same entity, otherwise it results in a conflict.

It was actually datascript’s exception that brought this to my attention in the first place…I was using unique-card-many attributes in datomic without issue, and only when syncing them to datascript did things go wrong. I’ve since refactored away from using them so I can stay on the supported path, begrudgingly 😉

I’m curious tho if datahike would consider merging that PR. I still believe the semantics are perfectly valid.

I just tested this on Datomic Cloud and it worked

Yeah, I was testing on Cloud as well. Apparently tho it’s not actually supported. When I brought it up in #datomic, Marshal was actually surprised that it works at all. They’re considering adding a schema exception/warning if you attempt to assert unique-card-many attributes.

So, it works today, but I suppose it might not work tomorrow

Ah; Interesting.

I wonder how :db/ident and aliasing will get handled then...

Not sure. Could be that datomic handles those cases explicitly for the purposes of aliasing? Datascript doesn’t actually assert the cardinality of :db/ident: https://github.com/tonsky/datascript/blob/184665afeb9c969662ef74f312c9ebce3cfad255/src/datascript/db.cljc#L23 I think in that case it acts like card-one.