Revive this project

[srid]

Proposed solution

Elixir server, interacting with Dropbox to read/write underlying text files, with Elm client providing a CRUD for that data.

(See below for actual proposal)

[fiatjaf]

I like the idea of a tree of memories very much (since I read it here), but don't you think it is too much of a burden to use Postgres for this? Or to have a hosted version with logins and all that?

I mean, this is something that will be used by individuals. I can't stop thinking it should use future-proof storage, and that it should run on personal computers. I started writing a command line app with the concept of a tree of memories that would save every piece of data as a single file in the hard disk, and read all the data at startup to present it as a graph somehow (I stopped at 10 lines of code, but I thought I should say I started it), but now I think it could perhaps be a Electron app.

This is what I wrote in my idea notebook (it's vague):

An installable software or app that will save and update, in readable, plain-text format, a collection of files describing all facts of your life as you remember them, at the time you remember then and at the approximate time they happened. This is intended as a memory companion and will have a nice timeline-like GUI, but the saved files will also be readable because in the future no one knows what will happen.

What do you think?

[srid]

@fiatjaf I'm open to other data storage system (in fact I was just looking at Firebase for this project). I agree that it should be future-proof. As for running on personal computers -- my personal use case is to be able to access a personal install of Chronicle from both desktop and mobile devices, which can be achieved if there is a good local sync solution (using Dropbox/ iCloud/ etc.).

[srid]

I like the idea of saving data as plain text files and and creating an Electron app (containing Elm compiled files). It would be perfect if the same sources can be compiled to a HTML based iPhone/Android app that uses the same plain text files but synced off something like Dropbox.

[fiatjaf]

Dropbox API integration is a pain, but I don't see a better solution. Anyway, since I'm just brainstorming here and will probably contribute little or nothing besides this, let me just say that I thought about using Syncthing, which already runs on Android (it could be the Dropbox mobile app too, right?) together with a standalone app that reads and saves to plain files. The files would be synced between mobile and Desktop by Syncthing and everything would be fine.

The same app would be written for Electron and, with probably some small tweaks, compiled for Android with Cordova or other similar tools.

This seems too distant, however.

[fiatjaf]

Another idea I just had: if the app used CouchDB as the backend, it could be run entirely on client -- on the browser, as a browser extension, as an installed Electron app, as a mobile app, even as a command line app!, and all these would use PouchDB to sync the data with the main CouchDB instance powering it.

Each user could bring its own CouchDB (just a URL + password) and use the same website-version. Or they could use a srid-provided CouchDB instance (there are free CouchDB instances for low usage on Smileupps and Cloudant) that some time later them could change/replicate to their own CouchDB instances later, or them could just keep a local PouchDB folder synced, to ensure they have their own data -- this if the user cares about it.

This is not as future-proof as files are (although it is a lot future-proof, since the user can keep a totally offline copy of the data and an application that understands it forever), but since a full CouchDB state is just a bunch of JSON documents, it would be easy to later turn a local PouchDB copy of the data into a list of files, perhaps transpiled to YAML for better readability.

[srid]

Here is a totally different way of approaching this problem: what if this app was made read-only, and did only rendering (and search, filtering, etc.) of the underlying JSON data?

That way, 'adding' (new entries) can be done from other places - such as CLI tools and mobile apps. The mobile app in particular can directly add the data to JSON files in Dropbox. I wonder what mobile apps are our there to allows me to customize creation of new files (using templates) in Dropbox.

[fiatjaf]

I like the idea very much. Having separate apps for writing and reading seems great for me. Since the app will be (indirectly) interfacing with other apps, naturally a clear "protocol" will emerge ("since the reader app expects data in a certain format, the writer app must write it in that way"), which makes everything safer, more serious, more future-proof, and makes easier to write other writer and reader apps.

I don't know anything about Dropbox. I tried to write an app using their API some time ago, but gave up. I doubt there is an app that writes files based on templates, but it seems like an useful kind of app.

Anyway, your idea is to have this read-only app reading directly from the filesystem? Right now I'm interested in writing a simple CLI for writing my own memories directly to the filesystem. I didn't look too much at chronicle besides the README (although I did run it on Heroku, I guess), so I don't know exactly what kind of data does it plan to accept, but if you say it, we can agree on a kind of a protocol prototype so that my app will write files chronicle will be able to read.

[srid]

In regards to protocol, I'm inclined towards re-using an existing one over inventing a new one. As I already use Emacs, perhaps the org-mode format (which is basically a text file with outlines) can be used.

There are org-mode parsers in various languages, so implementing the 'writer' part should not be difficult.

To make the text files manageable each .org file can represent a year's worth of data (2015.org, 2016.org, etc.). Top-level headings can then refer to months, with next-level referring to days. An example .org file can look like:

# 2015.org
* 2015
** November
*** 26
- Enjoying sunny day :happy:sun:
- Sipping tea
*** 27
- Disappointed with a rude pedestrian :annoyed
** December
*** 1
- foo...

Adding a new entry would, in theory, be as trivial as appending to this file with a single line ** <thought-here> :<tags>:

And after 'summarizing' ('folding'), the file would look like:

# 2015.org
* 2015
** Summary
- A mediocre year; stressful around summer, but improved winter.
** November
*** Summary
- Overall good month, lots of sunny days and relaxing. :good:
*** 26
- Enjoying sunny day :happy:sun:
- Sipping tea
*** 27
- Disappointed with a rude pedestrian :annoyed
** December
*** 1
- foo...

---

With the above design, my proposal is as follows:

• Add a server component to Chronicle (my preference is to use Elixir language)
• This server component will talk to Dropbox for reading and writing .org files
• The client remains the same (in Elm) and talks to the server
• Dropbox based authentication is used, so multiple users can use the same web app

The client can also do the adding/editing of entries as it already does now. So a separate writer client is not required - however, you can still edit the underlying .org files in Emacs or whatever which should ultimately reflect in the web app.

[srid]

On second thoughts, it may be better to just use JSON instead of org-mode format for ease of server implementation.

[fiatjaf]

I don't use Emacs and have never used org-mode, but I kinda like it. I also like JSON, but there is already too much JSON in the world.

org-mode seems better for editing manually, even if you don't use Emacs, much better.

In this case, all entries would be in the same file? Do the entries have other metadata? Like when you remembered them?

[srid]

org-mode seems better for editing manually, even if you don't use Emacs, much better.

org-mode is also available for other editors like Sublime Text.

In this case, all entries would be in the same file?

Not necessarily.

Do the entries have other metadata?

Yes, org-mode calls them properties, but I don't see specific need for them as there are tags (the :happy:sun part in the above example are two tags for that entry).

Like when you remembered them?

This is implicit from where you position the entry in the outline, isn't it? (as in, "November -> 27" under 2015.org file means that entry belongs to 2015-11-27 day).

[fiatjaf]

Yes. Stupid question. I was thinking about when you had remembered of an event, not when that event actually happened.

[srid]

On a not so unrelated note I've been playing with mood tracking apps for Apple Watch. I particularly like moodnotes -- it allows quickly recording the feeling-state. Later on the added entries can be elaborated on the phone with thoughts and analysis.

This app does not synchronize the data; there is only manual export. And, of course, there is no 'fold' feature.

I think it would be worth looking into creating an app like this that synchronizes to some backend (eg: sqlite synchronized to backend server, with backup option uploading to Dropbox) and then have the 'fold' feature on top. I'm not at all keen on having web UI (Chronical project is essentially a web UI on top of postgres) anymore, as it is looking like mobile (phone, watch) is going to be the future. Besides it is very very convenient to enter feelings from my watch than having to fiddle with a web UI even from a smart phone.

[srid]

I've been playing with mood tracking apps for Apple Watch [...] I'm not at all keen on having web UI [...] anymore, as it is looking like mobile (phone, watch) is going to be the future.

A couple of things have changed since I wrote that about 2 years ago (has it been really that long?):

• I've switched from Mac to Linux, thus I'm not at all keen on continuing to invest in Apple's ecosystem.

• Frameworks like React Native have shown that one can use web technology to write native-feel mobile apps. At that time there was nothing like that in Elm. However since then, given Elm's shortcomings, I've gradually moved to GHCJS (Haskell). Specifically I've been playing with Reflex which has a pretty good story (albeit not yet publicly documented) for native mobile.

Thus, I'm quite interested in resurrecting Chronicle as a Reflex app that runs on both Web and Mobile using the same (Haskell) code base. It will most likely be a completely rewrite of the current Elm code base ...

[srid]

Thus, I'm quite interested in resurrecting Chronicle as a Reflex app that runs on both Web and Mobile using the same (Haskell) code base.

Here it is--still in prototyping phase.

[srid]

If anybody is wondering, I've recently moved on to a system called Zettelkasten that implements the principles of chronicle (but in a less limited fashion; DAG not tree). See https://github.com/srid/neuron#neuron