Archive

My new structure for my newsletter at the start of this year was an attempt to improve my writing. My theory was that by writing about the same thing, and by working on a piece alongside the newsletter for four weeks, I could turn the newsletter into a form of delibarate practice. I’d be able to get better at researching, outlining, editing, all these skills that would make me a better writer.

It didn’t quite work out. I was feeling rushed and stagnant before I started this new structure, and that only got worse with more writing to deliver. So, I took a little break a couple weeks ago, and stopped with the structure.

I realized that I wasn’t really having difficulty with the skills I thought would make me better. My problem was more fundamental. I was having difficulty with the basic activity of writing.

I want to talk about some things that have been on my mind as I’ve been implementing collaborative editing in Hyperspace this past week.

It’s been a lovely combination of strategy, technical wrangling and character development.

First, a broad overview of what I wanted to accomplish.

Hyperspace is a social space for learning. People can create and interact with expressive documents that are live and collaborative, and which can be richly networked to create both social and informational structures.

Hi everyone! I’m going to be taking 3 weeks off from this newsletter and returning on the 28th.

I stretched myself a little too far with these last couple newsletter topics, and while it’s lead to me learning a lot, writing each newsletter has gotten progressively harder. I also find myself slipping with the meta structure, which is a good sign I need to re-evaluate what’s going on.

I’ve valued the regularity of the habit a lot since I started it last year, but I think a short break is going to do me more good than toughing it out in this case.

While I’m off there are a couple things I want to think about:

What constraints if any would it be useful for society to put on the production and use of digital technologies?

Yep, this next newsletter batch is going to be about regulation. Get hyped.

In these last newsletters I’ve been talking about prayer as a conversation with God. I’ve kind of skirted around the question of what you’re actually talking to.

In “Talking to God” I wrote:

To roughly summarize last week’s newsletter, prayer is talking to God.

Thus far, I’ve mainly been talking about spontaneous, conversational prayer. The kind where you close your eyes and just “talk”.

It’s a kind of prayer that’s been easier for me to think about, as it’s formed solely between two entities. It’s simple. But, it captures only a segment of the prayers I’ve said throughout my life. Many more are prayers.

Over the last couple of years I’ve been learning more about meditation and feel like I have a decently stable understanding of “how it works”. Roughly, it’s something like “train your powers of observation, then observe the experience of being, in order to discover your unity with everything else”.

There are a couple tricky bits in there, namely “unity” and “everything” else, but it should hold for a working definition.

Prayer is weird to me, because it has the same goal, but works by an entirely different mechanism. Roughly the core idea seems to be, talk to God.

That seems:

If you’re new to this newsletter, or just reading this one after a while, hi! I usually write about technology and learning here, and in Season 2 I’m exploring different topics through 4 week/newsletter long expeditions. We’re just starting a new one!

First a couple disclaimers. The topic for this time, prayer, is a little bit outside my normal range. It’s also a intertwined with religion which can be a pretty shifty ground for a lot of people. I understand if you want to check out until we return to less fraught ground! (if you unsubscribe using that link, I’ll add you back when we do)

The vast majority of applications today share a simple architecture. You have your “app” which encodes a whole bunch of “business logic”. Your users interact with your app, and then your app talks to your database to store data.

However, the database isn’t just a dumb dump. It has all sorts of “constraints” for your data and it will happily throw your app’s requests out if it doesn’t respect them.

These constraints also encode your “business logic”. Things like “every cohort must have a facilitator who must be a user in the system”, or “every user must have a username and email”. Where’s the line between these constraints and the more procedural logic stored in your “app”?

Okay assume this whole personal database thing works out, and I end up with a lil db stuffed full of information. Well, now I need to query it.

I can use that data to answer all sorts of questions, like: - what’s the recipe for Sorpotel. - which of my friends recommended me this book I loved? - what’s on my todo list today and when did I actually say I’d do those tasks?

But, because computers, I can’t just ask the database these question directly. I have to write them in a language it can understand. A .

My project for the next couple of weeks is implementing a personal database. I want it to store information about the things I read, the thoughts I’m thinking, the websites I visit, the people that matter to me, and anything else I can cram into it.

One of the biggest decisions in implementing this database is figuring out the data model: How do we organize the data and it’s relationships?

I decided pretty early to go for a facts based data model. In it, all the information in a system is represented by a set of “facts”.

Alright well I held off for the first one so y’all would think I’ve turned a new leaf, but, as world the keeps turn, I’m back on my bullshit.

My next 4 newsletters are going to be focused on the design and implementation of a personal database.

What’s a personal database for?

“A Finite game is played for the purpose of winning, an infinite game for the purpose of continuing the play” James Carse, Finite and Infinite Games

It seems to me that learning, though it often threads its way through many a finite game, is infinite. We learn so the way may able to learn more things, and expand our experiences outwards, continuing on. We have goals, but those goals rarely conclusively end, but evolve and branch out as they’re fulfilled.

Recently, the video game industry has been realizing the money making potential of infinite games. Or, more charitably, they’ve realized that players were gravitating to the infinite ones. Whatever it is, we’ve seen the rise of “Games-as-a-Service”.

First a meta note. When I was designing the game that is this newsletter I really messed up with the difficulty curve. Week three comes at you fast. Last week I wrote up a little outline, and this week I have to turn it into a complete draft! I’m writing that alongside this newsletter, so we’ll see how it goes…

Two of my favorite games of the last couple years, Celeste and Hades, have had very well considered difficulty systems.

Changing the difficulty is nothing new in games, most have some flavor of “Easy/Medium/Hard”. But these two games take a more nuanced approach, that informs the player, and gives them control to shape their experience. And, remarkably, they do so without detracting from the core experiences the game designers want to create.

Hello again! If you’ve been with us a bit, nice to see you again, and if you’ve just tuned in welcome! It’s Season Two ¹, of this weekly newsletter, chronicling my learnings around data, computers, people, life, and of course, learning.

This time around, the plan is to do things a little differently. For a bit of context check out the the last season of this newsletter, and some of .

Hello! This is the last newsletter I’ll be writing this year. It’s a little recap of what I’ve been writing about, and how it’s been. I’ve been thinking a lot on how to improve this publication and my writing practice, and will be returning early next year. Keep an eye out for that! And if you have any ideas, let me know!

Okay first a couple numbers: 50 newsletters in, 44,888 words written, 95 subscribers. All of it growing pretty linearly, no hockey sticks here. Thanks for sticking through. I read through pretty much all those words for the first time again today and here are some things I thought about them:

Some of the favorite things I wrote:

Update on the end of year plans for this newsletter: Next week will be last for the year and I’ll start back up some time in January, perhaps the first week of.

Today I’ll reflect on the practice of writing this thing for the last 50 weeks, and I’ll close out next week by looking back at all the things I actually wrote about.

I really bounced around all over the place with this experiment, so it’ll be a fun time trying to extract some sense from it. I tried essay style writing, technical explanations, accountability posting, writing updates. This made for a maybe not so great subscriber experience (sorry!), but I think it was a great way to feel out how I want this to work.

My little prototype of a information management tool is coming together. My apologies if that description means absolutely nothing to you, “a note-taking tool” wasn’t quite cutting it as a description for me.

Following my gut from last week, I threw out the web application I’d been building and instead made an EC REPL CLI (ha!).

Let’s break down those acronyms, eh?

First! = Entity-Component; the architecture of the application. Entities are unique documents, and components are values that are associated with those documents things like or .

A Remarkable Review

I love e-ink. It manages to be both an infinitely malleable abstract display, and an object, something that exists in continuitiy with the rest of the world. The ReMarkable 2, expresses these qualities truer than any other device I’ve seen.

My goal for this next week is to make this prototype usable. It’s almost there honestly, but there a couple elements missing that will make me feel properly comfortable using it on a daily basis.

The first is replacing message passing with function calling, as I mentioned last week. The second is adding a new way to store state information.

Before I get to that though, let’s talk about the way I want to use this thing.

Following one with the theme of last week, my work on this little note-taking tool prototype hasn’t been the most practical, but it has been fun.

Moving around documents

I started by implementing basic vim movements in the editor. While this isn’t useful in the long term ( I plan to re-implement the edtior using at some point) its a pretty huge quality of life boost as it get’s this prototype working the way the rest of my computer does.

I’m having a hard time writing this newsletter because I’ve just been having so much fun hacking on this little prototype. Since one of my goals for this prototype is to make it fun to use, I want to dig a little deeper into what made this hacking enjoyable.

Knowing my tools

Okay, so I did make that prototype I promised I would last week, but it’s still a little raw, so I don’t think I’ll be exposing it to the (few) eyes here yet.

But since, it turns out using this newsletter for motivation is a great idea, I’m going to set another goal: Implement links, and make it pretty enough to show people.

Over the last week I’ve been puzzling over the ideas around MUDs I was talking about in https://awarm.space/newsletter/40-roguelikes a couple weeks ago.

As a quick recaps MUDs are/were multiplayer text-based games that you can connect to over a terminal. If you’ve ever played a text adventure, writing things like “go left” or “pick up the key”, it’s like that, but with other people!

One of the most evocative features of some MUDs is the ability for players to create the world while in it. They can write descriptions for objects, create new scenes or rooms, and even write scripts for how different things behave.

I started working at ConsenSys four years ago this week. Fathom actually started a little bit earlier than that but that’s when it became something real and not just a collection of ideas in people’s heads.

After I left ConsenSys I experimented with a bunch of different things, one of which, hyperlink.academy, turned into the work I’m doing today. One of the most useful things I did during that transition was write up a retrospective of the first prototype of the website, while we were getting ready to embark on the next version.

This weekend was the Rougelike Celebration. It’s a conference around roguelikes, a video game genre with a long winded history/defintion that happens to be one of my favorites.

We’re two and a half weeks into Internet Homesteading. It’s one of the first courses we’re running hyperlink.academy, but it’s special to me for a couple other reasons. One, it’s the one I’m actually facilitating 😅 but it also happens to fall close to the original vision for the site.

Following my gut from last week, I experimented a little this week with Cloudflare workers, making a tiny app

Last week I talked about how I’ve shifted from expressing my values through the technology I use to expressing it in communion with the people I work with.

Ultimately what directs the values… is less the underlying technology (though that definitely has a significant impact!) but the people who beleive in it, and who see something of it in the future, and build it.

This is going to be a bit of a short one as we (the hyperlink team) just got back from our first retreat, and I am pooped.

One of the things you talk about during a retreat is . What are the things you think are important, in how you work, what you do.

This week I wrote myself a self-verifying todo list. Inspired by the loops of last week, I wanted to create a system that would keep me in the loop of getting what I want to do in a day|week|month, done.

What I ended up with is a program that checks whether I’ve done different tasks, and outputs a checklist in red and green. With a click of a button I can run it again.

This edition of A Warm Newsletter revolves around loops. Specifically, three different loops: a video game loop, a learning loop, and a software development loop.

Hades and rouge-lites

I returned this week to a previous take on fancynote: a command-line application. ¹

So we launched hyperlink.academy on Tuesday! It’s a whole mix of feelings to realize that this is the first anything in the fathom lineage that’s actually launched.

If you’re reading this newsletter, chances are you’ll at least be interested in the course I talked about developing last week, . It’s a course on making a home for yourself on the internet, with a website.

Hello! I regret to say that I have not quite gotten what I wanted to done for fancynote. Instead the end of this week has been a bit of a rush to get things ready for hyperlink.academy’s launch in the coming days.

It’s been a bit whack-a-mole with finding and fixing bugs, but overall the site’s looking good! Actually, much harder than the bugs and programming is the other thing I have to do for launch, creating a course on “Internet Homesteading”.

This week I actually used Fancynote, in both ways it’s meant to be used, for writing and programming. Both experiences were just successful enough to keep me satisfied and just frustrating enough to get me fired up to make it better. I’m starting to barely see the outlines of a useful tool here. But, it’s not enough to make the experiences for both uses better. I want to converge them.

Right now I use fancynote the to program fancynote , which I use to write notes. I want to do both of those in the same place, using the same set of primitives.

My goal for this week was to get fancynote “good enough” to write my daily journal with it.

I’ve had the journal on and off since 2018, but really clicked in place this year. The value of it exists manifests in three different ways for me:

1. It’s a data source I can use to answer questions in the future. How was I feeling this past week? What did I accomplish? When did I read that book?

If you’re new to this newsletter, it’s currently chronicling my attempt at building my own thinking infrastructure, which happens to be a perfect way to yak-shave my way out of actually having to think. But, I have to think about interfaces for thinking, which is almost as hard, and so to yak-shave my way out of that, I conjured up fun technical challenges that “had” to be done first.

First, I implemented an append-only log of creating and updating notes. On top of the log you can instantiate which process it and expose different ways of viewing your collected thoughts. This forms a stable foundation for future experiments.

This week I finished implementing the append-only-log architecture I laid out two weeks ago. That turnaround isn’t bad, especially considering I only work on Fancynote on the weekends, but I’d hoped to be done last week. As you may have read, that didn’t pan out, due to struggles with API’s, my own and the browser’s.

The latter was nothing diving into MDN couldn’t fix, but figuring out how to design my own interfaces took some more thinking.

After the high of last week’s design breakthrough¹ I now am trapped in the lightning sand of API usage and design.

Today I’d like to talk to you about append-only logs, the simple data-structure behind some of the coolest peer-to-peer systems out there today. Then I’d like to convince you why they’re useful for something as simple as a notetaking system (you can probably see where this is going).

First, some housekeeping. This is A Warm Newsletter, a weekly log of the things I (jared) have been working on and thinking about. For the last couple of weeks I’ve been detailing my work on fancynote, my experiment with making my own notetaking software from scratch.

But instead of actually working on the fancynote task I set myself last week, I decided to spend my weekend thinking about .

Last weekend I noticed a slew of fascinating papers pop up all over the place. I’d started searching for information on a couple different programming languages as I needed some inspiration for Fancynote, my own little language experiment. Each time I’d set off on my search I’d come across a paper written for something called HOPL4, on the history of the language I was looking into.

This may be due to my self-taught computer science education but I barely ever hear about the histories of the tools I’m using. By and large the things I’m reading about the field are firmly rooted in the .

Last week I set myself two very vague goals:

1. Add a compiler to fancynote, i.e execute some kind of code in a notes file
2. Write an essay based on prompts I've collected over the last couple weeks

Okay a first take at this new “worklog” style newsletter.

What’s happening with Hyperlink.academy

This week we “pushed to master” with the new hyperlink.academy site. You can take a sneak peak if you like but stuff there is still extremely under-construction so please be generous.

So to recap, last week I decided to go back to the project that started off this newsletter, Fancynote. Being incredibly dim, I decided to do this right as things are kicking in gear with hyperlink.academy. That’s why I’m just starting to write this newsletter, at 12:48AM. Alas.

Anyways, I set my self the goal of getting my experimental notes software outputting to and well, there it is!

What ever happened to Fancynote?

The very first issue of this newsletter was about Fancynote, “a silly editor”. It was to be my tool for thought. A general purpose space for writing and thinking in, that I could program to do whatever I want. Recently I’ve been thinking about it again. To those who are starting to worry reading that, I promise I’ll still be getting my actual work done.

Anyways, I think my mistake with the first attempt at fancynote was trying to go all the way to building an editor. Turns out, making a nice text-editing experience (especially when you’re used to one) is . I should’ve started smaller. And where better to start small than with plaintext?

Warning: this is a bit of a technical one. Nerdery about web frameworks lies ahead.

A couple days ago Tom MacWright published this article: .

As I build the hyperlink.academy website, and we start to get specific about what it’s going to look like, I’ve been drawing inspiration from other learning spaces that are fusions of technology and community. The two, drastically different, ones I’m writing about today are Monome and Emacs.

I know I’ve gone on about emacs but have I mentioned Monome in this newsletter before? They’re a small company that makes some of the most beautiful musical instruments out there. Each piece of hardware they make is physically beautiful and lovely to touch and use. But they only truly comes alive as the gateway to beautiful they’ve created

Hi all. This is an edition of A Warm Newsletter, written by me, Jared, about the things that I’m thinking about. This week I’m writing about task management. Kinda overdone I know, but I’m going to be coming at it from a tool making perspective, asking, what’s the API of a task? What’s it’s type? This is a stake in the ground to mark my current thoughts and give me a kick in the ass to work on this area more.

A I started editing a public domain ebook as a fun little craft project. I ended up finishing later that week and what that was like this week. If you’re interested in reading Democracy and Education by John Dewey, you can download an or and .