Decentralize/isomorphize API (+ P2P, etc)

[metasoarous]

In some recent work getting local first (true sync; optimistic update; offline write availability, etc) working on clients (see commits 0fc7139, 25c93e1 and 4c75956), we've realized that using centralized Datomic eids via :dat.sync.remote.db/id on the client is an absolute mess of state maintenance. Everything ends up being much simpler if we just assume there are :db.unique/identity attributes we can use for asserting global identity between entities. As a bonus, this opens up the opportunity for us to use the same datom/tx translation mechanisms on the client and server, and thus eliminate the need for distinctions between client/server (everything is a remote, no matter where you are). This can potentially lead to a single dat.sync namespace with generalized translation functions. It will, however, involve creating some abstractions for letting us seamlessly handle DataScript vs Datomic. These may end up being generally handy as part of the public API as well.

Note that this connects with #12, as once we're fully utilizing lookup refs from identity attributes in our translations, there's no need to keep :dat.sync.remote.db/id any longer, and in fact, doing so makes it harder to get true P2P functionality.

[claj]

Yes. We use :ds/id (identity) with uuid, with squuids (to avoid index trashing) in our in-house mechanism. A slight problem is that the squuids leak creation time, which may or may not be a problem for most applications.

There also needs to be something like :db/ident in some architechtures (we sync sessions from a per client top node, so the ident equivalent needs different attributes or different schema in datomic and datascript clients).