yes it is. What it does is • user enters and sees the marks on calendar on the days he/she attended • user marks today as attended • all these with authenticating tokens

This is super cool, and impressive! Extracting some links while I read it: https://www.krestianstvo.org/ https://docs.krestianstvo.org/en/introduction/ https://en.wikipedia.org/wiki/Croquet_Project https://www.krestianstvo.org/docs/about/publications/ https://blog.codefrau.net/2021/08/what-is-croquet-anyways.html

; Reference implementations:
; Virtual Time 
; Reflector server 
; Future Message Send  ()
; TODO: Portals 

> I am interested in how this suits Electric, and if this type of architecture can be realised even without introducing Croquet on top of it • Electric runtime is backpressured, which means that if you pause the network (try it with browser dev tools), messages are queued and will go through when network is unpaused. We see "offline as just online with extreme latency". This builtin capability seems to overlap a lot with this userland event system • The mouse cursor is lagged presumably because it is round tripping through the server? We're working on improving our optimistic state abstractions for cases like this (we are focused on perfecting our crud forms first, but the underlying primitives should be the same for things like mouse cursors)

I don't really understand the Croquet architecture yet, specifically I don't understand this exactly yet: > In Croquet application architecture the state is never going outside the client and is updating in sync by using local internal queues of messages (Future message sends). These queues advanced in virtual time by receiving the control tick (metronome) message from the Reflector. All user-land events are also stamped by Reflector and distributed to all the clients back (sending owner too), forming very low net traffic.

Yes, there is a good explanation of Croquet VM on their current version (Croquet OS) https://croquet.io/croquet-os/

Croquet OS is closed sourced, but it has the same architectural components, that I try to implement currently (based on Virtual World Framework aka Croquet IV)

What is your relation to this project? Krevistiansvo is your project?

"Croquet OS provides a kernel that enables bit identical shared simulations between users." Is there a rationale for this capability? Why is bit-identical simulation something that virtual worlds need

Yes, I am a founder and developer of Krestianstvo project. I am working with Croquet since Smalltalk version.

Sure, bit-identical simulation is a crucial concept for virtual worlds, as when simulation is going no network traffic is involved. Clients getting only timestamps from reflector, which advanced the simulation.

"when simulation is going no network traffic is involved" -> what about syncing user I/O?

All user-land events needs to go to Reflector to be stamped and then distributed to all the clients back. That's considered as the minimal traffic (like mouse coordinates or clicks). The application state is stying on client side.

how is latency mitigated?

Ah, I guess the simulation state excludes cameras for example, it's the scene graph which is synced and consistent?

Right, users operate through local Views on a synced Model.

if the model state is a reduction over global event log, and this reduction is replicated on each client (peer?), then the global event log is replicated to each client/peer, so sorta like a bitcoin node? What if the number of events is large

reading this https://blog.codefrau.net/2021/08/what-is-croquet-anyways.html

Yes, that's great introduction! As for the latency, clients with low speed network will not pause the clients with hight speed traffic, that's was the key feature of Croquet. In the contrary to lockstep algorithms.

So the reflector runs in the edge, all events are funneled through the reflector (which is like a transactor, it decides a globally consistent total ordering). It sounds like https://www.cloudflare.com/products/durable-objects/

To map to electric/missionary: synced Model - this is discrete event streams, in simplest webapp terms this is basically the database transaction log? local Views - this is continuous time lazy rendering, electric maps best to this part

The question of if the synced model (the transaction log) is replicated or centralized - Electric doesn't care, we would say this is a data plane decision, some databases replicate and others are centralized

The Croquet event layer is probably better than ours, this is the part where there is overlap, it is comparable to our optimistic crud form sync abstractions which we haven't really talked about or shown yet. Our optimistic form state sync is done in Electric userland not the runtime

So it makes sense that there is overlap, and your project makes sense in an Electric worldview

Did I get this right?

great

Have i answered your original q?

Yes, thank you Dustin! I am really excited with Electric and would like to do a lot with it!

That's demo video of the prototype.

Is this accurate: The big idea is to use the Electric distributed runtime as a basis for a higher level scene graph sync abstraction for use in collaborative virtual worlds.

Here is a good explanation video of David P. Reed at OOPSLA '05 talking about Croquet architecture. "Designing croquet's TeaTime: a real-time, temporal environment for active object cooperation" https://dl.acm.org/doi/10.1145/1094855.1094861

Here are the slides from the presentation.

I think (last i looked) server actions are RPC (meaning not a scalable composition model), tbh I struggle to manifest the attention to slog through all the complexity and adhoc machinery to figure out all the ways their thing is broken, perhaps someone who has used it can compare

We have a https://github.com/hyperfiddle/electric/blob/master/src-docs/user/demo_reagent_interop.cljc. Does that help?

Yup, that's enough. Thanks!

new is used to call electric functions. Since F and InputSubmit are electric functions you have to call them with new. Note that the e/defn macro will rewrite the code so it has the semantics of a function call and is not a regular usage of new

https://electric.hyperfiddle.net/user.tutorial-lifecycle!%4Cifecycle

Got it, thanks.

just e/for-by, should work with anything sequable. https://electric.hyperfiddle.net/user.demo-system-properties!%53ystem%50roperties

I get a #{set} of [vecs of {maps}] so it's interesting figuring out how to unpack it

#{[{:details "deets'}] [{:details "detes"}]} not sure how to `e/for-by it

ideally the input to e/for-by is a vec of maps?

I got it working but it looks mental 😅

tracks (-> (xt/q db '{:find [(pull ?track [:track/id :track/album-id :track/title])]
                               :where [[?track :track/album-id album-id]]
                               :in [album-id]}
                             album-id)
                             vec
                             flatten
                             vec)]

and then for whatever reason calling it just track works instead of track/title

(dom/div (dom/props {:class "track-cool"})
            (e/server 
              (e/for-by :track/id [{:keys [track/id track/album-id track/title]} tracks]
                (e/client 
                  (dom/div (dom/text (str "track " title)))))))

@U055PQH9R4M the flatten will be expensive. You can do (map first (x/q db …)). @dustingetz is it advisable to pass a sorted seq to e/for-by or does the keyfn imply a sorting seq? I assume you’d want a sorted result but also keyed for efficient updates.

e/for-by does not sort, it is a sequential traversal same as clojure for

e/for-by performa diffing internally for stabilized reactive updates, which is a traversal, so pass reasonable collections (like a page of database records, not 1000 records)

the DOM itself can only handle about 2k nodes anyway

@U055PQH9R4M I think you’ll want to add a :sort-by clause to your XT query, or sort-by the query result before passing to e/for-by to avoid the diffing, or does the diffing always occur?

diffing is necessary to handle updates effectively. It's the same as in e.g. react where you have a dynamically updating collection and need to provide a key

to be clear, diffing is separate from sorting. e/for-by renders dom elements in order, it can render any sequence not just UIs that are in sorted order