Ask HN: Software for writing a diary that will be around in 20 years from now

[iagooar]

I guess this is a bit of an unusual question. Yesterday, my first child was born and I decided to start writing a diary. The twist is that in this diary I want to write about our experiences together as a family and include pictures and other digital material there. By age of 18, my gift to him will be to give him access to the diary.

So far I've considered opening an email account and sending mails to it so that it keeps everything in place. The other would be to keep stuff as files and use some software to manage it. Backup would be spread across my own devices and the cloud.

Is there anything the HN crowd can recommend that for sure will be there in 20 years? The email option sounds good, but I won't ever trust Google to keep a service running, and other paid options are not better. A self-hosted email-server is too much of a hastle.

Maybe there is someone who has been writing a diary / journal for a long time and wants to share how they do it?

[beamatronic]

I would use the most low tech thing imaginable. Structurally your "Diary" folder might contain a series of timestamped folders, one for each entry. The time stamp you'd want to use is YYYYMMDDHHMMss, for easy sorting. Inside each of those folders I'd write the diary entry as a plain .txt file and you could include the digital artifacts ( .jpg ) in the folder as well, or create sub folders "images", "audio", etc. Using this as your "system of record", it is easy to create a recursive zip file of all the entries, and this zip file is easy to encrypt and sync around ( email, Dropbox, Google Drive, USB sticks ). If you ever need to compare or merge you can use a tool like Beyond Compare which makes it a snap to recursively examine/compare two folder structures.

[beamatronic]

I also wanted to say it is easy to iterate over this basic format and use a script to generate HTML for example as a derivative work.

[katkattac]

Plain text is your best bet. You can just save images along beside it. Backup often.

If you must have images inline, you could probably use Markdown to include them. Markdown will almost certainly be around in 20 years, but if it's not, writing a parser for it will be self-explanatory and won't take long.

[alphapapa]

Emacs with Org-mode. Emacs has already been around for longer than that, and will surely be in 20 years. Org-mode is a part of Emacs and isn't going anywhere. Plain text with extensive markup support, including inline images, code, inline HTML/LaTeX, etc. Easily export to HTML, PDF, blog, etc. Easy to store, backup, sync, version-control, etc.

[bwackwat]

I see how a mail server would be annoying to maintain. How about a file server with server-grade hard disks setup in RAID?

I hope current digital file storage strategies and Ethernet internet exists in 20 years!

[niftich]

There are a few distinct issues at play:

1. Authoring software

2. Schema and metadata that relates the entries to each other into a cohesive whole

3. Format of a single entry at rest, including multimedia

4. Persistence and backups

A lowest common denominator solution is "plain" text files with all the entry metadata included in each file; or a dated folder for each entry and all associated data (pictures, videos, etc) in that folder.

Email does give you an out-of-the-box solution for this, because authoring software is widely available, and each MIME message includes the posting date, the author, the body (in multiple formats, if you so wish), and any attachments.

IMAP can be used to copy messages up and down, POP can be used to download them such that they disappear from the server, and some cloud providers like Gmail have their custom APIs to access messages. A robust way of backing this up is to have a custom script that downloads messages through IMAP, copies them up to a different cloud provider, and saves a local structured backup (.mbox or Maildir) as well. These formats are commonly understood and don't venture very far from the innate structure of Email itself, so even if software to parse them becomes rare, they can be understood in a simple text editor, and could even be reasonably reverse-engineered.

For multimedia, stick with formats that are widely deployed today and backed by major standards bodies or industry consensus -- even if they are patent-encumbered. Installed base often trumps ideology, for practical reasons. JPEG is 24 years old and still in common use. H.264 is an official codec for Blu-rays, so it'll likely be supported for a long time, similarly the older codec MPEG-2 was used on DVDs, and is unlikely to irrevocably disappear. Uncompressed PCM, MP3, and AAC-LC should be your choices for audio.

I'd be wary of the archival potential of formats that are solely used on the Web with little usage on tangible physical hardware by major commercial publishers -- the Web of today moves very fast and technologies come and go. Google is pushing WebP, WebM, but work is already under way on a big consensus format called AV1. When AV1 comes out, new VP8/VP9 content will likely no longer be produced. Browsers periodically prune older features, 20 years is almost as long as the web has been around, and given enough time support for the format may only be available in software that make format coverage an explicit goal (ffmpeg, libav, VLC). Opus is being made a mandatory audio codec for WebRTC, teleconferencing is usually ephemeral -- will there be lots of .opus files sitting on disks in the future? Too early to tell, not worth gambling on.