
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.<p>So far I&#x27;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.<p>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&#x27;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.<p>Maybe there is someone who has been writing a diary &#x2F; 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.

