Use etebase instead of a custom sync server

[djmitche]

@savchenko suggested this (I believe! possibly @dbr?)

https://www.etebase.com/ defines a very generic, end-to-end encrypted sync protocol, with a server implementation and lots of client libraries, including one in Rust.

From a brief read of the docs, I think one way to approach this, while maintaining the detailed OT semantics we've established, would be as follows:

• Each task history corresponds to a single Collection (what is called a "client" in the current sync-server protocol) of type taskchampion.task-history
  • That collection's data is a structure containing, among other things, latestVersion, which takes the form of an Etebase uid (I can't find more about this than just "it's a string", but that's OK)
• Each history segment is stored as an item in that collection, of type taskchampion.history-segment
  • That item's data contains a parentVersion (uid) and the history segment
• AddVersion is just a transaction adding a new Item and updating coll.latestVersion
• GetChildVersion doesn't have a direct analog, then. The use of GetChildVersion was for a Replica to iterate forward in the chain of versions from its own latest version toward the server's latest version. But the proposed organization would index by version, not by parentVersion -- and it doesn't seem there's a way around that. Probably the best approach is to iterate backward, starting with coll.latestVersion. The risk is that if the two histories are unrelated, it will take a long time with many fetches to figure that out. That could be overcome by putting a timestamp on the versions and stopping the search if the returned versions get too old.

Note that this would not interoperate with iCalendar TODO items. I think that building a CLI to do so would be neat, but it isn't TaskChampion as the semantics of those TODOs would be totally different.

Thoughts? This actually sounds pretty easy, but that's without having written a line of code yet :)

[savchenko]

Yeah, I was testing EteSync for encrypted DAV transport and stumbled upon EteBase which was subsequently mentioned during our conversation.

Additional bonus: this should greatly simplify "Android client" as it can defer synchronization to https://github.com/etesync/android.

@tasn, do you have any opinion on the outline written by Dustin?

[djmitche]

I put in an issue for this in #175.