I've reorganized my homepage a bit.

1. Much less scrolling is needed now.
2. Larger lists have been broken into smaller lists which are easier to orient.
3. Mixing writing into each section makes way more sense. (I learn more and more: don't sort by type).
4. It's deliberately a bit rough so that I can fix things later.

I had more grandiose ideas, but this will do for the moment. Feels good to improve so much without a big 'redesign'.

The last update in 2021 was quite dramatic for me, going from pure icons to text; slowly considering more the reader over 'aesthetic'.

This is part of some things I'm doing for the 20th anniversary of my domain. More to come this year.

I've reorganized my homepage a bit.

1. Much less scrolling is needed now.
2. Larger lists have been broken into smaller lists which are easier to orient.
3. Mixing writing into each section makes way more sense. (I learn more and more: don't sort by type).
4. It's deliberately a bit rough so that I can fix things later.

I had more grandiose ideas, but this will do for the moment. Feels good to improve so much without a big 'redesign'.

The last update in 2021 was quite dramatic for me, going from pure icons to text; slowly considering more the reader over 'aesthetic'.

This is part of some things I'm doing for the 20th anniversary of my domain. More to come this year.

feedbox is an embed for previewing RSS feeds. Here's what it looks like:

Here it's configured to fetch the one from this blog, but you can use any RSS feed and drop in on your website with a few lines of code. I've added it to all my project home pages, including Zero Data App and my homepage.

It uses an instance of cors-anywhere to get around CORS complaints; I hope someday it will be simpler to just fetch the raw contents of a page.

Unlike most of my programming projects, I tried to write code that feels more 'messy' to me (simple human names instead of XYZVerboseNames, which is generally hell for other people). I also actually wrote a README (uncommon for most of the over 100 OldSkool modules) to describe the setup and possible options; hope to maintain this as a baseline for future modules.

Was kind of fun to let go, and not test everything, although I still wrote some tests…

As a more general complement, I automatically added link[rel="alternate] to sites that don't have one by setting an environment variable.

The sensation of stuff updating everywhere, even on static pages, without anybody doing anything, is kind of electric to me: isn't that what computers are for? bleep bloop!

feedbox is an embed for previewing RSS feeds. Here's what it looks like:

Here it's configured to fetch the one from this blog, but you can use any RSS feed and drop in on your website with a few lines of code. I've added it to all my project home pages, including Zero Data App and my homepage.

It uses an instance of cors-anywhere to get around CORS complaints; I hope someday it will be simpler to just fetch the raw contents of a page.

Unlike most of my programming projects, I tried to write code that feels more 'messy' to me (simple human names instead of XYZVerboseNames, which is generally hell for other people). I also actually wrote a README (uncommon for most of the over 100 OldSkool modules) to describe the setup and possible options; hope to maintain this as a baseline for future modules.

Was kind of fun to let go, and not test everything, although I still wrote some tests…

As a more general complement, I automatically added link[rel="alternate] to sites that don't have one by setting an environment variable.

The sensation of stuff updating everywhere, even on static pages, without anybody doing anything, is kind of electric to me: isn't that what computers are for? bleep bloop!

Year two of my experiment in creating sustainable income as an independent creator.

---

I'm currently so optimistic and confident about how much better it's going to look next year that I have no shame about how bad it might look this year. Also continually surprised at my unwavering commitment to something that appears to bear only a small material result. One might question when it makes sense to stop versus persist, but it's so obvious to me that the things which excite me and absorb my curiosity should be where I spend my time, that I usually make compromises that a rational person wouldn't make… I still believe my vision is possible and realistic, but it will take time based on the parameters I've chosen.

Podcast

The most significant effort I made this year was in producing Strolling, and it was quite a trip.

My original concept involved an intense two-week editing ceremony per episode, resulting in a short version, long version, intro, outro, music produced for each episode, subtitles, guest playlist, and publishing to every platform. I was rather proud of the result and intended to continue for a while, as it was creatively fulfilling, but participating in the moos.garden residency changed things as I needed to record many guests in a short period, so I switched to publishing snippets with as little editing as possible. I'm also quite happy with this change and got lots of positive feedback (people like the tiny bites and enjoy them like little pieces of candy every now and then).

I learned to avoid a strict interview structure when possible, have more back and forth, film video from the waist up, and maybe care a little more about video quality than I'd like. Membership-wise I think I made a gross miscalibration in optimizing for 'people on the Internet' as a potential and somewhat generic audience: I learned that some common patterns for transacting (which I was trying to model) may not apply here, as the majority of members are people who know me somehow and want to support what I'm doing, not really in exchange for any 'exclusive content'—it's possible that I need to eventually optimize what I offer for a different kind of value exchange, where what supporters receive is not necessarily a material thing.

Freelancing a bit

I had a brief stint with getting paid as a freelancer again, curious to see how far I could pursue that: although it's validating to get paid for what comes naturally to me, I ultimately returned to what we want and felt unwilling to trade my time for money as there is no urgency for me to do so. It was also clear that I'm less fitting in organizations needing a specialist, and more cohesive when I can approach things holistically and fill various gaps based on that perspective (which comes from years of trying to 'make the whole widget'); this can result in me offering things that were never asked for, and that nobody else knew was needed. Also interesting to note that I might be hired based on the relationship, that people like having me around, or that I enjoy the company of people I work with. I plan to continued some freelancing as long as it doesn't get in the way of my projects, but I could also not, and I'm even willing to get into debt for some time if it gives me a clearer focus on what I'm passionate about.

Changes

A big shift last year was leaving the iOS App Store after going fully web, which freed up lots of mental and computer space to focus on other projects—I feel lighter, less stressed, and more excited to do my projects now that I've simplified my life in this way. Another shift was detaching from online life, which resulted in closing the Café, merging Ephemerata into my mailing list, and not doing online events; I think these projects were trying to accomplish a larger goal (of bringing people together), which I plan to continue working on via my podcast and other ways. That in mind, here is what the delta looks like:

2020	2021	2022
twitter	113	339	432
mastodon	87	207	283
github	7	46	63
visitors	?	>19.9K	33.8K
mailing list	110	166	316
ephemerata	116	🏁
ios apps	$4K	$3K	🏁
fund button	$87÷1	$134÷5	$147÷7
open collective	$750÷13	$600÷8
strolling	$691÷11
café members	17	🏁
screencasts	15	15
public garden pages	~40	155	168
events organized	15	🏁

I called this 'bad' in the beginning because even though the numbers are basically higher, it doesn't represent a noticeable growth in sustainable income—still feels like the amount coming in per year would be better per month. Nonetheless, I'm looking forward to continuing, and again, I'm super optimistic about my plans for the following year.

Do follower and visitor counts matter? I was asking myself as I fetched the numbers this year. I'm significantly more detached about them than before, as I feel focused on my process and can stay underwater there for a while, but part of me wants to publish them to give a sense of how traffic and vanity correlates to financial sustainability. Unsure if the message is clear, but I'm reflecting on this.

Conclusion

This was a year of dense learning despite being far less active in the majority of my projects. Next year, I hope to spend time maintaining and improving prior work, as well as launching new ideas; I'm specifically excited about a recent surge of thoughts around how to bring everything I do under a single hub.

Thanks to Ahsen, Andy, Boris, Brian, Charles, David, Deta, Feathers, Filippo, Heddi, Hibai, Holger, Mark Segger, Michael, Mustafa, my dad, Myke, Noel, Omar, Orazio, Paul, Stephen, and Vision for your financial contributions to my work in 2022.

I'm trying to integrate more of my musical side online as time goes on, and so will leave you with my top three musical moments from this year:

1—with myself, creating the Strolling theme music…

2—with Kaixi Yang, jamming after our podcast recording…

3—with my capoeira group, singing some of my favourite songs on earth (written by Paulo César Pinheiro)…

---

All fiscal posts: 2021, 2022

Year two of my experiment in creating sustainable income as an independent creator.

---

I'm currently so optimistic and confident about how much better it's going to look next year that I have no shame about how bad it might look this year. Also continually surprised at my unwavering commitment to something that appears to bear only a small material result. One might question when it makes sense to stop versus persist, but it's so obvious to me that the things which excite me and absorb my curiosity should be where I spend my time, that I usually make compromises that a rational person wouldn't make… I still believe my vision is possible and realistic, but it will take time based on the parameters I've chosen.

Podcast

The most significant effort I made this year was in producing Strolling, and it was quite a trip.

My original concept involved an intense two-week editing ceremony per episode, resulting in a short version, long version, intro, outro, music produced for each episode, subtitles, guest playlist, and publishing to every platform. I was rather proud of the result and intended to continue for a while, as it was creatively fulfilling, but participating in the moos.garden residency changed things as I needed to record many guests in a short period, so I switched to publishing snippets with as little editing as possible. I'm also quite happy with this change and got lots of positive feedback (people like the tiny bites and enjoy them like little pieces of candy every now and then).

I learned to avoid a strict interview structure when possible, have more back and forth, film video from the waist up, and maybe care a little more about video quality than I'd like. Membership-wise I think I made a gross miscalibration in optimizing for 'people on the Internet' as a potential and somewhat generic audience: I learned that some common patterns for transacting (which I was trying to model) may not apply here, as the majority of members are people who know me somehow and want to support what I'm doing, not really in exchange for any 'exclusive content'—it's possible that I need to eventually optimize what I offer for a different kind of value exchange, where what supporters receive is not necessarily a material thing.

Freelancing a bit

I had a brief stint with getting paid as a freelancer again, curious to see how far I could pursue that: although it's validating to get paid for what comes naturally to me, I ultimately returned to what we want and felt unwilling to trade my time for money as there is no urgency for me to do so. It was also clear that I'm less fitting in organizations needing a specialist, and more cohesive when I can approach things holistically and fill various gaps based on that perspective (which comes from years of trying to 'make the whole widget'); this can result in me offering things that were never asked for, and that nobody else knew was needed. Also interesting to note that I might be hired based on the relationship, that people like having me around, or that I enjoy the company of people I work with. I plan to continued some freelancing as long as it doesn't get in the way of my projects, but I could also not, and I'm even willing to get into debt for some time if it gives me a clearer focus on what I'm passionate about.

Changes

A big shift last year was leaving the iOS App Store after going fully web, which freed up lots of mental and computer space to focus on other projects—I feel lighter, less stressed, and more excited to do my projects now that I've simplified my life in this way. Another shift was detaching from online life, which resulted in closing the Café, merging Ephemerata into my mailing list, and not doing online events; I think these projects were trying to accomplish a larger goal (of bringing people together), which I plan to continue working on via my podcast and other ways. That in mind, here is what the delta looks like:

2020	2021	2022
twitter	113	339	432
mastodon	87	207	283
github	7	46	63
visitors	?	>19.9K	33.8K
mailing list	110	166	316
ephemerata	116	🏁
ios apps	$4K	$3K	🏁
fund button	$87÷1	$134÷5	$147÷7
open collective	$750÷13	$600÷8
strolling	$691÷11
café members	17	🏁
screencasts	15	15
public garden pages	~40	155	168
events organized	15	🏁

I called this 'bad' in the beginning because even though the numbers are basically higher, it doesn't represent a noticeable growth in sustainable income—still feels like the amount coming in per year would be better per month. Nonetheless, I'm looking forward to continuing, and again, I'm super optimistic about my plans for the following year.

Do follower and visitor counts matter? I was asking myself as I fetched the numbers this year. I'm significantly more detached about them than before, as I feel focused on my process and can stay underwater there for a while, but part of me wants to publish them to give a sense of how traffic and vanity correlates to financial sustainability. Unsure if the message is clear, but I'm reflecting on this.

Conclusion

This was a year of dense learning despite being far less active in the majority of my projects. Next year, I hope to spend time maintaining and improving prior work, as well as launching new ideas; I'm specifically excited about a recent surge of thoughts around how to bring everything I do under a single hub.

Thanks to Ahsen, Andy, Boris, Brian, Charles, David, Deta, Feathers, Filippo, Heddi, Hibai, Holger, Mark Segger, Michael, Mustafa, my dad, Myke, Noel, Omar, Orazio, Paul, Stephen, and Vision for your financial contributions to my work in 2022.

I'm trying to integrate more of my musical side online as time goes on, and so will leave you with my top three musical moments from this year:

1—with myself, creating the Strolling theme music…

2—with Kaixi Yang, jamming after our podcast recording…

3—with my capoeira group, singing some of my favourite songs on earth (written by Paulo César Pinheiro)…

---

All fiscal posts: 2021, 2022

In the spirit of 'document and share', here are some considerations for how I assemble an online collection of projects I've made since 2012.

Why bother doing this?

It's easy to forget what happened, and hard to re-create experiences as time passes. Files can also get lost, making it impossible to have traces of what was done. My personal reason is that a CV makes little sense, as it doesn't capture well what I do. Aside from that, it's just pleasant to have a more media-rich reminder of the past that's as simple as scrolling through your personal photo library.

What to document?

Not skills or roles. Focus on the work that was done, interesting aspects of the project, or what you're proud of. Although it would be fine to showcase just one artifact, I have chosen to document projects that result in multiple creations, as it better represents the different perspectives with which I approach things. This is less like a portfolio for potential clients and more like a diary: a reminder to oneself in the future of something to remember.

When to capture?

Wait until the dust has settled—usually not right after publishing something; let time work in your favour as changes and improvements accumulate, especially with digital projects that can be modified easily. Perhaps a good moment is when it's clear the project will no longer be public, but also even when it feels stable and unlikely to change much.

For documenting processes or 'the making of', take screenshots (not with 'version control' or something that needs to be re-constructed later). It should be simple to scroll through to get a sense for what's going on, without complex interactions.

Where to store it?

Ideally on a space you can control (using Ghost or WordPress for example), or a platform with decent export functionality. I use Tumblr for nostalgic reasons and because I trust their parent company Automattic to keep it running after I turn to dust, but I suppose it would be wise to also have a self-hosted backup. It's useful to be able to organize with tags or search so that there are flexible ways in and out.

---

Hope that's helpful for anyone wanting to do something similar. If you end up also creating a project archive, feel free to share with me.

In the spirit of 'document and share', here are some considerations for how I assemble an online collection of projects I've made since 2012.

Why bother doing this?

It's easy to forget what happened, and hard to re-create experiences as time passes. Files can also get lost, making it impossible to have traces of what was done. My personal reason is that a CV makes little sense, as it doesn't capture well what I do. Aside from that, it's just pleasant to have a more media-rich reminder of the past that's as simple as scrolling through your personal photo library.

What to document?

Not skills or roles. Focus on the work that was done, interesting aspects of the project, or what you're proud of. Although it would be fine to showcase just one artifact, I have chosen to document projects that result in multiple creations, as it better represents the different perspectives with which I approach things. This is less like a portfolio for potential clients and more like a diary: a reminder to oneself in the future of something to remember.

When to capture?

Wait until the dust has settled—usually not right after publishing something; let time work in your favour as changes and improvements accumulate, especially with digital projects that can be modified easily. Perhaps a good moment is when it's clear the project will no longer be public, but also even when it feels stable and unlikely to change much.

For documenting processes or 'the making of', take screenshots (not with 'version control' or something that needs to be re-constructed later). It should be simple to scroll through to get a sense for what's going on, without complex interactions.

Where to store it?

Ideally on a space you can control (using Ghost or WordPress for example), or a platform with decent export functionality. I use Tumblr for nostalgic reasons and because I trust their parent company Automattic to keep it running after I turn to dust, but I suppose it would be wise to also have a self-hosted backup. It's useful to be able to organize with tags or search so that there are flexible ways in and out.

---

Hope that's helpful for anyone wanting to do something similar. If you end up also creating a project archive, feel free to share with me.

After mentioning in my last birthday reflection how I wanted to avoid doing an end-of-year recap, I've decided to do an end-of-year recap… Ever since reading the Pinboard anniversary posts, I felt the urge to make one—the charts and odd commentary, uh, inspire me. So this will be less personal and more fiscal—a mix of reflection, stats, link roundup, and (of course) music.

---

The biggest question of the year for me (asked by friends, strangers, internet acquaintances, parents, my therapist, the occasional bird, and myself) is: "How do I plan to make all this sustainable?" This hit me like a small pebble at least once every few weeks and my best answer was always "I'll do whatever I can to last a year or two and everything will work out after that…"—it makes sense to me (even now), but leaves many others raising one of their eyebrows. It's hard to see, I get it: I too questioned things, especially during periods of fatigue from doing too much… I wondered towards the end of the year about what energized me versus what didn't, and came to the conclusion that the work of recurring events needs to go for now.

The idea was an imitation of various individuals and organizations who create continuity through group meetups. Although the reasons for doing them align with my motivations and objectives, it would make more sense if I had fewer projects or if other people did most of the organizing. Even though it isn't that much on a day-to-day basis, the psychological load impedes me from concentrating on other things and I end up being able to handle only smaller tasks for most of the month, not advancing on my main projects. This was probably amplified because I was doing not one, but generally three events per month, but I think even with a single date, I would rather not deal with the before and after of making it happen. Also draining is the feeling that experiences don't accrete: the lack of recordings (often for good reason) leaves no collective artifact to share afterwards, which means I'm less present during the event as I frantically take notes to avoid letting everything 'slip away'—it's important for me to 'have something to show after', and I don't think written notes capture the experience well enough, so I might exclusively do recorded events from now unless it's mostly social in nature. I imagine focusing more on my upcoming podcast project, which could solve all these issues by 1) requiring less planning or promotion, 2) being recorded, and 3) compounding more easily over time.

A useful question that helped me find clarity is "How does it help you to continue producing for another year?" I would typically be satisfied with intrinsic motivations and the fulfillment of creating, but it ultimately isn't sustainable without what one might call 'material conditions for existence'. Perhaps now is a good time to look at stats and talk about money:

2020	2021
twitter	113	339
mastodon	87	207
github	7	46
visitors	?	>19.9K
mailing list	110	166
ephemerata	116
note the sound	$1.4K	🏁
ios apps	$4K	$3K
fund button	$87 (via 1)	$134 (via 5)
open collective	$750 (via 13)
café members	17
screencasts	15
public garden pages	~40	155
events organized	15

I've been re-imagining my income situation since the COVID-19 pandemic knocked out note the sound in the first quarter of 2020; it used to be 60–70% of my income and will likely not return for the foreseeable future (but hopefully, maybe someday). I also decided to stop making iOS apps and lower prices or make them free, which reduced and eliminated the other 30–40%. In 2021, I experimented with in-app payments via my fund button and direct patronage from financial backers, describing tradeoffs of each in Platform puzzle pieces for sustainable community. The amounts that came in so far are too small to sustain me in most places, but I think it's a useful start and with some changes (see [[Why the fund button is slow (TBA)]]), I think I can dramatically improve the result.

On the bright side, everything else is growing! See Measure progress for more commentary on the other figures or 100 steps to success for these eighteen experiments from 2021:

1. Create icons for feature lists
2. Use bolder design for landing pages
3. Set an example for how to use a new medium
4. Help friends to get started
5. Create tutorials to demonstrate how things work
6. House everything in the commons
7. Centralize project discussion and community
8. Start a weekly thing
9. Create original content on a regular basis
10. Offer calls to action across projects
11. Differentiate unrelated elements with contrast
12. Announce the latest thing across projects
13. Overview the universe
14. Host events
15. Measure progress
16. Broadcast the exit
17. Collaborate with others
18. Try everything

I don't have any doubts about all this becoming sustainable, especially with long-term persistence and constant learning. Doing anything worthwhile takes time, and I'm opting to use my current flexibility (year of savings/runway) to organize things in a way that gives me maximum leverage over my future—I hope that next year it will be easier to see why.

---

Below are my most popular texts from this year.

• Secular churches for continuity (which won Interintellect's first Writing Challenge)
• Dating apps, take one (sparked many conversations with friends and strangers)
• Wetware of writing and doing (video presentation with text version)

(Apparently I wrote over 12,000 words when you count the other long-form ones, which is not quite a novella but comfortably a novelette)

---

It should come as no surprise that the albums I've most listened to are from Brazil.

• Paulo César Pinheiro: Capoeira de Besouro (2010)
• João Donato: Quem É Quem (1973)
• Cristina Buarque e Samba de Fato: O Samba Informal de Mauro Duarte - Volume 1 (2008)
• Joyce: Revendo Amigos (1994)
• Pedro Martins: VOX (2019)

---

Last but not least, shout out to Brian Ginsburg, Elisa Guimarães, Lawrie, an anonymous donor, miguel francisco, Andy Matuschak, Reef Loretto, Feathers Cloud, Charles E. Lehner, Deta, Sasquatch in Orange Shoes, and Boris Mann for becoming backers in 2021. You're all pioneers ❤️💫.

Thanks to everyone using my apps, reading my words, sharing my projects, and contributing in innumerable other ways. I look forward to see what the future holds and hope you'll join me there.

---

All fiscal posts: 2021, 2022

After mentioning in my last birthday reflection how I wanted to avoid doing an end-of-year recap, I've decided to do an end-of-year recap… Ever since reading the Pinboard anniversary posts, I felt the urge to make one—the charts and odd commentary, uh, inspire me. So this will be less personal and more fiscal—a mix of reflection, stats, link roundup, and (of course) music.

---

The biggest question of the year for me (asked by friends, strangers, internet acquaintances, parents, my therapist, the occasional bird, and myself) is: "How do I plan to make all this sustainable?" This hit me like a small pebble at least once every few weeks and my best answer was always "I'll do whatever I can to last a year or two and everything will work out after that…"—it makes sense to me (even now), but leaves many others raising one of their eyebrows. It's hard to see, I get it: I too questioned things, especially during periods of fatigue from doing too much… I wondered towards the end of the year about what energized me versus what didn't, and came to the conclusion that the work of recurring events needs to go for now.

The idea was an imitation of various individuals and organizations who create continuity through group meetups. Although the reasons for doing them align with my motivations and objectives, it would make more sense if I had fewer projects or if other people did most of the organizing. Even though it isn't that much on a day-to-day basis, the psychological load impedes me from concentrating on other things and I end up being able to handle only smaller tasks for most of the month, not advancing on my main projects. This was probably amplified because I was doing not one, but generally three events per month, but I think even with a single date, I would rather not deal with the before and after of making it happen. Also draining is the feeling that experiences don't accrete: the lack of recordings (often for good reason) leaves no collective artifact to share afterwards, which means I'm less present during the event as I frantically take notes to avoid letting everything 'slip away'—it's important for me to 'have something to show after', and I don't think written notes capture the experience well enough, so I might exclusively do recorded events from now unless it's mostly social in nature. I imagine focusing more on my upcoming podcast project, which could solve all these issues by 1) requiring less planning or promotion, 2) being recorded, and 3) compounding more easily over time.

A useful question that helped me find clarity is "How does it help you to continue producing for another year?" I would typically be satisfied with intrinsic motivations and the fulfillment of creating, but it ultimately isn't sustainable without what one might call 'material conditions for existence'. Perhaps now is a good time to look at stats and talk about money:

2020	2021
twitter	113	339
mastodon	87	207
github	7	46
visitors	?	>19.9K
mailing list	110	166
ephemerata	116
note the sound	$1.4K	🏁
ios apps	$4K	$3K
fund button	$87 (via 1)	$134 (via 5)
open collective	$750 (via 13)
café members	17
screencasts	15
public garden pages	~40	155
events organized	15

I've been re-imagining my income situation since the COVID-19 pandemic knocked out note the sound in the first quarter of 2020; it used to be 60–70% of my income and will likely not return for the foreseeable future (but hopefully, maybe someday). I also decided to stop making iOS apps and lower prices or make them free, which reduced and eliminated the other 30–40%. In 2021, I experimented with in-app payments via my fund button and direct patronage from financial backers, describing tradeoffs of each in Platform puzzle pieces for sustainable community. The amounts that came in so far are too small to sustain me in most places, but I think it's a useful start and with some changes (see [[Why the fund button is slow (TBA)]]), I think I can dramatically improve the result.

On the bright side, everything else is growing! See Measure progress for more commentary on the other figures or 100 steps to success for these eighteen experiments from 2021:

1. Create icons for feature lists
2. Use bolder design for landing pages
3. Set an example for how to use a new medium
4. Help friends to get started
5. Create tutorials to demonstrate how things work
6. House everything in the commons
7. Centralize project discussion and community
8. Start a weekly thing
9. Create original content on a regular basis
10. Offer calls to action across projects
11. Differentiate unrelated elements with contrast
12. Announce the latest thing across projects
13. Overview the universe
14. Host events
15. Measure progress
16. Broadcast the exit
17. Collaborate with others
18. Try everything

I don't have any doubts about all this becoming sustainable, especially with long-term persistence and constant learning. Doing anything worthwhile takes time, and I'm opting to use my current flexibility (year of savings/runway) to organize things in a way that gives me maximum leverage over my future—I hope that next year it will be easier to see why.

---

Below are my most popular texts from this year.

• Secular churches for continuity (which won Interintellect's first Writing Challenge)
• Dating apps, take one (sparked many conversations with friends and strangers)
• Wetware of writing and doing (video presentation with text version)

(Apparently I wrote over 12,000 words when you count the other long-form ones, which is not quite a novella but comfortably a novelette)

---

It should come as no surprise that the albums I've most listened to are from Brazil.

• Paulo César Pinheiro: Capoeira de Besouro (2010)
• João Donato: Quem É Quem (1973)
• Cristina Buarque e Samba de Fato: O Samba Informal de Mauro Duarte - Volume 1 (2008)
• Joyce: Revendo Amigos (1994)
• Pedro Martins: VOX (2019)

---

Last but not least, shout out to Brian Ginsburg, Elisa Guimarães, Lawrie, an anonymous donor, miguel francisco, Andy Matuschak, Reef Loretto, Feathers Cloud, Charles E. Lehner, Deta, Sasquatch in Orange Shoes, and Boris Mann for becoming backers in 2021. You're all pioneers ❤️💫.

Thanks to everyone using my apps, reading my words, sharing my projects, and contributing in innumerable other ways. I look forward to see what the future holds and hope you'll join me there.

---

All fiscal posts: 2021, 2022

Since 2013, I was using a website design with no visible words—icons only; it was an obsession with The icon is a promise and the perspective of words being 'limited' in expressing things. Eventually I added text available only to screenreaders, and thought it was interesting to have a context where visually impaired persons (VIPs) would be able to 'see more' than sighted people. I digged the pure visual aesthetic and the design seemed like it would last forever (just keep adding icons to the list). I also avoided explaining 'me' because I thought that 'what I do should explain me', and seeked to make everything 'about the projects'. So for almost a decade, I have been 'explaining' myself to the online world with a list of icons, and a small amount of project-specific text essentially invisible to most people. After contemplating this recently, I began to notice issues.

Imagining what it's like for someone arriving there, I feel it would be overwhelming to click on anything: a giant list of icons, each one descending into a rabbit hole of who knows what, not one seeming to offer a sense of the landscape or horizon—how does one decide where to start? I suspect that the poor sense of 'what to click on next' might cause me to lose many people who arrive there and feel lost. It would be selfish to expect people to essentially gamble with their attention and click many links at random in order to understand the larger picture—if they aren't able to understand, the medium of communication has failed. Worse, I realized recently that although it was possible to hover on icons to see the name and description of each icon, this was not possible on mobile devices. I sometimes thought I was raising awareness about the needs of VIPs, but in retrospect it was kind of a jerk move which made it harder for most people on purpose… So it's time to try something different. It should be simple to get an overview of what's going on: perhaps better to present with more information.

Comparing current and previous layouts: text is now visible everywhere without any special interaction or hardware and there is a small blurb about me which links to an about page for a more textual overview. I think both frame everything in a way that's more accessible for everyone, making it simpler to understand what on earth I'm doing with my life. I feel happy with the result: I still dig the aesthetic and actually find it more friendly. Looking forward to see how this next phase of the design goes, and how much time passes until the next change.

---

As a bonus, check out the pre-2013 layout on Wayback Machine.

Since 2013, I was using a website design with no visible words—icons only; it was an obsession with The icon is a promise and the perspective of words being 'limited' in expressing things. Eventually I added text available only to screenreaders, and thought it was interesting to have a context where visually impaired persons (VIPs) would be able to 'see more' than sighted people. I digged the pure visual aesthetic and the design seemed like it would last forever (just keep adding icons to the list). I also avoided explaining 'me' because I thought that 'what I do should explain me', and seeked to make everything 'about the projects'. So for almost a decade, I have been 'explaining' myself to the online world with a list of icons, and a small amount of project-specific text essentially invisible to most people. After contemplating this recently, I began to notice issues.

Imagining what it's like for someone arriving there, I feel it would be overwhelming to click on anything: a giant list of icons, each one descending into a rabbit hole of who knows what, not one seeming to offer a sense of the landscape or horizon—how does one decide where to start? I suspect that the poor sense of 'what to click on next' might cause me to lose many people who arrive there and feel lost. It would be selfish to expect people to essentially gamble with their attention and click many links at random in order to understand the larger picture—if they aren't able to understand, the medium of communication has failed. Worse, I realized recently that although it was possible to hover on icons to see the name and description of each icon, this was not possible on mobile devices. I sometimes thought I was raising awareness about the needs of VIPs, but in retrospect it was kind of a jerk move which made it harder for most people on purpose… So it's time to try something different. It should be simple to get an overview of what's going on: perhaps better to present with more information.

Comparing current and previous layouts: text is now visible everywhere without any special interaction or hardware and there is a small blurb about me which links to an about page for a more textual overview. I think both frame everything in a way that's more accessible for everyone, making it simpler to understand what on earth I'm doing with my life. I feel happy with the result: I still dig the aesthetic and actually find it more friendly. Looking forward to see how this next phase of the design goes, and how much time passes until the next change.

---

As a bonus, check out the pre-2013 layout on Wayback Machine.

Since the first edition of Ephemerata, my intention was to share things that give a sense of my world and spur discussion, grouping them in a single digest to avoid overloading people with real-time messages. I still think there's value in sharing them (especially the music I find, as it might be hard for most people to come by)—now and then I get feedback that there's something compelling in there—but there seems to be a clear stronger reaction to my original writing (for example, about community or analytics, where people have gone out of their way on various channels to share their impressions), so I'm going to focus more on that.

I initially thought about writing something original for every edition, which would be motivating for me, but zooming out further I felt something unexpected click. I could atomize these texts so that they live on their own space (sort of like a blog) and publish them any time without being tied to the release schedule of Ephemerata. I can write about my experiences, document what I learn, share my thought process, and expand beyond the conceptual or 'reference' focus of my garden—this text is an example of what I might do. By giving myself permission to explore 'transient' things and write as it happens (perhaps even multiple times between editions), I feel a new outlet of expression opening up, and I'm excited to see what I would put there.

Using the same Ghost installation that now powers the newsletter, I've compiled an archive of texts from the newsletter with other long-form writing; as much as I've avoided the traditional blog organization for most of my life, it still feels like a better interface to explore collections of writing than a 'forum'. I'm still using Discourse for comments on individual texts and for newsletter editions.

Setting up a new Tumblr, I've organized the links I share into a chronological stream. This still forces me to take time (contra the urge to post a link in a box and have an app fetch the context) to reflect on what I want to communicate by sharing and be more deliberate. I suspect also that receiving many links on a weekly basis might be kind of overloading (despite my intentions to the contrary), so now there's more than one way to check it out. This also makes it possible to explore or even subscribe to music, articles, or podcasts via tag.

So in summary: 1) the newsletter is still a weekly package and an important rhythm for continuity; 2) the blog is for anyone who just wants original texts (and maybe via RSS Feed); 3) the Tumblr is for getting the links as I share them and also for things that don't make it into the newsletter. I would also re-state about Ephemerata that you don't have to read any of it—it disappears, and if you miss a week there's nothing to catch up on; just come in when you feel like it and know that it's consistently there and ready for you.

Since the first edition of Ephemerata, my intention was to share things that give a sense of my world and spur discussion, grouping them in a single digest to avoid overloading people with real-time messages. I still think there's value in sharing them (especially the music I find, as it might be hard for most people to come by)—now and then I get feedback that there's something compelling in there—but there seems to be a clear stronger reaction to my original writing (for example, about community or analytics, where people have gone out of their way on various channels to share their impressions), so I'm going to focus more on that.

I initially thought about writing something original for every edition, which would be motivating for me, but zooming out further I felt something unexpected click. I could atomize these texts so that they live on their own space (sort of like a blog) and publish them any time without being tied to the release schedule of Ephemerata. I can write about my experiences, document what I learn, share my thought process, and expand beyond the conceptual or 'reference' focus of my garden—this text is an example of what I might do. By giving myself permission to explore 'transient' things and write as it happens (perhaps even multiple times between editions), I feel a new outlet of expression opening up, and I'm excited to see what I would put there.

Using the same Ghost installation that now powers the newsletter, I've compiled an archive of texts from the newsletter with other long-form writing; as much as I've avoided the traditional blog organization for most of my life, it still feels like a better interface to explore collections of writing than a 'forum'. I'm still using Discourse for comments on individual texts and for newsletter editions.

Setting up a new Tumblr, I've organized the links I share into a chronological stream. This still forces me to take time (contra the urge to post a link in a box and have an app fetch the context) to reflect on what I want to communicate by sharing and be more deliberate. I suspect also that receiving many links on a weekly basis might be kind of overloading (despite my intentions to the contrary), so now there's more than one way to check it out. This also makes it possible to explore or even subscribe to music, articles, or podcasts via tag.

So in summary: 1) the newsletter is still a weekly package and an important rhythm for continuity; 2) the blog is for anyone who just wants original texts (and maybe via RSS Feed); 3) the Tumblr is for getting the links as I share them and also for things that don't make it into the newsletter. I would also re-state about Ephemerata that you don't have to read any of it—it disappears, and if you miss a week there's nothing to catch up on; just come in when you feel like it and know that it's consistently there and ready for you.

I have been working on iOS apps since 2009; I started with a collaboration with Wil on AudioScrub (née iLift), and eventually went solo in 2014. After twelve years on the App Store, I've decided it's time to go all-in on the web and would like to share what that means and outline the tradeoffs involved.

The spur for this change occurred years ago after the launch of my seventh app sonogrid. Although the project had iterations over several years, it mostly came together in the summer of 2018: I overworked myself for months, with incessant attention to detail, and was eager to present this to people I would meet during my upcoming trip to Colombia (they really love music there, and this app was for music lovers).

The app launched to a good reception online within various iOS music app communities, but to my dismay, most of the Colombians I met in person were not able to access it because Apple devices are prohibitively expensive there. I would offer to demo the app on my phone and let the other person play with it after: repeatedly, they would enjoy the interface and become immersed in a fun creative process, only to become disappointed on learning that it's not on Android. It was hard to resolve the contradiction between producing something I was super proud to share—a kind of magnificent zenith in my iOS trajectory—and realizing that only half the world can use it.

This was a bit deflating, and I wasn't motivated to do double the work just because of platform duopolies. Added to this was the more subtle but long-standing aversion to the 'review process' that native apps go through before appearing on the App Store: I was hesitant to invest further in an environment with little control and leverage over my own future, with a constant fear of 'reviewer rejection' and the rug slipping out from under me at any time. So I took a step back and haven't updated many of my iOS apps since then.

In place, I worked on various web components and put them together to create about a dozen web-based projects. Contrasting the experience between the web and native (i.e. iOS) worlds, I feel more enthusiastic about how the web is evolving. It can still be 'limited' in comparison to native apps, but that gap is gradually closing and most of my ideas already fit within what's currently possible.

Why you should choose Web over Native

Just to review, in case it's not obvious, there are some more commonly understood reasons for choosing the web over native:

• Basically, all current and future devices (mobile, tablet, desktop) and operating systems (iOS, Android, macOS, Windows, Linux) are supported.
• Projects are simpler and more cost-effective to build and deploy, with tools and skills that are easier to acquire.
• A thriving universe with bazillions of communities spanning the entire Internet provides lots of answers to questions, and most knowledge is based on open standards and therefore highly transferable.
• Backward compatibility is a priority, which means your project is likely to continue working despite technology evolving over time.
• You can make changes whenever you like and have them online within seconds or minutes, as opposed to requiring third-party approval for everything, which could take days or weeks.
• The environment makes it more and more empowering for single-person or small team operations to produce things, without requiring the resources of a large company.

The challenges of the web for developers like myself is to help people 'cross the chasm' that exists due to a lack of common patterns for interacting with apps:

• There is no obvious 'App Store', so people are left to search the wider web (amongst articles, videos, cat pictures, and everything else), but maybe there could be one that celebrates the 'instant' nature of this platform, or a subscription bundle like SetApp to help with discovery.
• There is no universal 'buy' button—every project does this their own way, but the Ghost Portal is becoming more and more common, and I'm trying something similar with my Fund Button.
• The idea of an 'install' button isn't ubiquitous, and some web apps may not be mobile-friendly or local-first, but for the rest there are libraries like a2hs.js that help guide people to make accessing web apps a more familiar experience: simply click on an app icon to launch.
• The lack of an integrated payment system means that every project needs to re-build trust and help others be comfortable enough in the environment to support them financially, but Stripe Checkout, PayPal Checkout, and Web Monetization are contributing various solutions that reduce friction from this process. (I would also love to see fiscal hosting become more prevalent so that having a legal entity is not necessary to receive money.)
• Performance has often held back the types of applications that can be built on the web platform, but WebAssembly will eliminate this issue for a whole class of ideas.

There are plenty of people working to create open solutions to these 'missing features'; it seems like a solvable problem with time.

What it’s like making Native Apps

(Feel free to skip this section if you'd rather not hear me complain about Apple.) I'm sharing some negative aspects of my experience making native apps with hesitation, not to be a downer but because there might be people that aren't really familiar with the developer side:

• The paternal review process can be soul-crushing at times: reviewers don't enforce rules consistently; bad app(le)s get approved and grift people out of money or personal information; it's an anxiety-ridden process that can feel unpredictable. You may have a good impression of Apple if you've bought their products: calling them for support usually means speaking to a friendly person who takes responsibility for your issue and tries to resolve it. App Review on the other hand might as well be an outsourced company, incredibly bureaucratic, and often feels like talking to a rock; any sensuality around the Apple brand quickly vanishes under these bright white office lights as you find yourself filling out TPS reports in the developer cubicle all of a sudden.
• Large companies dominate the App Store listings and generally get better treatment. The lucky independent developers are ones who have the ear of someone who works at Apple to support them if there's a dispute and either push their app through App Review or get it featured.
• It's quite a task for an individual or small team to produce an app, create screenshots and videos, localize everything in multiple languages, respond to reviews, and keep on top of technology that changes every year. The prototypical success looks more like a large organization than two guys in a garage.
• It feels like feeding into a device ecosystem of planned obsolescence and overconsumption, where developers and consumers need to keep upgrading—an insatiable appetite for more.
• The certificates and signing from the build process is complex and can bring development to a halt if you don't have the right combination of XCode and macOS (hint: keep buying new Macs).
• The expanding variety of screen sizes forces you to learn responsiveness primitives which are platform-specific and create a complex array of image and video assets at different sizes for distribution.
• The constantly changing environment will break your app and force you to either hurry and accommodate the changes or receive messages from customers asking why it doesn't work anymore.
• You can't simply share your app with a friend or even install it on your own device without paying rent or getting permission through App Review.

There are obviously lots of positives to native platforms as well, but these kinds of things weigh down smaller operations like mine, favouring large companies with resources and time to deal with this ever-growing complexity.

Developing for Web

Despite the web's challenges, there's much that excites me about its future and some of these characteristics are intrinsic to the platform:

• The concept of instant games promotes highly shareable apps via a simple link that requires no install process: show up and start.
• Having multiple payment providers, potentially with the addition of cryptocurrencies means if you wanted to also just invent your own value system, maybe some kind of post-money coupon thing, it's possible to integrate with existing systems…
• User-controlled personal data stores are already being used on the web and will eventually make their way to native apps.
• Edge apps that work completely in the browser are easy to mirror or fork, and virtually free to distribute: imagine having your site/app available everywhere via IPFS
• The culture of perpetual improvement, with less focus on versioning, is normal: people do not need to 'install updates' for each app they use on every change.
• It's just more fun and with a lower barrier to entry, which results in more diverse and dynamic communities who form part of a larger public commons: more sparks, more life, more weird.

My iOS apps have been quietly free for a while. By mid February 2022, they will disappear forever; I'm not completely sure how this works—I understand you can continue to use them, perhaps even re-download them, but only if you already have it. I would like to eventually re-make them for the web (be welcome to join me or keep me alive). In the meantime, enjoy these apps while they last. I'm jumping headfirst into a world bubbling with new possibilities and excited to develop for the largest open pool of people on the planet.

I have been working on iOS apps since 2009; I started with a collaboration with Wil on AudioScrub (née iLift), and eventually went solo in 2014. After twelve years on the App Store, I've decided it's time to go all-in on the web and would like to share what that means and outline the tradeoffs involved.

The spur for this change occurred years ago after the launch of my seventh app sonogrid. Although the project had iterations over several years, it mostly came together in the summer of 2018: I overworked myself for months, with incessant attention to detail, and was eager to present this to people I would meet during my upcoming trip to Colombia (they really love music there, and this app was for music lovers).

The app launched to a good reception online within various iOS music app communities, but to my dismay, most of the Colombians I met in person were not able to access it because Apple devices are prohibitively expensive there. I would offer to demo the app on my phone and let the other person play with it after: repeatedly, they would enjoy the interface and become immersed in a fun creative process, only to become disappointed on learning that it's not on Android. It was hard to resolve the contradiction between producing something I was super proud to share—a kind of magnificent zenith in my iOS trajectory—and realizing that only half the world can use it.

This was a bit deflating, and I wasn't motivated to do double the work just because of platform duopolies. Added to this was the more subtle but long-standing aversion to the 'review process' that native apps go through before appearing on the App Store: I was hesitant to invest further in an environment with little control and leverage over my own future, with a constant fear of 'reviewer rejection' and the rug slipping out from under me at any time. So I took a step back and haven't updated many of my iOS apps since then.

In place, I worked on various web components and put them together to create about a dozen web-based projects. Contrasting the experience between the web and native (i.e. iOS) worlds, I feel more enthusiastic about how the web is evolving. It can still be 'limited' in comparison to native apps, but that gap is gradually closing and most of my ideas already fit within what's currently possible.

Why you should choose Web over Native

Just to review, in case it's not obvious, there are some more commonly understood reasons for choosing the web over native:

• Basically, all current and future devices (mobile, tablet, desktop) and operating systems (iOS, Android, macOS, Windows, Linux) are supported.
• Projects are simpler and more cost-effective to build and deploy, with tools and skills that are easier to acquire.
• A thriving universe with bazillions of communities spanning the entire Internet provides lots of answers to questions, and most knowledge is based on open standards and therefore highly transferable.
• Backward compatibility is a priority, which means your project is likely to continue working despite technology evolving over time.
• You can make changes whenever you like and have them online within seconds or minutes, as opposed to requiring third-party approval for everything, which could take days or weeks.
• The environment makes it more and more empowering for single-person or small team operations to produce things, without requiring the resources of a large company.

The challenges of the web for developers like myself is to help people 'cross the chasm' that exists due to a lack of common patterns for interacting with apps:

• There is no obvious 'App Store', so people are left to search the wider web (amongst articles, videos, cat pictures, and everything else), but maybe there could be one that celebrates the 'instant' nature of this platform, or a subscription bundle like SetApp to help with discovery.
• There is no universal 'buy' button—every project does this their own way, but the Ghost Portal is becoming more and more common, and I'm trying something similar with my Fund Button.
• The idea of an 'install' button isn't ubiquitous, and some web apps may not be mobile-friendly or local-first, but for the rest there are libraries like a2hs.js that help guide people to make accessing web apps a more familiar experience: simply click on an app icon to launch.
• The lack of an integrated payment system means that every project needs to re-build trust and help others be comfortable enough in the environment to support them financially, but Stripe Checkout, PayPal Checkout, and Web Monetization are contributing various solutions that reduce friction from this process. (I would also love to see fiscal hosting become more prevalent so that having a legal entity is not necessary to receive money.)
• Performance has often held back the types of applications that can be built on the web platform, but WebAssembly will eliminate this issue for a whole class of ideas.

There are plenty of people working to create open solutions to these 'missing features'; it seems like a solvable problem with time.

What it’s like making Native Apps

(Feel free to skip this section if you'd rather not hear me complain about Apple.) I'm sharing some negative aspects of my experience making native apps with hesitation, not to be a downer but because there might be people that aren't really familiar with the developer side:

• The paternal review process can be soul-crushing at times: reviewers don't enforce rules consistently; bad app(le)s get approved and grift people out of money or personal information; it's an anxiety-ridden process that can feel unpredictable. You may have a good impression of Apple if you've bought their products: calling them for support usually means speaking to a friendly person who takes responsibility for your issue and tries to resolve it. App Review on the other hand might as well be an outsourced company, incredibly bureaucratic, and often feels like talking to a rock; any sensuality around the Apple brand quickly vanishes under these bright white office lights as you find yourself filling out TPS reports in the developer cubicle all of a sudden.
• Large companies dominate the App Store listings and generally get better treatment. The lucky independent developers are ones who have the ear of someone who works at Apple to support them if there's a dispute and either push their app through App Review or get it featured.
• It's quite a task for an individual or small team to produce an app, create screenshots and videos, localize everything in multiple languages, respond to reviews, and keep on top of technology that changes every year. The prototypical success looks more like a large organization than two guys in a garage.
• It feels like feeding into a device ecosystem of planned obsolescence and overconsumption, where developers and consumers need to keep upgrading—an insatiable appetite for more.
• The certificates and signing from the build process is complex and can bring development to a halt if you don't have the right combination of XCode and macOS (hint: keep buying new Macs).
• The expanding variety of screen sizes forces you to learn responsiveness primitives which are platform-specific and create a complex array of image and video assets at different sizes for distribution.
• The constantly changing environment will break your app and force you to either hurry and accommodate the changes or receive messages from customers asking why it doesn't work anymore.
• You can't simply share your app with a friend or even install it on your own device without paying rent or getting permission through App Review.

There are obviously lots of positives to native platforms as well, but these kinds of things weigh down smaller operations like mine, favouring large companies with resources and time to deal with this ever-growing complexity.

Developing for Web

Despite the web's challenges, there's much that excites me about its future and some of these characteristics are intrinsic to the platform:

• The concept of instant games promotes highly shareable apps via a simple link that requires no install process: show up and start.
• Having multiple payment providers, potentially with the addition of cryptocurrencies means if you wanted to also just invent your own value system, maybe some kind of post-money coupon thing, it's possible to integrate with existing systems…
• User-controlled personal data stores are already being used on the web and will eventually make their way to native apps.
• Edge apps that work completely in the browser are easy to mirror or fork, and virtually free to distribute: imagine having your site/app available everywhere via IPFS
• The culture of perpetual improvement, with less focus on versioning, is normal: people do not need to 'install updates' for each app they use on every change.
• It's just more fun and with a lower barrier to entry, which results in more diverse and dynamic communities who form part of a larger public commons: more sparks, more life, more weird.

My iOS apps have been quietly free for a while. By mid February 2022, they will disappear forever; I'm not completely sure how this works—I understand you can continue to use them, perhaps even re-download them, but only if you already have it. I would like to eventually re-make them for the web (be welcome to join me or keep me alive). In the meantime, enjoy these apps while they last. I'm jumping headfirst into a world bubbling with new possibilities and excited to develop for the largest open pool of people on the planet.

I talk often about my apps, but rarely about how I use them to make things happen. Going share some of my process on October 29th at Tools for Thought Rocks.

ToolsForThought.Rocks October Meeting

---

Video for the event with timestamps and links below. See also the chat log.

time	section	notes
00:00	Introduction
07:52	wetware of writing and doing	presentation links
08:17	doing, creating, producing
09:39	productivity trinity: capture, organize, purge	Productivity Trinity
10:47	keep going
12:08	queues
13:18	joybox for audiovisual media	Joybox
15:46	kommit for committing to memory	Kommit
17:03	Shareability	Joybox source code
18:39	Maintaining software for the long-term
21:45	launchlet for removing friction	Launchlet
23:40	emoji log for time-bound journaling and tracking	Emoji Log
25:51	Misusing tools on purpose
27:27	Data structures
28:18	Re-usable interface components	OLSKCatalog
29:18	Linus Lee and interface consistency between projects	thesephist.com
30:30	Tool-making and 'handedness'
31:28	Formats for machines versus humans
35:32	hyperdraft for reference, writing, and publishing	Hyperdraft
42:12	writing without magic
45:28	Technical stack
46:45	Update your website while typing
48:45	Building your own tool versus using an existing one
51:09	Writing emerges from accumulated material
52:40	Autocomplete helps reference the past
53:28	Twitter likes as a picture of someone's brain
55:35	POSSE versus PESOS	POSSE
57:13	A note-taking Twitter client hybrid
59:08	Cross-platform standards for public and private posts	Export considered harmful
61:44	Andy Matuschak tweets as an Agora
62:25	Making app-writing easier
67:13	Safely publishing private things
71:55	Developing apps without authentication
74:36	Throwaway software
75:42	Fragmented forks are hard to merge

I talk often about my apps, but rarely about how I use them to make things happen. Going share some of my process on October 29th at Tools for Thought Rocks.

ToolsForThought.Rocks October Meeting

---

Video for the event with timestamps and links below. See also the chat log.

time	section	notes
00:00	Introduction
07:52	wetware of writing and doing	presentation links
08:17	doing, creating, producing
09:39	productivity trinity: capture, organize, purge	Productivity Trinity
10:47	keep going
12:08	queues
13:18	joybox for audiovisual media	Joybox
15:46	kommit for committing to memory	Kommit
17:03	Shareability	Joybox source code
18:39	Maintaining software for the long-term
21:45	launchlet for removing friction	Launchlet
23:40	emoji log for time-bound journaling and tracking	Emoji Log
25:51	Misusing tools on purpose
27:27	Data structures
28:18	Re-usable interface components	OLSKCatalog
29:18	Linus Lee and interface consistency between projects	thesephist.com
30:30	Tool-making and 'handedness'
31:28	Formats for machines versus humans
35:32	hyperdraft for reference, writing, and publishing	Hyperdraft
42:12	writing without magic
45:28	Technical stack
46:45	Update your website while typing
48:45	Building your own tool versus using an existing one
51:09	Writing emerges from accumulated material
52:40	Autocomplete helps reference the past
53:28	Twitter likes as a picture of someone's brain
55:35	POSSE versus PESOS	POSSE
57:13	A note-taking Twitter client hybrid
59:08	Cross-platform standards for public and private posts	Export considered harmful
61:44	Andy Matuschak tweets as an Agora
62:25	Making app-writing easier
67:13	Safely publishing private things
71:55	Developing apps without authentication
74:36	Throwaway software
75:42	Fragmented forks are hard to merge

A while ago, after years of being "analytics-free", I decided to try Plausible Analytics and I want to share what led me to start thinking differently.

The original provocation was learning that Photopea, despite financial success as a one-person operation, earns most of its revenue from advertising and only four percent of its revenue from subscriptions or memberships. Considering that I am trying to finance my own sustainability directly via the people using the app, I thought it curious that this income equalled a sort of 'minimum wage' despite being a well-known, high-traffic project. I don't intend or know how to make something as complex and deep as a Photoshop clone, and so I wondered if I would have fewer opportunities than this—perhaps I need to be open to selling ads at some point in the future, if that's what it takes to keep content freely accessible on the web. (On the other hand, I believe it's better to avoid comparing yourself to others and complexity is not synonymous with income, but I'm not sure how to think about all this at the moment).

Another reason is that I had a hard time turning garbage numbers like 'requests' (which include bots and counts multiple files for each pageload) into something that gives me an idea of 'how many people are actually looking at this?'. I believe in talking to the people who use what you make, but I think many (or most?) people don't have time to write in their impressions, and so this will always be smaller by a magnitude you cannot know; there is value in passive feedback and I think most people would prefer this if it's done with purpose.

So far it feels good. I aggregate visitors to various projects into a single picture. It's nice to have more meaningful numbers and to find out about interesting places that link to you, like this Brazilian guy's tech blog. One of my 100 steps to success, still in-progress, is to track your growth over time, and this is another way to do that.

I hesitated all these years because Google Analytics has become a form of surveillance capitalism, and this taints most other approaches to analytics (or at least our perceptions of it). How can this be remedied? Does it help to use open-source technology? Or if the company hosting the technology aligns with your values? Collecting data generally requires trust because one cannot verify beyond the 'privacy policy'—what about being transparent and just showing what one collects?

Similar to Buttondown, which I use to send mailing lists, I dig the spirit behind the project and its team and would like to lend my support. All this feels holistic so far, but I'm open to having my mind changed again. What do you think?

---

Originally posted in Ephemerata #014.

A while ago, after years of being "analytics-free", I decided to try Plausible Analytics and I want to share what led me to start thinking differently.

The original provocation was learning that Photopea, despite financial success as a one-person operation, earns most of its revenue from advertising and only four percent of its revenue from subscriptions or memberships. Considering that I am trying to finance my own sustainability directly via the people using the app, I thought it curious that this income equalled a sort of 'minimum wage' despite being a well-known, high-traffic project. I don't intend or know how to make something as complex and deep as a Photoshop clone, and so I wondered if I would have fewer opportunities than this—perhaps I need to be open to selling ads at some point in the future, if that's what it takes to keep content freely accessible on the web. (On the other hand, I believe it's better to avoid comparing yourself to others and complexity is not synonymous with income, but I'm not sure how to think about all this at the moment).

Another reason is that I had a hard time turning garbage numbers like 'requests' (which include bots and counts multiple files for each pageload) into something that gives me an idea of 'how many people are actually looking at this?'. I believe in talking to the people who use what you make, but I think many (or most?) people don't have time to write in their impressions, and so this will always be smaller by a magnitude you cannot know; there is value in passive feedback and I think most people would prefer this if it's done with purpose.

So far it feels good. I aggregate visitors to various projects into a single picture. It's nice to have more meaningful numbers and to find out about interesting places that link to you, like this Brazilian guy's tech blog. One of my 100 steps to success, still in-progress, is to track your growth over time, and this is another way to do that.

I hesitated all these years because Google Analytics has become a form of surveillance capitalism, and this taints most other approaches to analytics (or at least our perceptions of it). How can this be remedied? Does it help to use open-source technology? Or if the company hosting the technology aligns with your values? Collecting data generally requires trust because one cannot verify beyond the 'privacy policy'—what about being transparent and just showing what one collects?

Similar to Buttondown, which I use to send mailing lists, I dig the spirit behind the project and its team and would like to lend my support. All this feels holistic so far, but I'm open to having my mind changed again. What do you think?

---

Originally posted in Ephemerata #014.

In preparing Tiny concert for a friend, I audio recorded myself playing guitar while singing and listened back to it immediately after. I tried to do this at least once per day and ended up with four or five sessions repeating this process with the same set of songs.

I was surprised by my noticeable progress in just a few days, and that the process felt productive, self-affirming, and contributing to a healthy relationship with music and the instrument—I actually enjoyed the feedback loop. I noted how my own preferences emerge more clearly: I'm definitely modelling my performance off of the recordings from which I learned the repertoire, but hearing myself makes my inclinations more malleable—music starts to feel more like a moldable material rather than something abstract or 'from someone else'. I thought I would feel overly critical, but it actually trained me to accept and even enjoy my own sound. For a few days I also had a nice routine going of breakfast, reading, stretching, recording, listening back—it felt like a thorough wake-up, leaving me ready to experience the day.

I frequently wondered, "Why have I never done this?". I always knew that people do this, and that I could too, but somehow never gave it a try. I've known about this for a while, since studying music professionally and having been around musicians and their culture for a while. Perhaps it's due to dogmas around perfection that made me feel too intimidated to listen to myself: in one context, music being more about execution than improvisation; in another music being professionalized to the point where sounding 'good' takes precedence over emotional expression. I haven't figured out my answer yet, but I find it useful to ask "What stopped me from doing this and what else is it preventing me from experiencing?"

There were obviously various challenges, but I felt uplifted knowing that one grows by learning to deal with situations. One long-time difficulty of mine is to play music at an unfavourable moment (such as in the morning, before my day starts, in sort of chilly temperature). I found myself working through feelings of clammy fingers and lousy tone, using what I have to construct something (the recursive process of using your own resources to validate your own resources), and building ways to deal with what's at hand. Another difficulty is various hesitations and mental disturbances (thinking too much and other things that impede your flow). I found multiple aspects of performance to help hook myself into the music when feeling distracted: pronunciation, enunciation, helping the body embody the music, voice projection, breathing, etc… It was a relief when I reminded myself that it's okay for me to be somewhat shoddy with my guitar playing because in this context the words are more important. I was able to overcome this binary around "now we're playing the song, now we're not" by constructing mini-routines like tuning the guitar before each performance, allowing myself to revise any ambiguities directly or through improvising, not worrying about how the audience perceives it, and generally opening myself up to be more fluid with music and sound.

To me, the ideals of 'gradual incremental progress' (so common in the world of technology) always seemed at odds with the non-linear nature of music, but I now feel like having arrived at some semblance of it that nurtures more than compromises the practice.

I'm excited to try this more in the future, not only as a way to 'rehearse' but as a way to 'compose'. I also see the approach as part of my broader idea about documenting moments:

For most of life it's possible to look back and observe your own progress. This is encouraging at times when you feel less positive about yourself. All it takes is making a note of where you are with words, sounds, or images.

In preparing Tiny concert for a friend, I audio recorded myself playing guitar while singing and listened back to it immediately after. I tried to do this at least once per day and ended up with four or five sessions repeating this process with the same set of songs.

I was surprised by my noticeable progress in just a few days, and that the process felt productive, self-affirming, and contributing to a healthy relationship with music and the instrument—I actually enjoyed the feedback loop. I noted how my own preferences emerge more clearly: I'm definitely modelling my performance off of the recordings from which I learned the repertoire, but hearing myself makes my inclinations more malleable—music starts to feel more like a moldable material rather than something abstract or 'from someone else'. I thought I would feel overly critical, but it actually trained me to accept and even enjoy my own sound. For a few days I also had a nice routine going of breakfast, reading, stretching, recording, listening back—it felt like a thorough wake-up, leaving me ready to experience the day.

I frequently wondered, "Why have I never done this?". I always knew that people do this, and that I could too, but somehow never gave it a try. I've known about this for a while, since studying music professionally and having been around musicians and their culture for a while. Perhaps it's due to dogmas around perfection that made me feel too intimidated to listen to myself: in one context, music being more about execution than improvisation; in another music being professionalized to the point where sounding 'good' takes precedence over emotional expression. I haven't figured out my answer yet, but I find it useful to ask "What stopped me from doing this and what else is it preventing me from experiencing?"

There were obviously various challenges, but I felt uplifted knowing that one grows by learning to deal with situations. One long-time difficulty of mine is to play music at an unfavourable moment (such as in the morning, before my day starts, in sort of chilly temperature). I found myself working through feelings of clammy fingers and lousy tone, using what I have to construct something (the recursive process of using your own resources to validate your own resources), and building ways to deal with what's at hand. Another difficulty is various hesitations and mental disturbances (thinking too much and other things that impede your flow). I found multiple aspects of performance to help hook myself into the music when feeling distracted: pronunciation, enunciation, helping the body embody the music, voice projection, breathing, etc… It was a relief when I reminded myself that it's okay for me to be somewhat shoddy with my guitar playing because in this context the words are more important. I was able to overcome this binary around "now we're playing the song, now we're not" by constructing mini-routines like tuning the guitar before each performance, allowing myself to revise any ambiguities directly or through improvising, not worrying about how the audience perceives it, and generally opening myself up to be more fluid with music and sound.

To me, the ideals of 'gradual incremental progress' (so common in the world of technology) always seemed at odds with the non-linear nature of music, but I now feel like having arrived at some semblance of it that nurtures more than compromises the practice.

I'm excited to try this more in the future, not only as a way to 'rehearse' but as a way to 'compose'. I also see the approach as part of my broader idea about documenting moments:

For most of life it's possible to look back and observe your own progress. This is encouraging at times when you feel less positive about yourself. All it takes is making a note of where you are with words, sounds, or images.

Tutorial

time	section	notes
00:00	Intro
00:39	Design	Rich Hickey's Simple Made Easy talk
02:15	Part 1: logic
02:39	Add a function
09:12	Simple library	OLSKHash
10:50	Complex library	Zero Data Wrap
14:41	Part 2: interface
15:58	Add a link	OLSKGazette
21:00	Access
21:42	Localize
22:39	Misc
23:48	Simple component	OLSKPlaceholder
25:27	URLs for each test
27:14	Complex component	OLSKAppToolbar
33:07	Messages
37:33	Concerns via files
38:36	General tips	'tests are your eyes'
42:27	Conclusion

Part 1: logic tests (AKA unit tests)

Requires no build system and ideally runs unlimited tests in about one second. See Modular object structure for syntax.

Part 2: interface tests (AKA UI/integration tests)

Requires a server for [[System A]] and also building process for [[System B]]. See Build and run my apps on your machine for setup. Takes more time than logic tests and gets longer with more tests: optimizations welcome. Look for localizing in another video [[localizing (tba)]].

Technical note: runs Zombie headless, no concept of CSS or box model, just HTML and JavaScript.

Access

• is it on screen or not?
• decouple visibility from other concerns

Localize

• put the maximum on screen
• run suite for each supported language
• will fail or make noise about missing translations
• decouple language from other concerns

Misc

• can be for checking attributes, binding, sending messages, anything
• decouple configuration/behaviour from other concerns

General tips

1. Test as much as you can. If something is not testable because of the testing environment, write the test that should pass and then skip it. I avoid changing anything before writing tests.
2. 'Tests are your eyes' (via Zura) – they are imperfect and should be distrusted at some level, but ignoring them entirely is like 'playing jenga with blackboxes'. Let the machine work for you.
3. Design for change. Assume that you have missed something and will need to adjust later. How easily can it be changed?

---

Part of Project workflow.

---

Reply with a comment.

Tutorial

time	section	notes
00:00	Intro
00:39	Design	Rich Hickey's Simple Made Easy talk
02:15	Part 1: logic
02:39	Add a function
09:12	Simple library	OLSKHash
10:50	Complex library	Zero Data Wrap
14:41	Part 2: interface
15:58	Add a link	OLSKGazette
21:00	Access
21:42	Localize
22:39	Misc
23:48	Simple component	OLSKPlaceholder
25:27	URLs for each test
27:14	Complex component	OLSKAppToolbar
33:07	Messages
37:33	Concerns via files
38:36	General tips	'tests are your eyes'
42:27	Conclusion

Part 1: logic tests (AKA unit tests)

Requires no build system and ideally runs unlimited tests in about one second. See Modular object structure for syntax.

Part 2: interface tests (AKA UI/integration tests)

Requires a server for [[System A]] and also building process for [[System B]]. See Build and run my apps on your machine for setup. Takes more time than logic tests and gets longer with more tests: optimizations welcome. Look for localizing in another video [[localizing (tba)]].

Technical note: runs Zombie headless, no concept of CSS or box model, just HTML and JavaScript.

Access

• is it on screen or not?
• decouple visibility from other concerns

Localize

• put the maximum on screen
• run suite for each supported language
• will fail or make noise about missing translations
• decouple language from other concerns

Misc

• can be for checking attributes, binding, sending messages, anything
• decouple configuration/behaviour from other concerns

General tips

1. Test as much as you can. If something is not testable because of the testing environment, write the test that should pass and then skip it. I avoid changing anything before writing tests.
2. 'Tests are your eyes' (via Zura) – they are imperfect and should be distrusted at some level, but ignoring them entirely is like 'playing jenga with blackboxes'. Let the machine work for you.
3. Design for change. Assume that you have missed something and will need to adjust later. How easily can it be changed?

---

Part of Project workflow.

---

Reply with a comment.

Tutorial

time	section
00:00	Heads up
00:14	Intro
01:55	The 4 steps
02:11	Step 0: Install node.js
03:37	Step 1: Open the project folder in your terminal
05:29	Step 2: Install dependencies
07:35	Running the project
08:17	Step 3: Run system B
09:34	Step 4: Run system A
11:04	Making changes
11:46	System A changes
13:31	System B changes
15:36	Localization files
16:26	Localize system A
17:19	Localize system B
17:58	Help fix this
18:43	Conclusion

The 4 steps

Step 0: Install Node.js + NPM if it's not already on your machine

Confirm by executing node -v in your terminal. I currently have v14. Earlier versions should work but you might run into problems, the closer the versions are the better…

Step 1: Open the project folder in in your terminal

From the repository page, click 'Download ZIP' under 'Code'.

Alternatively, run git clone https://github.com/wikiavec/hyperdraft.

Step 2: Install dependencies

Execute npm run setup. This will:

• run npm install without modifying the package.json file
• clear any package-lock.json file
• copy the .env-sample to .env

Step 3: Start system B

Execute npm run watch. This will:

• build the final JavaScript from Svelte files
• watch for changes to re-build automatically

Step 4: Start system A

Execute npm start. This will:

• start a node.js server
• allow the site to be accessible at http://localhost:3000
• watch for changes to reload when certain files are changed

Other notes

Avoid making changes before writing tests. See Testing logic and interfaces.

See Universal project folder structure.

Localization files (i18n.xx.yml) will not trigger any updates or be visible on reload. For system A: kill the process in your terminal with Ctrl+c and execute npm start again; if you would like to improve this, make a pull request to OLSKExpress. For system B: make a change to any .svelte file.

---

Part of Project workflow.

---

Reply with a comment.

Tutorial

time	section
00:00	Heads up
00:14	Intro
01:55	The 4 steps
02:11	Step 0: Install node.js
03:37	Step 1: Open the project folder in your terminal
05:29	Step 2: Install dependencies
07:35	Running the project
08:17	Step 3: Run system B
09:34	Step 4: Run system A
11:04	Making changes
11:46	System A changes
13:31	System B changes
15:36	Localization files
16:26	Localize system A
17:19	Localize system B
17:58	Help fix this
18:43	Conclusion

The 4 steps

Step 0: Install Node.js + NPM if it's not already on your machine

Confirm by executing node -v in your terminal. I currently have v14. Earlier versions should work but you might run into problems, the closer the versions are the better…

Step 1: Open the project folder in in your terminal

From the repository page, click 'Download ZIP' under 'Code'.

Alternatively, run git clone https://github.com/wikiavec/hyperdraft.

Step 2: Install dependencies

Execute npm run setup. This will:

• run npm install without modifying the package.json file
• clear any package-lock.json file
• copy the .env-sample to .env

Step 3: Start system B

Execute npm run watch. This will:

• build the final JavaScript from Svelte files
• watch for changes to re-build automatically

Step 4: Start system A

Execute npm start. This will:

• start a node.js server
• allow the site to be accessible at http://localhost:3000
• watch for changes to reload when certain files are changed

Other notes

Avoid making changes before writing tests. See Testing logic and interfaces.

See Universal project folder structure.

Localization files (i18n.xx.yml) will not trigger any updates or be visible on reload. For system A: kill the process in your terminal with Ctrl+c and execute npm start again; if you would like to improve this, make a pull request to OLSKExpress. For system B: make a change to any .svelte file.

---

Part of Project workflow.

---

Reply with a comment.

It usually takes me time to create projects and develop ideas before sharing them with the world. The durations always differ, but I might expect to wait a month or so as details accumulate, one or more weeks to conceive and finalize a visual identity, some weeks or months for implementation if there's programming involved, some time for considering how another person might come to and perceive the space, etc… The entirety of this process was compressed into about three hours in the case of Ephemerata.

I woke up on a Sunday morning ready to begin a normal day: made myself hot oatmeal for breakfast, read some articles. An idea came to me while reading, and I thought, "That sounds kind of cool, I should do that some day." Ten minutes passed by, and then I received a jolt and thought, "Whoa, I should really, really do that, like maybe even drop everything and get started immediately type of thing." I tried to calmly finish eating, and then got to work.

Completely consumed by this idea for a weekly newsletter, I came up with a concept and visual identity, wrote the first edition, and told the world about it before lunch. It was like standing under a waterfall, a deluge of possibilities and details hitting me intensely and all at once. In combination with my discussion forum, this very clearly represented for me a missing piece of the puzzle, one that I've been struggling with for over a year now in my journey to earning a living as an independent creator. The two create a sort of connective tissue for building a community around what I do. This sort of thing might seem obvious to many people who approach things from a less technical perspective, but I was skeptical about this approach for a long time, and it actually took me until now to arrive here.

Reflecting later in the evening, I realized something: it was Mother's Day. And how fitting it was for this idea to have emerged, fully formed, on that day: I gave birth, in a sense, to a new community, and my mother was someone who brought people together. It was like receiving a gift from her, and reconnecting with qualities that she had passed onto me, qualities that I have only recently began to cultivate more deeply. I now believe that this idea struck me so hard because—and I say this with sincerity—it resembles a new way of for me to integrate myself into the world, a gift of life. It gives me a significant resolution to various questions of belonging that have plagued me for ages, and I feel relieved, energized, and excited.

Thanks, Mom, and to all mothers, whose nurture and care transcends their time on earth.

It usually takes me time to create projects and develop ideas before sharing them with the world. The durations always differ, but I might expect to wait a month or so as details accumulate, one or more weeks to conceive and finalize a visual identity, some weeks or months for implementation if there's programming involved, some time for considering how another person might come to and perceive the space, etc… The entirety of this process was compressed into about three hours in the case of Ephemerata.

I woke up on a Sunday morning ready to begin a normal day: made myself hot oatmeal for breakfast, read some articles. An idea came to me while reading, and I thought, "That sounds kind of cool, I should do that some day." Ten minutes passed by, and then I received a jolt and thought, "Whoa, I should really, really do that, like maybe even drop everything and get started immediately type of thing." I tried to calmly finish eating, and then got to work.

Completely consumed by this idea for a weekly newsletter, I came up with a concept and visual identity, wrote the first edition, and told the world about it before lunch. It was like standing under a waterfall, a deluge of possibilities and details hitting me intensely and all at once. In combination with my discussion forum, this very clearly represented for me a missing piece of the puzzle, one that I've been struggling with for over a year now in my journey to earning a living as an independent creator. The two create a sort of connective tissue for building a community around what I do. This sort of thing might seem obvious to many people who approach things from a less technical perspective, but I was skeptical about this approach for a long time, and it actually took me until now to arrive here.

Reflecting later in the evening, I realized something: it was Mother's Day. And how fitting it was for this idea to have emerged, fully formed, on that day: I gave birth, in a sense, to a new community, and my mother was someone who brought people together. It was like receiving a gift from her, and reconnecting with qualities that she had passed onto me, qualities that I have only recently began to cultivate more deeply. I now believe that this idea struck me so hard because—and I say this with sincerity—it resembles a new way of for me to integrate myself into the world, a gift of life. It gives me a significant resolution to various questions of belonging that have plagued me for ages, and I feel relieved, energized, and excited.

Thanks, Mom, and to all mothers, whose nurture and care transcends their time on earth.