Open matthewhammer opened 4 years ago
cc @gobengo
Are the real time collaboration features required from the beginning? If so, do you intend to use CRDTs?
@gobengo I would like to use those if needed, but I would like to not need them in the short term.
Two more answers:
Yes and no. A single-user version would still be cool, and interesting.
(*) For a simple IC-only solution that works for multiple users: I think that we can use some ideas from ic-game-terminal to have a pretty good experience for collaborative (non-adversarial) users. That link points to a description that I'd like to highlight:
The updateKeyDown and queryKeyDown messages are related, and the SHIFT key controls when they are each used...
In short, the game terminal collects and sends a keyboard buffer in either query or update mode, and the SHIFT key controls which mode is active.
Both modes use the canister to repaint the frontend view, and do not require any difference in how they process results from the canister (just how they feed keyboard input to it).
Ideally, using the SHIFT key wouldn't be needed at all (it was more for a POC experiment), and instead, the front end software would do all of this keyboard buffer management behind the scenes.
We started trying to do this in this PR, but it didn't ever quite work because of some library interaction issues in Rust:
https://github.com/matthewhammer/ic-game-terminal/pull/15
(*) I think this trick works for any collaborative setting, which is the normal case for Etherpad and many other things too. e.g., I daydream about the future of programming and I imagine collaborative IC-versions of live programming environments like Hazel.
Write a minimal implementation of Etherpad in Motoko, to demonstrate using this codebase for collaborative text editing and text search.