Hi everyone.

I am making some changes to the way I do my newsletter, so I can write more regularly.

  1. This mailing list is going to be more focused on Diaryx and technical topics.

From September to May next year, I will be a part of the Sandbox startup incubator program at BYU. I am going "all in" on Diaryx, and plan to do everything I can to make it a real company with sustainable revenue. A big part of this is being more open about the work I do on Diaryx, since it all starts with me. So the focus of this mailing list will be shifting. If this content does not interest you, please feel free to unsubscribe (unless you are my family, in which case you are required to read every email I write).

  1. I am no longer naming every email after a Book of Mormon verse.

This is legitimately a hard decision for me. Let me be clear: I still plan on sharing spiritual thoughts (and scripture quotes) in my emails. I just won't name every single email after a verse. This is a tradition I started as a missionary.I love the Book of Mormon, and naming my emails after Book of Mormon verses gave me joy and motivation to share. But I realize that the title of an email just isn't the right place for it. And I'll be honest, sometimes it delayed emails because I couldn't quickly think of a super related verse, or made my email titles "stretches," or even made me change the content of an email by a lot just to make it fit the title better. So I have decided to focus on making the content more honest and powerful, and allowing the title to be a boring, short description of the email, as it should be.

  1. I am renewing my commitment to write weekly.

Yes, really! I haven't decided on a day yet—maybe Mondays. But this is something that will be good for me and everyone that likes to read my writing.

  1. I am switching my email delivery service from Substack to Buttondown.

Hopefully this won't be a big deal from your end. But Substack has been bothering me because of its insistence on the marketing side of newsletters, which I am not interested in. Buttondown is a much better option, and it is more mission-aligned with Diaryx as well. Maybe I will write a technical post about this another day.

Diaryx is going to play a much bigger role in my life, and hopefully your life going forward. It is, simply put, the mission to allow personal digital archives to last forever.

I want to give you a brief introduction to the ecosystem I have built this summer. This email may be a little long.

Fig

Fig is a project I made to address the structured metadata part of preservation.

Say you want to represent a person. They have a name, a favorite color, things they like, a place they live, and so forth. You could represent the person like this:

{
    "person": {
        "name": "John Doe",
        "favoriteColor": "blue",
        "thingsLiked": ["Raindrops on roses", "whiskers on kittens"],
        "hasABigNose": false,
        "age": 35
    }
}

This is the JSON format. It is very commonly used in the programming world. You will probably never find a software developer who hasn't used JSON.

Fig, internally, represents this like:

  • First, a mapping with one key-value: "person"
  • The value of "person" is another mapping.
  • This mapping has 5 keyvalues: name, favoriteColor, thingsLiked, hasABigNose, and age.
  • name and favoriteColor have values that are strings of text.
  • "hasABigNose" is a false value. "age" is a number.
  • "thingsLiked" is a sequence of values. There are two strings in the sequence.

There are lots of different formats for this kind of information. I wrote my own format, called "Fig."

person
> name = John Doe
> favoriteColor = blue
> thingsLiked = [Raindrops on roses, Whiskers on kittens]
> hasABigNose = false
> age = 35

You could also use YAML format:

person:
    name: John Doe
    favoriteColor: blue
    thingsLiked:
        - Raindrops on roses
        - Whiskers on kittens
    hasABigNose: false
    age: 35

Lots of people like writing in YAML format, but I think Fig format is better because I don't have to count spaces. What do you think?

Anyway, Fig, the library, can convert between any of these formats, and crucially, it can edit these files precisely, modifying the absolute minimum number of bytes necessary. So, if you keep your information in a specific order, or have special comments or spacing at certain spots in the file, Fig won't affect it. This is a surprisingly uncommon quality in a file parsing library, and a super important one in the realm of archiving/preservation. So I had to write Fig before I could have a proper Diaryx.

Twig

Twig is Fig's sister project. Remember when I said that Fig could represent "pretty much any kind of information you could possibly think of"? That's a big claim. Could I, for example, convert an email into Fig format?

email_content[0] = {type = paragraph, txt = This is my first paragraph!}
email_content[1] = {type = paragraph, txt = This is my second paragraph!}
email_content[2] = {type = paragraph, txt = Look at this cool picture!}
email_content[3] = {type = image, src = https://example.com/image.png}
email_content[4] = {type = paragraph, txt = Did you like my image?}

Yes, you can. But it isn't pretty.

Once we have information that is shaped more like a document than a list of values, Fig's tiny abstract syntax tree model starts feeling claustrophobic. We start repeating things, because we want some kind of consistent leg to stand on. We do things like type = paragraph because we wish Fig's AST had something more than strings and numbers.

Basically, Twig is lot more complex than Fig, but fundamentally works the same way. It has ~40 types instead of just 7.

But it is worth it, because I can represent my document like this:

This is my first paragraph!

This is my second paragraph!

Look at this cool picture!

![](https://example.com/image.png)

Did you like my image?

Notice how it looks… normal. I don't have to say that it is a paragraph. It just is a paragraph, because it is text on a line. That is the beauty of plain text.

Plain text is important to Diaryx because it is the de facto way to share writing between computers without needing any specific dedicated program. Plain text doesn't rely on any specific program—it relies on ASCII and UTF-8, standards that are supported by nearly every computer on the planet. Because of plaintext, you could read your Diaryx file on a computer from 1960, and it would look pretty much identical. That is because every character you see on screen equals one byte of information. It is dead simple for a computer to render.

That's one truth I'm betting on for Diaryx. Plain text lasts forever. At least, it is more likely to last forever than anything else on a computer.

Leaf + Flower

You can probably detect a naming theme by now.

Fig and Twig are great, but they don't reach the end user. A person who knows nothing about programming will never ever see them. But a person could see Leaf and Flower.

Leaf is a rich text editor. In fact, I am writing these very words in the Leaf editor in the Diaryx app. I can click on it and type into it. As I type, I can style my text and Twig will automatically convert it to plain text. So I get the benefits of plain text without having to know anything about it.

There is something magical about this process: I am typing these words, and on the computer they are represented in a way that isn't very far removed from how they appear on the screen. If I moved them to an old Windows XP desktop from 2001, and opened them, they would appear pretty much identical to how they look now. It's like a visual window into a block of computer memory.

Flower is a little different, because it is configuration rather than a document. Visually, it looks more like a settings menu than prose. And that is a good thing: to have prose in one place and a settings menu in another. A settings menu is strict, structured information that is easy for a computer to interpret, while prose is natural for humans. They deserve to be side-by-side.

PROV

This might be the most important one. It stands for Plaintext Records, Organized and Verifiable. It does a lot of things:

  • Keeps track of all files in the folder
  • Stores crypographic hashes for each file
  • Construct derivable views of the files
  • Validate links between the files

That's just a short list.

Prov "depends on" Twig and Fig. The whole idea is that structured data belongs right alongside a document, so they coexist in the same file. And that structured data names other files, so all the files link together in a kind of big workspace graph.

This linking is really important when you are working on any sufficiently complex project. A text message isn't much. But if you are writing a novel, you probably want Chapter One in one file and Chapter Two in another. Then, they can link to a "parent" file, called the "index file." This parent file can be named, "My Novel." It looks something like this:

---
title: My Novel
author: Me
contents:
    - "[Chapter 1](chapter-1.md)"
    - "[Chapter 2](chapter-2.md)"
---

This is my novel! It has two chapters:

# Chapter 1

In this chapter, the dragon kidnaps the princess.

# Chapter 2

In this chapter, the knight saves the princess from the dragon!

Notice how the file declares a structured data section at the beginning. Notice it has a contents value that lists each of the chapters. This is the primary insight of PROV—that information can be organized in a way that is easy to understand intuitively. On your computer, you see three files:

  • my-novel.md
  • chapter-1.md
  • chapter-2.md

How simple is that?

Though, I have to admit that PROV is not as verifiably accurate and useful as Fig or Twig. There isn't really a precedent for a project like PROV. I'm treading new ground! Though, recently the Markdown format, popular for plaintext documents, has become really popular because of AI. So the popularity of apps like Obsidian has exploded!

The thing I wanted to be different with PROV is the linking between files. This nearly eliminates the dependency on even the filesystem. That means, even if you couldn't see a list of what was in the folder, and all you could see is one file at a time, you could still find your way around!

Diaryx

Diaryx brings all of these together. Imagine all the power rangers coming together to form a super robot! Or something like that.

My main goal with with Diaryx is making the app as easy-to-use as possible. Even if you have no technical knowledge at all, I want Diaryx to be super easy to use! Seriously, I want my grandma to be able to use it with no problems! That means you don't need to understand anything I just told you in order to use Diaryx.

But what hopefully lots of people will appreciate is the longevity of the files they keep in Diaryx. Because of how it is designed,

  • your files won't be randomly deleted.
  • They won't be trapped on someone else's server.
  • They won't glitch out.
  • If the app glitches out, it doesn't touch your files.
  • If you accidentally delete a file, you can still recover it.
  • If your phone explodes, your files will still be safe (assuming you don't turn off backups).
  • You can share with your friends and family, too.
  • You don't have to share everything if you don't want to.

These things feel very important to me. They feel like basic human rights—which is part of why I've been so passionate about this.

I’ve updated the Diaryx website to be a better landing page. I am probably going to change it again in the near future. But it is pretty cool as it is now, so go take a look anyway.

Also, Diaryx will be available on the App Store very soon! It is actually already available on the Mac App Store. But the iOS app is currently waiting for review—it has been waiting since Tuesday.

If you want to support me in this mission, honestly the best thing you can do right now is offer ideas or feedback. I'm setting up a sponsor page but it is low priority until I can actually release something people can use.

Thanks for everything,

Adam Harris