I've been running this site for just over 20 years now. I began writing it in my dorm room at Georgia Tech, hosted on a G4 Mac Mini¹, as a way for me to share technical how-to guides and news. I used WordPress for the first handful of years, then the Ruby static site generator Jekyll for a decade. It wasn't until 2024 that I redesigned and rebuilt this site from scratch using Next.js.²

I'll be turning 40 years old in 2026, which is still surreal to me. For my entire career, I was always the younger one on the team, and what feels like a sudden shift means that's no longer true. In many ways, that change is actually a clarifying feeling.

I'm more focused and fired up to do great work than I've ever been. I'm driven by the desire to craft great products: things I can be proud of working on. My framing shifted from "Can I help this team build this product?" to "Is this the problem I want to spend my best years on?" I've developed a visceral aversion to working in any environment where I don't feel like I can do the best work of my career.

My taste and judgment have compounded over these years. I've been through similar experiences that I can draw from across whatever I'm working on. Even on minor UI challenges alone, I'm still surprised at how often I pull inspiration from my time at Twitter where density was king and compact timelines ruled everything. I always try to keep that as just one input though, especially working in AI when so much is continually changing and you can't bring assumptions with you.³

My 2025 at a glance

• Sold my house.
• Left my role as Co-Founder and Head of Design at Limitless (née Rewind AI).
• Took 4 months off. Traveled, talked to 30+ founders, companies, and investors as I explored new opportunities.
• Started a new role as Head of Design at Sesame.
• Started working in an office full-time. After years working remotely, I'm loving it.
• Bought a car after 7 years without one, and learned my lesson about buying a new redesign generation car.
• Limitless was acquired by Meta.
• Personal resets:
  • Stopped consuming caffeine entirely. Decaf coffee only, not even green tea.
  • Had my second year of no alcohol.
  • Stopped wearing my Apple Watch (got annoyed with notifications, wanted to simplify.)
  • Mostly stopped wearing contact lenses in favor of my glasses⁴.

Selling my house

The year started with me finally selling the one-bedroom condo I had purchased a decade earlier. I completely regret purchasing that place. Not because it had major maintenance issues or anything like that, but because it was a horrible investment. I had it for 10 years and still lost money on it once you factor in the lower sale price, prep work to sell (staging, floor upgrades, painting), and associated fees.

It was a relatively new building in a bustling shopping and restaurant area in Nob Hill near Russian Hill. The entire building was only nine years old when I bought my unit, so I only had minor maintenance tasks over the years. I loved living there. The unit was modern, had a good HOA, no issues with neighbors, and had 500/500 Webpass as the ISP (this was before fiber was commonplace and before Google Fiber purchased Webpass).

Why did I buy this place to begin with? I got it in 2015 when I was 29. I had been at Twitter for a few years and made some money from the Twitter IPO. I hated having roommates, and the alternative of paying $4,000–$5,000 a month to rent my own apartment didn't feel like a good idea. And at the time, it felt like you couldn't go wrong buying in San Francisco. More and more companies were becoming SF-based instead of Silicon Valley, and many friends and coworkers around me were buying homes too.

I purchased it with 25% down and a 2.75% 7-year ARM mortgage from First Republic Bank (RIP, they were great). I figured seven years was plenty of time to either sell or refinance before the rates increased. That didn't help either.

I moved to New York in 2019 and rented out my condo through a property management company that handled everything while I was out of state. I was in NYC for four years and lost money every month renting it out. Not to mention the property management company was horrible and a pain to deal with. My 7-year ARM's fixed period ended in mid-2022 while I was in New York while the rate was increasing monthly. By the time I sold the unit, my expired 2.75% ARM mortgage had exceeded 7.5%. It wasn't worth refinancing by then, I knew I wanted to sell it soon.

My wife and I came back to San Francisco in 2023. That same horrible property management company forgot to have the tenant sign a lease (you had one job..), and the tenant ended up moving out unexpectedly a few months in. It lined up perfectly with the end of our apartment lease in New York, so we decided to head to San Francisco for a few months to fix up the condo, sell it, then head back to NYC.

When we got back in January 2023, it wasn't a great time to sell, so we stayed. We didn't mind escaping the New York winter for a while, and the AI boom was starting to make SF feel alive again. We still love New York, but at the moment it really feels like if you work in tech and AI, you need to be here. The energy is palpable.

We eventually got around to selling it at the start of 2025. I always thought selling it would be a hassle and that I would need to do upgrades to make it enticing. Well, it ended up being so much easier to sell than I expected.

A former coworker introduced me to a small real estate agency; they were perfect. I dropped off the keys and they took it from there. They refinished the floors, upgraded some things in the bathroom, updated the heating system, painted, and staged. In less than two months, it sold. I received 11 offers: four competitive and three all cash. Even though I lost money on the sale all things considered, I had expected it to sell for considerably less given it was listed in January instead of the ideal time in spring.

I learned my lesson with this place. I don't see myself purchasing a house in San Francisco anytime soon. The opportunity cost of the down payment alone stings. It would have tripled in a basic total U.S. stock market ETF over those 10 years.

We've since been renting in Noe Valley for the last year. I finally have enough space and my own garage, so I moved over all of my stuff that had been stored with family: my Eames chair, Pro Display XDR, and old gear like this original iSight.

Finding this rental was a huge challenge. Every evening for what felt like a year was spent scouring rental sites before we eventually found it off-market through a friend. At one point there was an apartment in Pacific Heights we loved so much we wrote a love letter (more common with purchases, not rentals), offered many months of cash up front, and even extra rent. There was just too much competition.

I frequently hear from people saying they're moving to San Francisco in a month or two. My advice is always the same: start looking for your apartment as early as possible!

Leaving Limitless

2025 started with an itch. After two and a half years of working on Rewind, then through its evolution to Limitless and the Limitless Pendant, I needed a change. I needed a new design and product challenge.

In my time there, we really embodied what a startup is all about. We had a true customer focus, endless product iteration, countless product strategy refinements, and long hours sweating the details. We were a remote team of ~15-20 people in recent years. I was the only designer for a period and wrote about what this was like in The Startup Designer.

We built a lot of stuff as we searched for product-market fit. Rewind was a native Mac app that captured everything you'd seen (via screen capture), said and heard (via opt-in meeting and audio recording), compressed it, and made it actionable. You could visually rewind time as well as search or ask AI to find anything you've seen.

I loved that it had a local-first approach, private by design, and was a bit uncanny until you got used to it. An app that records your screen all the time? Crazy. But it worked.

I would tell people that making Rewind was probably a similar user and marketing challenge to what the team at 1Password likely went through when they were starting out in the mid-2000s. "You want me to put all my passwords into this one app I'm supposed to trust with my digital life?" Crazy. But it worked.

We also made Rewind for iOS, then I spent some time diving into Windows development with C# and WinUI as we worked on a Windows app focused on using a local LLM.

While the product had some challenges with search quality due to limitations from the local approach, I still think the Rewind concept is solid. Microsoft famously thought so too and created the Rewind-inspired Recall feature. There are some things I'd approach differently if Rewind were rebuilt from the ground up today: prioritize task-based workflows over pure recall, and explore using lightweight visual models for data classification.

We then pivoted to a cloud-based product called Limitless, largely as a result of feeling limited by what we could achieve with Rewind's local-based approach. There was the cross-platform Limitless web and desktop app, and then the React Native mobile app.

Limitless started with meeting recording and summary functionality. That was a recurring use case people had with Rewind. While I personally felt that functionality wasn't the most exciting thing to work on, nor did it have staying power with countless meetings-focused competitors working on the exact same thing, we had an ambitious roadmap. The goal was to continually add more data sources over time for context.

One of those data sources was to be our own hardware, the Limitless Pendant, to capture in-person meetings and conversations to help differentiate us from competitors.

The Pendant was a bold bet, but after a year of building its companion app and dogfooding it, I realized it wasn't a product for me. I take privacy extraordinarily seriously and lean introverted, so I wasn't exactly comfortable wearing a recording device out of the house and asking for consent every time I encountered someone new. On top of that, my wife wasn't comfortable with me wearing it at home either. The product had real use cases, and we heard about that consistently from customers, but it wasn't for me.

Meanwhile, the tech industry was exploding as LLM capabilities improved at a rapid clip and I felt like I was watching from the sidelines. Agents, deep research, multimodal models, new interaction paradigms... I wanted to be at the forefront of that. The opportunity cost felt too high. My heart wasn't in it, and I decided to leave.

Acquired by Meta

The Rewind and Limitless story came to a close some months later at the end of 2025 with a Meta acquisition. It felt like a great time for the team to join a larger company with the means to really compete with AI hardware and services coming out across the industry. It was a well-deserved exit for the team.

Financially, I received a modest sum for shares I had early exercised, and for my vested in-the-money stock options. I had also previously sold some equity⁵ right after the company's last public round.

I'll likely put some of it toward a few angel investments. I've done several angel investments in the past, mostly in crypto companies like Rainbow and XMTP (the messaging protocol now used by Coinbase Base and World). However, I've declined to do them more regularly because I feel that to do a good job, you need to have the time and bandwidth to stay on top of deal flow—seek it, meet the founders, and maybe you end up investing in 1 out of every 10+ teams you come across.

Time off

After leaving Limitless, I gave myself permission to slow down before jumping into something new. I ended up taking four months off, though it didn't really feel like time off at all. I was meeting with founders, companies, and VCs for weeks, and also spent time I was working on my design portfolio.In hindsight I went overkill on the portfolio—I had two versions, the most comprehensive of which was 177 slides—but the act of doing it was a great way to reflect on how I worked, what gave me energy, and what drained it.

My wife made the most of me no longer working nights and weekends, and we ended up taking a few trips. First to Germany and Austria, then later to Milan and Lake Como for a friend's birthday.

I stopped consuming caffeine entirely in 2025. It was during the trip to a medical health resort called MayrLife on Lake Altaussee, Austria that made that happen. This place was strict: a set schedule with strict meal times along with no caffeine or alcohol. The alcohol part was fine, but getting off of caffeine was a challenge.

I had zero alcohol in all of 2024 and maybe just 5 drinks for all of 2025. I just don't really care for it anymore, and never loved the feeling of feeling something the next morning even if I only had two cocktails the night before. After the first full year of zero alcohol, it's like I was rewired and completely don't even care for alcohol anymore. I'll have some non-alcoholic beers and mocktails at times, of course.

I had been used to having a 2-3 strong cups of coffee every day. I ended up having about 4 or 5 days of caffeine withdrawal migraines as I went cold turkey. After that, I decided I didn't want to go back to my normal coffee routine. I still love coffee and have a cup of decaf every morning though. I've learned all about the different kinds of decaf processes like Swiss Water Process (chemical free; the lowest caffeine but the worst taste) and Ethyl Acetate (best taste). My current decaf favorite is by Perc Coffee, but I'm still trying out others I'm discovering on the r/decaf subreddit.

After the initial withdrawal issues, staying off of caffeine wasn't that bad. Decaf coffee doesn't dehydrate you during the day, which is something I could feel. I used to rely on melatonin and sometimes magnesium to more easily fall asleep at night after a day of coffees, but now I don't need that either. The biggest downside is that while I love the flavor of coffee it's harder to find good decaf options at coffee shops. If they do have decaf, it's likely just one kind and only served as an americano, not pour over or brewed.

I also took the time to hit reset and simplify a few other things in my life. On the nerdy side, I got rid of the two servers I had been running for a while. I had one server that managed this website's email newsletter, that I publish to very infrequently. I had been using a self-hosted web app called Sendy that uses AWS SES to send emails cheaply. I ditched that in favor of Kit. But between that and my other server I used to host my personal Mastodon instance, I hated having to login every few weeks to install an update or fix something. It's a small thing, but it freed up mental space.⁶

I stopped wearing my Apple Watch too. I was constantly annoyed by all the useless notifications and buzzing on my wrist. While I appreciated the health tracking functionality, I wanted to simplify. It didn't start as an overnight consciousness decision. I got a simple Casio F-91W watch, changed the strap and started wearing it some days. Eventually that became everyday. Half of what I appreciate is that it's not a smartwatch. The other half I appreciate is that it's just so small and lightweight.

Exploring what's next

I wrote down what was critical to me as I started thinking about what I wanted in a new role. At the end of the day, I wanted to work with an exceptionally talented team, at the forefront of AI, with leadership and a CEO who genuinely care about quality, and as little organizational friction as possible between us and an outstandingly well-crafted product.

I wasn't in a rush to find the next thing. I had time and wanted to optimize for seeing what was out there first. I'm often reminded of How To Be Successful by Sam Altman, where he writes:

“I am willing to take as much time as needed between projects to find my next thing. But I always want it to be a project that, if successful, will make the rest of my career look like a footnote.”

Being in San Francisco and being public about the fact that I was looking for my next thing was like a cheat code for that process. My days were filled as I met with several dozen founders, companies, VCs and friends.

Every founder and team I met with had a unique perspective on where the world is heading, and they were fighting through the ambiguity to get there. It's still wild to me that this level of energy and ambition is just par for the course in San Francisco.

I'm grateful to folks who took time to chat with me:

• Investors: A16Z, NEA, First Round Capital, Felicis Ventures, Bain Capital Ventures, Sutter Hill Ventures, Lightspeed Venture Partners, Marc Bhargava from GC and others.
• Companies: Cursor, Perplexity, Notion, Hooglee, Arcade AI, Microsoft AI, Sesame, LM Studio, OpenAI, Anthropic, Figma, World Labs and more.
• Friends: I reconnected with friends and acquaintances from Physical Intelligence, Vercel, Shortwave, Luma Labs, Streak CRM, Visual Electric, Humane/HP IQ, Variant.ai, Shopify, Macroscope, Agora.xyz, Adam Lisagor, Ulf Schwekendiek, Jake Jolis and others.

What I Learned

A few things crystallized from all these conversations:

• Some founders are really, really good at talking about their company. They have a clear view of the future and make the steps to get there feel obvious, almost expected. Almost like Steve Jobs's "reality distortion field." Their energy is infectious.⁷
• Builders are back. Thanks in no small part to AI, teams are doing more with far less. Orgs are extremely flat. ICs are preferred over managers. Designers who code aren't a nice-to-have anymore: they're the norm. The era of bloated teams shipping slowly feels firmly behind us.⁸ The talent stack has collapsed.
• The best designers, engineers, and product managers who weren't already working closely with AI were thinking about leaving their companies.

What I Wanted

All of this helped me articulate exactly what I wanted next after talking with small teams and large teams.

I'm happiest, most productive, and most ambitious working on 0→1 products and bold bets that scratch at something new in AI, where there's a shared understanding of quality. I would much rather be the first designer tasked with creating an app or site from scratch than a designer or manager on a team of dozens responsible for just a sliver of an app. Not on a team of dozens optimizing something that already exists. I wanted to stay close to the craft while also growing a team.

When I began this process, I actually thought I wanted to optimize for compensation and go to a late-stage, pre-IPO, or public company. I had always felt like you wanted to alternate between riskier early-stage startups and late-stage companies in your career so you wouldn't get "behind" with savings and investments. It became clear to me that was not where my heart was at all. I needed to work on something I was beyond passionate about with a team that shared that desire.

Joining Sesame

Sesame ended up being everything I was looking for and more. It's been phenomenal across the board: the shared appreciation and ambition for excelling at craft, the remarkable team comprised of industry veterans, and the bold bets we're making on the product we're building. Yes… I know everyone says this about their company when they join, but that's really how I feel.

I've never worked somewhere that truly cared about craft and understood it this much. A lot of that is due to the CEO, Brendan Iribe, who was one of the founders of Oculus VR. Brendan reached out after I published Browse No More. He's one of those founders I was alluding to in the previous section: someone who's really, really good at speaking about the importance of what the team is building, about taste, and about how great products are made.

I've been on enough teams to know that it really doesn't matter if various executives on the leadership team say quality matters. In my experience, it has to come directly from the CEO too. Brendan gets it; for software and for hardware. I later met the rest of the team, including the CPO Nate Mitchell (also one of the founders of Oculus VR), and it was clear this was a team I needed to work with.

What We're Building

We're building both software and hardware. On the software side, we're building what we call personal agents. They're not productivity assistants, they're more like a collaborator and thought partner you just talk with. But even that description doesn't do our ambitions here justice. They're much more than that.

We've been focusing on making them remarkably lifelike. That comes across in their unique personalities and how they carry the conversation. It's the sort of thing you need to experience to see what I mean: you can try our research preview released earlier in 2025 that over a million people have used. We're also working on an iOS app—you can get on the waitlist here.

"This is not another productivity assistant. It's something different: a lifelike, expressive collaborator—designed to engage and evolve with its user over time."

The second piece is hardware. We're making the world's best intelligent eyewear. They're fashion-forward and made for all-day comfort. Sequoia has more details on both our software and hardware in their article A New Era for Voice.

The mission we talk about that I really love is that we're working towards bringing the computer to life with our hardware and focus on voice-first AI. We've been saying "software is eating the world" for 15 years now. Now as AI is eating software, hardware is becoming the new distribution and interaction frontier for AI. I'm not saying we won't have phones in 5 years (I still absolutely love mine), but I'm eager to spend time collaborating with the team here to see what these new interfaces will enable.

"Hardware becomes a more popular moat (amid a surge of hardware startups). In a world where everyone can make their own software, unique products will emerge that tightly couple hardware and software." —Scott Belsky

And after five years of almost entirely working from home, I'm thrilled to be back in an office. When covid started, I thought I'd never go back to the office. I loved having my own desk setup and being able to focus.

Now I just miss working with people, whiteboarding design ideas, and perfecting prototypes right next to teammates. Also, teams building hardware kind of need to be in person with the number of physical prototypes we're continually crafting and testing out.

Design @ Sesame

It's been six months since I joined as Sesame's Head of Design, based out of our San Francisco office. My current day-to-day is heavy on design and code (Figma & Xcode for our iOS app)⁹ and helping out with things across product, hardware, brand, and marketing.

We've got a lot in store for design this year across mobile, web, brand, and hardware. It's always a fun design challenge to work beyond just software product design. Basheer Tome joined my team to focus on hardware design, interaction design, prototyping, and everything in between. He had previously worked on Google Glass, Google Pixel Buds, autonomous driving, and all sorts of projects spanning PM, ID and CMF at Fellow.

I'm looking forward to growing our design team this year. I'm the only software product designer at the moment¹⁰, and am looking to hire a seasoned product designer to work closely with me in our San Francisco office with a focus on visual design with a passion for craft and design engineering.

We're hiring for quite a few different roles outside design too.

How I worked in 2025

I finally perfected my home office setup. For the two years prior I had a small desk in the bedroom at my previous place. Once we moved, I finally had space to build things out the way I wanted. I had room for my iMac G3 and vintage gadgets, a much larger 72x30" standing desk, and a lounge chair behind it. I also finally shipped my Pro Display XDR to San Francisco from where it had been in storage at my in-laws' house on the East Coast.

For the last decade, I've had occasional wrist pain during extended computing sessions, but I have it under control these days with a combination of an adjustable desk (kept low enough so my elbows are properly angled), the Glove80 split ergonomic ortholinear keyboard, a Logi Lift vertical mouse, and a wrist brace for long sessions.

Using a keyboard like the Glove80 (or similar models like the Kinesis Advantage2 I used before it) takes some getting used to, but it's worth it if you're in a similar boat with wrist pain from RSI. Separately, I try to use AI voice dictation apps like Aqua to speak instead of type when I can. I haven't quite built that habit yet. I've been thinking about getting a gooseneck desk mic for the office, like some other coworkers have, to do this more often.

I've made a few other additions to my gear recently, but the standouts are my 333MHz Revision D iMac G3 from 1999, my original iSight camera, and my new OWC 4-bay M.2 SSD RAID enclosure. With the latter I've also started using Immich to manage my photos (hosted on my Mac, behind Tailscale) and will probably migrate my Google Photos to it.

Ironically, I now work in the office on weekdays, so the setup doesn't get as much use anymore. I purchased a car for my commute, the newly redesigned 2025.5 Audi SQ5 SUV. I haven't had a car since I sold my E92 M3 about 7 years ago. Mechanically, it's great: quick, makes a nice sound, and overall fun to drive. The rest is just okay. The interior design leaves a lot to be desired. There's ugly piano black plastic everywhere and too many controls are touch-based.

But the icing on the cake is the garbage computer system. Not the infotainment system (though I really dislike that it lacks a traditional tachometer gauge cluster setting), but the whole car's computer system has been remarkably buggy. Various warnings and check engine lights constantly come on and then vanish on their own. I took it in for service just a month after I purchased it. They kept it for more than a week and the issues persisted. Others on Reddit are having similar problems and hope an upcoming software update will fix everything. I've definitely learned my lesson about buying a new generation car.

Apps I love

• Dia has been my primary browser for the majority of 2025. After living with Arc for the few years prior, I'm really accustomed to a browser with side tabs. I've tried to get into the ChatGPT Atlas browser and Perplexity's Comet browser but they never stuck for me, even with the promise of all their agentic functionality. I just don't really have a huge need to automate things just yet.

  Actually, I take that back, I would but the few times I've tried current solutions they were too slow and inaccurate. Maybe later in 2026. About 99% of what I have AI do in a browser for me is summarize long articles, and I use both Dia's integrated chat for that, and recently, Anthropic's Claude browser extension for that.

  I just hope that Dia keeps its craft and charm even after its parent company's acquisition by Atlassian.

• Flighty for insanely good flight tracking. I don't fly that much and this app is still worth every penny. I get notified of flight delays before the airlines send notifications. I can more easily look up alternate routes, see where the inbound plane is, and more. It's just a delightfully well-crafted app.

• Yuka lets you look up the health impact of various food and cosmetic items. My wife and I use it often to make better choices when shopping, such as avoiding harmful chemicals.

  There are a few apps like it but it's simple and works well. It does not have data about microplastics (you should definitely take a look at Nat Friedman's PlasticList) yet unfortunately, but other apps like Olive and Oasis Health do.

  These days we're much more mindful about what we bring into the house and have replaced pans with non-toxic ceramic ones, plastic cutting boards with oiled wood ones, avoiding certain dish detergents, et cetera.

• Mercury is hands down the best personal banking app and bank out there. There's an annual fee but you get a lovely, well-designed modern app with things like automatic transfer rules to move money around (e.g., don't keep cash in checking, always move to HYSA) and support for sending wires really easily.

• NetNewsWire combined with Feedbin is my RSS reader setup of choice. NNW has been around since I had a G4 Mac Mini in my college dorm in 2004. Great, simple piece of software. Though I do wish it had slightly more robust search functionality.

• Things has been my to-do list app for many years. Simple, well-built apps for desktop and phone. I have a few minor design gripes with it (what designer wouldn't have strong thoughts about their to-do list app) but it gets the job done. There's an unofficial Things MCP server I've been meaning to integrate into my workflow too.

• Raindrop is where I send articles I want to read later, curate design inspiration, save interesting links, and everything in between. It also saves a permanent copy of each link you bookmark so it's still accessible even if that page ceases to exist on the web. I try to go through it weekly to organize and review what I've saved.

• Obsidian (with the Cupertino theme) is my catch-all for daily notes and more. I pay for Obsidian Sync service too. While I have various folders for different types of documents from outlines and drafts of blog posts to documents for ideas, I primarily use it for work. I create a new file each week where I write notes for the week. At the bottom of each week's document I keep a running to-do list. At the end of each day I'll reprioritize that list or write down an action plan if I'm in the middle of a large task so I'm prepared the next morning.

  While I really love Obsidian, it's not perfect. Searching for files is really, really rough in my experience. I need to keep things in organized folders as I know I'll need to find them later and can't rely on search. Also, despite a robust developer community, there's not yet an amazing LLM solution. Fortunately everything in Obsidian is flat files, so I often use Claude Code with my Obsidian vault for things like synthesizing summaries and themes across a lot of files.

  And finally, the other thing I don't love about Obsidian is the mobile app navigation. It's likely a downside of it being a highly-extensible and cross-platform app, instead of a more opinionated native iOS app.

Despite using all these apps for notetaking, saving, and curating, I don't really like the term second brain for this PKM stack. This quote below from I Deleted My Second Brain resonates with me to a degree, and I sometimes find myself saving things I never revisit.

"The “second brain” metaphor misfits how human memory works: associative, embodied, and purposefully forgetful.

When I first started using PKM tools, I believed I was solving a problem of forgetting. Later, I believed I was solving a problem of integration. Eventually, I realized I had created a new problem: deferral. The more my system grew, the more I deferred the work of thought to some future self who would sort, tag, distill, and extract the gold.

That self never arrived.""

The Year of Claude Code

2025 was the year of coding agents for me (and everyone else too). It's a remarkable, remarkable tool. At the start of the year I mostly used Cursor for smaller tactical changes, but I quickly became heavily dependent on Claude Code. It just kept getting better throughout the year.

"Claude Code (CC) emerged as the first convincing demonstration of what an LLM Agent looks like - something that in a loopy way strings together tool use and reasoning for extended problem solving. In addition, CC is notable to me in that it runs on your computer and with your private environment, data and context."
—Karpathy

There's many articles online on the proper way to configure and use Claude Code, how to put skills, agents, and CLAUDE.md to work for you, but this thread from the Claude Code creator in particular is worth a scroll:

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

Tools like Claude Code still need constant babysitting and can sometimes get stuck in a loop, trying the same solutions that didn't work. I find it critical to try out other models regularly, even for the same task. For example, I get the feeling that Sonnet/Opus aren't amazing at more advanced or recent SwiftUI tasks. In a recent example it gave me the old GeometryReader hack for getting scroll offset from a ScrollView instead of the single .scrollPosition() modifier I wanted.

These days I'm usually bouncing between Claude Code (usually via their official extension inside Cursor, which has nice expandable inline diffs) and Gemini 3 Pro via Cursor Agents. I don't have a set workflow. Sometimes I'll have Opus make a plan, then have GPT poke holes through it before Claude Code implements. I've also dabbled with tools like Conductor.

Aside from the obvious desire for faster and smarter models that just nail each task, there's one thing I wish these tools were better at: undo.

I know version control is technically my job. Git exists. But when I'm iterating quickly on a specific piece of functionality, I want to easily roll back to the last known good version without thinking about it. That's often from a previous agent response. I can leave a trail of commits behind me, but that doesn't look great on a PR. I can spend more time amending commits or dealing with git rebase, but that's friction I'd rather avoid.

This feels like something these tools themselves should help with. Cursor, for example, doesn't have diffs for each agent response. If you want to undo the last change, you have to ask the LLM to do it, wait, and hope nothing else unexpected is changed in the process. Compare that to just discarding changes if you'd made a git commit.

Design + AI

Much of what I do is design something from scratch in Figma, get it to around 90% or to a point where I have a few options I can't decide between without trying them out, and then begin building it. Figma is very much still a starting point. Lots of iteration—in aesthetics, interactions, and logic—happens while I'm building and feeling it out with real builds.¹¹ For me that even meant going deep on working with metal shaders this past year: an area that seemed too complex to approach previously.¹² However, I will sometimes use Figma MCP to help speed up parts of the development workflow.

The act of building and testing out as you build is what design is all about to me. It rapidly surfaces new ideas for iterations and directions. There should have never been a design to engineering "handoff" phase. It's the same thing. Every designer should be a design engineer too. Being able to more rapidly build designs and interactions also means you no longer have to scratch your head trying to decide if you should come up with a long dissertation about why a certain piece of feedback from a peer or executive isn't worth pursuing. Most of the time, you can just try it out and see how it feels that day. Don't close off paths too soon.

The biggest shift in design has not been on the visual design front for me. I don't necessarily need production assets with models like Nano Banano Pro, nor are there any UI design tools good enough yet to truly enhance my visual and UI design workflow… yet. I've tried to use them for coming up with design inspiration for things like iconography and brand design tasks at times, but haven't found anything that truly enhances my workflow yet.

Designers need to push on what AI isn't good at yet. To me, that means constantly seeking inspiration, curating, and communicating well. Always be curious.

You need to constantly be seeking information and inspiration. It can come from anywhere. Archive what feels good, interesting, or provocative to you. Hone your taste. The best designers I know are always curating. Some on Are.na and X. Some just in their own Figma moodboards. Some with link saving tools like Raindrop. Build that habit.

Restraint in AI

With Claude Code, Cursor Agents, and dozens of other AI dev tools anyone can build for themselves now. We're entering the era of rapidly created, personalized and bespoke software. It's going to seem even more insane this year.

Just because you can, doesn't mean you should.

The hard part now isn't building. It's restraint in this world where we have more capabilities than ever.

I've noticed this industry is a bit too trigger-happy to jump into Claude Code and start generating, then immediately commit what was one-shotted. Maybe we should all be doing our own product plan mode outside of Claude Code's plan mode.

Taking a step back to ask what we're actually building and why before we start. It's too easy to skip the product thinking and strategy. That's the necessary but slow and hard work of deciding what should exist, why, and who it's for in the first place.

What I'm referring to is just the normal product development process we've been doing for decades. Nothing new here. Just a reminder to not skip it when AI makes the building process closer and closer to a single button press.

As I design things I'm continually in a loop asking myself things like:

• Do I even need that (button/view/interaction)?
• Is that implied constraint absolutely required? Is it validated?
• And some of the Rick Rubin questions like "What's the simplest way to express this idea?" or "What's the core feeling or essence we're trying to convey?"
• I also constantly reference the brainstorming questions in this article.

Similarly, even if AI does make something for you and does it well, quality can drop fast if you're not careful to polish and clean up everything afterwards. For code quality and product design quality. Always polish it yourself. That's where craft lives.

Thoughts on personality in AI

Everyone's building some sort of agentic assistant right now. Connect your calendar. Integrate your email. Take actions. It all feels the same. A lot of assembled parts. Too many teams skip the hard parts: personality that builds trust, memory that truly enables continuity, and extensibility that meets you where you are. They also don't think enough about the why. Okay, so you can access my calendar… now when and why am I supposed to use this?

That's why too many of these tools today feel like packaged slop.

Personality and memory are what make these tools feel familiar and natural, not merely transactional. When GPT-4o was retired after GPT-5 launched, people were genuinely upset. They had gotten attached to how 4o wrote, how it felt. That's not nothing. As AI becomes more ubiquitous, more ambient—even worn—this will only matter more. Even in quick interactions, the wrong tone and style is immediately clocked.

Personality, memory, and extensibility form the defining triad of future agentic systems that you'll want to use:

• Personality: Comfortable, safe, and genuinely helpful across long-running exchanges and fleeting moments alike. It builds trust, maintains patience when things break, keeps people engaged over time, and even makes things fun when warranted.
• Memory: For intimately understanding your preferences, retrieving past decisions, and helping proactively (or at least trying to) without overstepping or making assumptions. Memory is tricky to get right. When unexpected and done poorly it can fail hard and quickly erode trust. It's not just RAG or long context. It's selective context, memory, and reasoning working together.
• Extensibility: What use would this all be if these systems couldn't do things for you and integrate into your workflows and tools?

It's time to stop thinking about building these systems as a series of LEGO bricks to slap together.

2026

2025 was a lot of change compressed into twelve months—new job, new house, new daily habits. Most of it came down to getting rid of stuff, physically and mentally, that were getting in the way. Now I'm at Sesame working on problems I actually want to solve with people who care about the same things I do. This has been a lengthy article… a lot longer than I had originally planned. If you made it this far, thank you for reading.

While I've been religiously saving interesting links and articles for inspiration in Raindrop, one thing I've started doing in the last year is maintaining a single markdown file where I paste interesting design-related quotes and related things. I wanted to close this article with a few of those.

I always like to refer to old computer and operating system reference material and designs for inspiration. The creators of these systems started from what felt like a blank canvas, drawing on things like the desktop metaphor, to build what we have today. I try to get myself into the mindset they might have been in when thinking about the next generation of computing we'll have with AI. Palm webOS is a great one too… I got a Palm Pixi Plus recently:

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

"People aren't trying to use computers—they're trying to get their jobs done."
—Apple, Human Interface Guidelines: The Apple Desktop Interface (1987)

On seeing things fresh and getting unstuck:

"[…] looking closely at the micro level can unblock you for understanding the macro level. […] Pirsig's Brick is a tool for seeing things freshly “without primary regard for what has been said before” which creates that perfect tension of challenge and ability enabling flow."
—Jordan Moore, How to Dismantle a Creative Wall

"But there's a paradox at the heart of design that's rarely discussed: the discipline that most profoundly determines how lasting and inspiring a work of design can be is a designer's ability to look away — not just from their own work, but from other solutions, other possibilities, other designers' takes on similar problems. […]

The most innovative solutions often come from designers who are aware of conventions but not beholden to them. […]

This discipline of looking away preserves the singularity that makes great design resonant. When we constantly reference existing solutions, our work inevitably gravitates toward the mean. […]

This is perhaps the most difficult discipline in design — harder than mastering software, harder than learning color theory, harder than understanding grids and proportions. It requires confidence to trust your own vision when countless examples of "how it's done" are just a search away. It demands the courage to pursue a direction that hasn't been validated by others.
—Christopher Butler, Good Design Comes from Looking, Great Design Comes from Looking Away

On design conviction:

"There's an important rule of prototyping: find the fun first and build from there. In all of your brainstorming, you need to determine what is actually fun to play. Sometimes a really complex or interesting system is compelling to plan out, codify, and parse as an algorithm… but then turns out to be lackluster to engage with. Keep moving. Find this fun as fast as possible, and don't accept anything less. Your players won't either."
—Andrew Zigler, MUD Cookbook: design meets implementation

"Conviction often stands in opposition to market trends. To have conviction before validation may make you seem weird or delusional, but it defines great artists—the ability to appreciate what others overlook or even fight against."
—Willem Van Lancker, Design Literacy

"Hayden, you can't change the world. It's not possible. All you can do is try to make your own world and then invite other people to be a part of it."
—George Lucas to Hayden Christensen

On soul:

In its purest form, design is poiesis. It is drawing ideas from the ether. It's a Muse.

"Beautifully designed products without soul, are just that: representational garden art. In all of our history, we've never had more money to design beautiful, functional and usable products. The bar is higher than ever, yet, they've never been more boring and devoid of soul."
—Steyn Viljoen, Beautiful, boring, and without soul

On software today, especially with this era of personalized software:

"software isn't just functional anymore. it's quietly turned into a lifestyle brand, a digital prosthetic we use to signal who we are, or who we wish we were.[…] people don't just use these apps. they use them to imagine themselves differently. more organized. more intentional. more in control. apps like superhuman or linear aren't just tools, they're lifestyle upgrades. software that feels like a reward. a signal that you care about your time, your taste."
—you are what you launch: how software became a lifestyle brand

"We stopped doing the real thing that would be the most empathetic, useful, and that would actually serve business outcomes best: building stuff that worked well and that people would love."
—Jenny Wen, Don't trust the (design) process

As for books, I did not read much at all in 2025 and really need to change that in 2026, similar to my 2017 goal of reading 24 books. I'm currently reading The Soul of A New Machine and The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality. I'll probably find more from this list of books mentioned on Hacker News.

Footnotes

1 After 20 years, I finally got my G4 Mac Mini back. The person I sold it to reached out after noticing my gear pages where I've been collecting vintage gadgets and asked if I wanted my old Mac Mini back. I need to add it to my gear section. I have an old Intel Mac Mini too.

2 I've been running this site for half my life. These days I mainly just try to keep my gear pages updated frequently, and then only focus on an article when I have some topic I want to go deep on, a perspective I think is unique and worth unpacking, or generally just something I want to nerd out on. That tends to mean about one longer article per year, which is fine with me. Work consumes a lot of my time and I'm passionate about designing and building great products.

3 Also, I've worked with too many people who use their past experiences as the primary input for a decision. That's not only the wrong approach all too often, but it also makes everyone around them resent their unwillingness to consider new ideas and perspectives (or even just entirely different culture, values, quality, people).

Not to mention.. do you know how annoying it is to keep hearing, "When I was at [company], we did X."? I always, always try to catch myself when I'm about to say that about my time at Twitter or another past company.

4 Even with fresh daily contacts, they're still nowhere near as comfortable as glasses on my eyes. Glasses are just easier and I've started collecting eyewear I really like, such as Mr. Leight and Lindberg.

5 Not being emotional with investments like that and being quick to diversify is something I learned after being at Twitter for 9 years where the stock was performing pretty poorly most of the time. Whenever I'd vest new RSUs and have an open trading window I'd immediately sell them. The logic there was "if you had $X in cash right now, would you go out and buy Twitter stock?" The answer for me was usually no.

6 Mastodon didn't quite pan out. I got really excited about the prospect of owning and hosting my own social media back when the Twitter exodus began in 2023… but it was never quite as active over there (same with Threads and Bluesky), and I still prefer Twitter/X.

7 I stopped the process with one company after meeting the CEO I would have worked with who lacked that energy. Instead, it felt like they sucked all the energy from the conversation.

8 5-10 years ago it felt like there was a wave of designers that figured success was going on the management track early (after sometimes just 2 years as an IC) when on a large team and we had bloated teams with too many managers that slowly lost touch of craft over time. Now they're having a hard time getting back into IC.

Similarly, designers that don't do well with 0-1 design from scratch, for example without relying on existing design systems, will have a harder time operating on these smaller, craft-focused teams. AI tools today can't help that much on the visual design side, and people lacking those foundational skills will need to find ways to adapt.

9 My 2.5 years endlessly designing, building, then redesigning and rebuilding every part of my app Stocketa prepared me well for sweating the front-end details. Lately I've also been touching some metal shaders as well.

10 We do, however, have quite a few hardware product designers and industrial designers.

11 The new problem is now when people ask for a specific Figma mock of something in the app; the latest version is in the app and it's much more work to go back and update Figma mocks to be production accurate. Probably a product opportunity for Figma there.

12 Dan Hollick's Making Software chapter about shaders is a great read.

I love and adore today's so-called AI answer engines: tools like ChatGPT, Perplexity, Grok, Copilot, and Gemini. I use them at least a dozen times throughout the day, and I'm sure you use them frequently as well. Their convenience is undeniable.

I turn to these tools to save me some clicks, but I give up control for that convenience. What I gain in efficiency—no longer needing to browse through slow-loading ad-heavy websites just to find out how to tie a Windsor knot or grab a recipe—I lose in the personality, idiosyncrasy, and creativity that makes the web feel authentic. We've come to expect, seek, and rely on this.

Browsing with traditional search engines wasn't exactly seamless but you were in the driver's seat. You would occasionally end up on some obscure personal site or forum that was unexpectedly right up your alley.

Those magical detours defined our web experience, enriching us with insight and creativity while establishing human connections. Today's instant answers with these AI tools sacrifice this beautiful chaos that once made the internet so captivating. But there's hope—a new kind of browsing experience might just be around the corner.

Before we had AI answer engines, and before we had search engines we just had lists of links with web directories like aliweb, Yahoo! Directory and dmoz. You'd tediously wade through these directories to find and absorb content you were interested in, or just to explore and tinker. Everything online was created by people and you were getting a glimpse into their world with each site.

The web grew. We gained search engines, blogs, feed readers, social media and more. While there were new ways of creating content and new ways of consuming, when you really needed something you'd still turn to a search engine and click around until you found what you needed.

This led to inevitable moments of delightful and serendipitous discovery. There was real joy in discovering another unique voice online, someone whose articles and interests were right up your alley. Their style of writing lended itself to being devoured in one sitting, while you scan their site to see how you can bookmark or subscribe to keep tabs on their latest works.

It wasn't just about stumbling upon a random personal blog that was a fun occasion. It was finding communities you didn't know existed. Even just recently as I've been upgrading my iMac G3 and running into some issues, I came across a forum for Mac OS 9 enthusiasts that was chockfull of the exact type of content I was looking for. It was not easy finding it. It didn't happen in one sitting, or with one tool and ended up being something I caught in passing that someone said in a video on a blog. But the payoff was worth it for that moment.

Serendipity while browsing the web wasn't just a byproduct of how the web began to form. It stretched our empathy by exposing us to diverse voices, nudged us out of echo chambers, and kept our web from becoming monotonous.

That style of surfing the web is fading away. What social media hasn't already taken over, or search engines haven't already diluted by sending us to ad-laden mainstream sites, is now steadily being eroded by AI-powered answer engines.

AI answer engines are phenomenal in what they do. I can fire off a prompt and relatively quickly get a blurb with the exact information I need. It really can't be overstated how great they are.

But I've lost something profound in the process—the joy of the unexpected detour. I'm not really browsing the web anymore. At best, I'm just browsing AI interpretations of a limited slice of the web. A slice that I didn't even pick or have control over. My surface area for discovery is now whatever these tools decide to show me.

It's not just me. Traditional search engines are evolving into answer engines. Zero-click searches are rising and will continue to rise. Nearly 60% of Google searches now end without the user clicking to any site. And now Google is experimenting with "AI mode"¹ to take this to the next level.

Core issues

Is this really a problem?

This is just another classic example of technology evolving. Who cares if it's a bit harder to find some smaller websites? I see a few issues at play here, and it extends beyond just web browsing. At a high level, these AI answer engines lack transparency in how they work, remove control, and homogenize what's left, sucking all vibrancy out of what makes the web special.

• 1) Deprioritized attribution

  These tools largely show sources as a tiny footnote link. As an industry we started using that design pattern to link to receipts to prove the LLM was not hallucinating. We need to highlight great content when it's most relevant, not bury it with a link and a little generic hovercard or popover.

• 2) The black box of search

  How do these tools index and rank the web? How do they decide what content is most relevant to a given question or user? They largely prioritize mainstream sources. How do they interpret your question and turn it into keywords to search their bespoke web index? How do they know when they've retrieved enough info? We lost the agency over these things we had with search engines.

• 3) Summary homogenization and mode collapse

  Even with access to diverse web sources, responses from these tools can feel a bit... off. Fine for when you're only looking to fetch basic facts, but limiting and less vibrant for anything else. It's like having access to every book in the world, but only being able to read them summarized by the same person with the same writing style.

1) Deprioritized attribution

The way these AI answer engines approach attribution leaves a lot to be desired. The early days of LLMs were especially riddled with hallucinations. The industry began using tiny numeric footnote citations to show that they had the receipts and there was actual data behind each sentence. I even did the same (albeit showing screenshot thumbnails too) when designing and building this feature.

In addition, these tools try to impress upon us that they are mighty and have referenced some huge number of webpages while coming up with each response. They display this information as a pile of favicons or list of sources, with no easy way to understand why they were included or how they were used. You're not meant to wade through it, nor should you have to.

Each source receives roughly the same visual representation with these tools. There's no transparency if it's from a reputable mainstream news site, a single author that's a domain expert given their past works, or a site you've frequented before. At most you'll get an expanded card or sidebar showing more the favicon, domain name, article title along with truncated content.

Some tools do it better than others, including the domain name as the citation instead of a number, or listing a few sources in the footnotes. But that still doesn't tell me much about the site, author, why this particular source was selected, and how its content was used. There's lots of signals that can be used to help guide understanding here.

It would also be interesting to also consider LLMs employing a system similar to X's Community Notes (née Birdwatch when I worked at Twitter) to clarify the context of and add perspective of web sources. For example, a source might seem upstanding but then you discover a whole Hacker News thread explaining in detail why it's not accurate.²

And finally, if you take a particularly dystopian view it's not hard to see potential second order effects of these tools with their deprioritized attribution. Perhaps authors will begin focusing on their own empires, where they have control over how their content is seen and monetized—such as moving it to private newsletters, away from the prying eyes of LLMs. AI companies may license data from bigger sites that do this, but definitely not your personal blog or sites on the small web.

Better or more prominent attribution isn't the solution to everything. It's a way of framing content to reflecting a broader range of perspectives, and elevating enough signals to allow the reader to understand what they're presented and why. Simply sampling the top X keyword results on a topic isn't enough to do this or reduce the echo chamber feeling; you also need greater control, understanding, and transparency in the search process.

2) The AI search black box

We also face lack of transparency regarding how these tools search the web to gather and process information needed to answer your questions. There is the potential for search and ranking bias, or lack of clarity at the least. Questions like "How are they creating their search indexes?", "What do they value when ranking sites?", and "How do they select a set of web results for user queries?" get elevated.

AI answer engines make countless hidden decisions about what sources matter and what information is relevant—all without your input or awareness. You get the illusion of comprehensiveness, when in reality you're getting a narrow slice of available information filtered for you.

These tools each have their own way of searching the web. Some may lean on third-party search indexes like Bing (ChatGPT) or X/Brave Search (Grok) but conduct their own crawling and ranking, while others handle everything independently. You've probably become fairly accustomed to how results feel in Google or DuckDuckGo, and you have a good grasp of how to wrangle them to find what you're looking for.

Now we're dealing with a new system entirely, but this time you're disarmed—you've lost your agency to fiddle with keywords, endlessly navigate pages, decide when to try a new query because one wasn't fruitful, and so on. Of course, you can always ask the AI answer engines a different question or provide a follow-up, but you still lack control over how they're translating your prompt into an index search.

Perplexity, for example, tries to provide greater transparency when doing a Pro search by showing the exact keywords they used to search their web index. However, I find this approach gives me even less confidence in what it was doing. Customers approach these tools thinking they are all-knowing AI supercomputers... and then see their thoughtfully-posed question get dumbed down to a 4 word search? I have no control over that process nor when it decides to keep searching.

What that type of UI does accomplish well is the job of communicating progress successfully during a long-running task. Even more intricate UIs exist, such as those from ChatGPT, Perplexity, Gemini, and Grok for deep research³ tasks that providing a peek into CoT reasoning. ChatGPT's deep research does do one novel thing when presenting sources though, it shows a tiny snippet of how that result was used.

There's also risk on the other side of it: letting users assume that the response they get is the truth. Maybe the cursory web search the answer engine did behind the scenes wasn't thorough enough? This is especially the case when dealing with niche topics. (Grok does the absolute worst here: for niche topics it won't reference any websites at all!) You've really got to scour the web to find what you need. If these tools are just a few keyword searches in their search index, that won't cut it. They don't know when to keep searching or ask for further clarification.

I realize that having to fiddle with search engines, while it can be seen as a control, can also be a nuisance at times. I'm not trying to be too dismissive here.

The huge benefit I'm flying past is that LLMs do a pretty solid job of understanding your intent and nuance—a crucial trait, given that most people still struggle to write great questions. Though I also think we should do more to guide people here; Elicit does a nice job with this UI to suggest different ways to ask precise questions.

We deserve so much more here. If AI tools understand our intent so well, they should deliver much more natural, interesting, and diverse results that feel indistinguishable from having a panel of experts at your side.

3) Summary homogenization and mode collapse

You know the feeling. AI-generated content often doesn't feel great. It feels slightly off; vaguely mechanical, even predictable. LLMs are largely consensus machines. In the pursuit of zero bias, you end up systematically smoothing out any novel perspectives or viewpoints introduced through these already not-too-diverse web sources used as context.

This feeling where models lose their creativity after post-training is often called mode collapse. Its makes LLMs particularly unsuitable for tasks like creative writing. Sudowrite, an AI writing tool, specifically addressed this problem of "AI-isms" when announcing their new writing model. And just recently, OpenAI mentioned they're working on a model made for creative writing.⁴

When you try to please everyone, you wow no one.

The way we build and train LLMs has led us to this. I could keep going down the rabbit hole and discuss the need for LLMs to get better at creativity. This is another thing you feel, even if you can't quite put your finger on it.

People could tell when Sonnet 3.7 felt a bit worse than 3.5. They were impressed when GPT 4.5 could do more despite not being a benchmark-killing model. I've definitely noticed this with 4.5 and have been putting my Pro subscription to use. I just wish we as an industry cared as much about this side of LLMs as we did with coding and reasoning capabilities.

Even with the right web sources, there's little insight into how AI answer engines use the content of each web source when generating their answers. Similar to the potential for search bias, we lack insight into how each web source is weighed and what other signals are used for determining what to incorporate in responses. Without intentional guidance, LLMs naturally lean toward averaging rather than amplifying unique, minority, or particularly insightful viewpoints.

Okay, maybe we're onto something here. But where does that intentional guidance come from?

Intentional personalization

Tools that grow with you. Tools that understand you.

Today's AI answer engines face fundamental challenges that go beyond the feeling of nostalgia for the old web, surfacing some bespoke notion about serendipitous discovery, or wanting more indie content bubbled up. The real issues—weak attribution, black-box decision-making, and homogenized responses—threaten to flatten rather than enrich how we use the web. Browsing the web isn't and shouldn't be a one size fits all experience.

The current generation of AI tools faces a prodigious challenge: how can they surprise and delight you when they know almost nothing about you?

The solution isn't overwhelming people with more controls, endless configuration opportunities, or exceedingly prominent website cards and attribution. People are confused enough as is selecting the model to use, or having to choose between needing a web search, a pro search, or a deep search, et cetera.

What personalization really means

These tools need to be more personalized to you and tailored to your needs. I know, I know... the term personalization gets tossed around a lot for countless uses—often carrying negative connotations, conjuring images of invasive ad targeting. But there's a better way.

AI personalization doesn't have to be about consuming every detail of your life or cloning yourself. We've fended off giving too much personal data to individual companies, why start now? You don't need to be digitally cloned to help you throughout your day. Even a little bit of info about your past interactions, goals, and interests can go a long way to delivering experiences that resonate more deeply with you.

A better way

This might come as a shock but I don't believe we want to embody some magical "it just works" scenario with personalized AI where these tools know everything about you, build some comprehensive understanding or model of you, and act as you. I believe a more intentional, transparent approach would serve us better, for several critical reasons:

• Behavior ≠ intent: What I do on my computer, phone, or browser is not always what I want to do or who I want to be. That can be a moving target. Just because one user ends up seeing and reading a lot about pop culture news doesn't mean they're not more interested in reading about another topic they're having trouble discovering. This is why it's not as easy as just sucking in as much raw data from the user as possible.
• Context matters: Your needs and motivations can change quickly. They can be based on time, location, task, who you're with, and more. You might be focused on a particular project and don't want personalization to be influenced by what you do at other times. I like to think about this akin to having different profiles in your browser. When researching a specific industry or topic for work, I don't want my personal interests bleeding into my results, and vice versa. This goes much deeper than just a work and home separation.
• Transparency is non-negotiable: Users deserve clarity about how their data shapes their experience. This means showing when personalization is active and providing intuitive controls. Even something as small as highlighting a blurb you enjoyed, requesting more depth on topics of interest, or correcting AI assumptions about your knowledge level.

Providing users transparency and control in tweaking how AI interprets them is critical to seeing, reinforcing, and correcting assumptions as they go. We need to invest in exploring some of these things as an industry. These tools are remarkably complex and we can't hope to nail it on the first try without some light user guidance along the way.

I'm okay doing a bit of work as an end user to shape my experience; and this doesn't just have to be a text response. As a random example, imagine a simplified interest graph representing how the AI understands you, where you prune irrelevant nodes, amplify important ones, and add entirely new focus areas that the system may have missed.

This isn't an entirely new concept, I think we're just so focused on increasingly more capable foundational models and discrete skills like reasoning that we're not quite at the point of going broad enough for things like this. OpenAI has inched in this direction in the past with its Memory and Custom Instructions & Traits features.⁵

These current implementations don't yet fulfill the capabilities I've outlined here. For example, it's unclear how ChatGPT decides to save memories, as they often seem to sporadic while also too specific. Additionally, custom instructions are great for high-level information about you, but things like traits feel more task and prompt-specific; not necessarily something I'd always want at the account level.

Personalizing without overreaching

Okay so providing users some control to tweak as they go is all fine... but what kind of source data are we talking about here?

Controlling the OS or the browser are the most powerful positions to be in. While it's hard for most large companies to even think about competing at the OS level, several have begun to compete with browsers: The Browser Company and Perplexity have already announced working on new AI browsers. Maybe OpenAI will enter the arena too.

Even basic browsing data offers powerful personalization potential. What content did you engage with deeply versus merely glance at? What did you create versus consume? Which topics consistently draw your attention over time? These patterns reveal far more than explicit preferences ever could.

There's a lot more to talk about when it comes to data capture here—from OS file access to accessing more detailed info from messaging apps, connecting to various cloud providers (email, docs, bookmarks), or even just knowing what apps someone is using or has installed while accomplishing a task. Some of those can be considerably harder integrations to justify with the additional privacy questions they raise.

I'm already on a bit of a tangent here, but I think the best route, barring inventing your own OS or browser that magically gets massive market adoption, is diving deeper into task-based routes of asking for, clarifying, and showing how context is used (touched on in [object Object]). It won't be easy though. You'll need to build systems for storing and querying these preferences with each LLM interaction. You won't want to just inject a ton of this as context with every call.

The key is balancing intentional personalization with user agency.

Why does personalization matter again?

Even with light personalization, AI answer engines could meaningfully tailor their responses to you. They would know you're very technical and experienced with the topic at hand to skip the basics and dive deeper into technical concepts. They would know you've been writing about technology for 20 years and really enjoy the underlying ways things work and always want that deeper understanding. And so many other things that might seem like minute details at first, but combined really add up.

They could know enough about you, your past interactions, interests and goals to guide you without overstepping, respecting your time and intelligence. A thoughtfully personalized system would:

• Connect the dots: Help connect new concepts and topics to previous ones you've read about as a frame of reference.
• Identify and manage echo chambers: Help you peek outside the echo chamber by surfacing novel perspectives.
• Leverage trusted sources: Help you learn from web sources you're already familiar with, while balancing new perspectives you may desire.
• Anticipate needs: Proactively suggest content you may be looking for before you've had to ask, in addition to doing tasks for you (The agentic aspect of this type of personalization could warrant an article of its own.)

Technology that knows you, even loosely, and helps you out in these ways isn't a particularly novel concept, but we can't lose sight of it as we design, iterate, and build these AI tools we all use.

Preserving the web's magic

Don't get me wrong, I love these tools. ChatGPT, Perplexity, Gemini, Grok, and others have earned their place in my daily workflow, largely displacing my use of traditional search engines.Yet without thoughtful evolution, they risk homogenizing and muting the web's rich diversity into bland, generic responses—eliminating what made the internet magical to begin with.

The large companies behind these tools have every incentive to develop deeper, more nuanced understandings of their users. In recent months, we've seen firsthand that these companies don't have much of a moat. Switching costs for users are as low as can be: just head to the App Store and pick up the next AI tool topping the charts. We saw it with DeepSeek one week and Grok another.

By adding more intentional personalization to their products, these companies will not only grow their moat and deliver more impactful, tailored answers but also embrace and highlight the web's unique voices and perspectives.

Will it help them directly achieve AGI? Maybe not. But it might start to feel like AGI sooner when these tools are more personalized.

This requires inching towards intentional personalization with refined AI product functionality, greater transparency about how these systems make decisions or apply personalization, and intuitive controls to let users guide their experience without becoming overwhelmed. We can augment human curiosity and creativity rather than replace it.

The magic of browsing the web isn't quite gone, but it's waiting to be reinvented.

Footnotes

1 It's always interesting to see how companies market their AI capabilities. Some really try to downplay AI and make it more about the opportunity, not the technology. Perplexity has more humanizing taglines like "Where knowledge begins", Grok has "Understand the universe", and OpenAI is rather utilitarian with ChatGPT just focusing on uses it can do without a specific tagline (of course OpenAI itself is all about safe and beneficial AGI), and then Google does the opposite and just calls it... "AI mode".

2 I know that is a bit crazy to consider; imagine just visiting a site today and your browser tells you this site is not accurate or has some other editorial issue with the content. That's not the job of a browser or other foundational technology, right? The difference here is that people did not seek this content out themselves, and they don't know what they're looking at or have all the tools available to decide on their own at a glance. The AI answer engine dug that all up on its own, so it's critical to provide as much info as possible to help people be informed about what they're consuming. You can't just put a disclaimer at the bottom saying AI can make mistakes and move on.

3 With every AI company coming out with roughly the same features it's starting to get a bit noisy with all the different modes, let alone models, to use to accomplish your task. That's another problem entirely, but I'm not here to talk about that. I just want to say how amazed I was the first time I used ChatGPT Deep Research. I forked over the $200/mon for the Pro subscription (and I'm still paying for it the next month) and give it a whirl.

It's remarkable how comprehensive it is with just about any prompt. It asks you for feedback before it dives in so you can steer it a bit more which is nice, though the UI for that could be easier than having to reply in a single textarea to a bunch of bullets/questions. ChatGPT Deep Research is the type of thing that gets me really excited about the evolution of these AI tools. They materially save me time and help me go deeper on things that interest me, like learning about topics thoroughly.

4 There was a whole bunch of discourse about this on X, particularly around whether people even want to read stories made by AI. I think we're jumping too far to one end of the spectrum where AI is writing everything. As a writer, I want an LLM that can act as a thought partner. I will provide the ideas, outlines, drafts and I want something to act as an editor, devil's advocate, and mentor all in one. For that role it's key that these tools can actually write well too, not just code, execute python scripts for complex math, and help with reasoning. The way they communicate is critical too. I'm not just thinking about it for writing articles. I want this for helping me frame documents like persuasive product briefs I write, et cetera.

5 Another sign that OpenAI is thinking about personalization was spotted in their recent announcement for the new Responses API. They showed a brief example use case for the file_search tool to gather user preferences for an agentic task. The exact implementation was left up to the API consumer in that example of course. While this article is generally about AI answer engines and the web, personalization like this will be especially important for agents.

The title of this article is a reference to an immersive theater work called Sleep No More I saw in NYC a few years ago. It tells the story of Macbeth and there's some interesting parallels I'm drawing on from this article. For one, loss of agency. When you visit you're immersed in an environment where you feel like you lose control (similar to what AI answer engines feel like they're doing today). You're a spectator wandering around while confusing things happen around you.

However, it can be incredibly rewarding. The fun comes from being able to excel at learning new skills and wearing many different hats while being solely responsible for large efforts.

• The startup designer's greatest strength is their speed and versatility. It's the light aiding in the search for product-market fit as resourcefully as possible.

• The startup designer is part artist, part scientist. The scientist views product design as something to be tamed with rules, systems, and principles; a thorough optimizer. The artist is aware of some of those rules but often chooses their own path. The artist runs by feel, and is known to always detach components. One crafts a system that helps with consistency, accessibility and scaling; the other continually challenges it and provides the friction needed to improve it.

• The startup designer can survive—and thrive—without relying on a design system. They can go from a blank canvas for a new homepage or landing page design and bring it to life in a way that embraces the brand and marketing strategy.

• The startup designer is relentlessly resourceful, and embraces any task, even the mundane, unfamiliar, or gargantuan. Helping with company swag, brand design, icon design, packaging print design, use case landing pages, et cetera. There are a few exceptions where outsourcing makes sense, but most of the time there's not enough time to find a contractor, onboard them, ramp them up on project context, and guide them through iterations.

• The startup designer knows where to compromise on quality, when to push for it hard, and how to advocate for it beyond intuition, armed with customer feedback, insights, and company goals.

• The startup designer perpetually exhibits strong ownership and knows what to work on. Their priorities come up naturally from working closely with the team and seeing what users are running into. They know the right fidelity, speed, and urgency for each task.

• The startup designer embraces ambiguity and is naturally optimistic. The cards are already stacked against every early stage startup. The team needs to be crazy enough to see through it all and envision the future they're building and convincing others of. When there are inevitable moments of uncertainty—with a feature, with the entire product, with a company pivot—the startup designer takes action to find clarity, gather data, and explore alternate solutions. The pessimist criticizes, the optimist creates.

• The startup designer balances their desire for craft and extremely high-quality shipped products with the pre-PMF startup's need to prioritize shots on goal. The faster you're able to ship (and nurture what is shipped), the more shots you can take, and the more likely you'll reach product-market fit. There are times when spending an extra week or two ironing things out and polishing matters, but most of the time it's hard to make that ROI math work. This compromise is one of the harder parts of the job.

• The startup designer doesn't try to predict designs needed for future versions of a feature that hasn't been built yet. They do enough design due diligence to make sure it works reasonably well for the near-term, then move on. Chances are that feature won't live long or work out anyways. And if it does well, it'll probably be redesigned and rebuilt based on new information.

• The startup designer fully separates themselves from the work. There is no time for ego. There will be hard feedback at every turn: from the team, from the customers. Everything worked on is the result of countless iterations. There's no point getting worked over a design that probably won't matter in the long run, or even next week when they're focused on something else.

• The startup designer is pragmatic. They know they can't refine everything to perfection before it gets shipped, and that not everything will ship. But they know when it's worth advocating for a bit more quality and rigor.

• The startup designer has a natural urge to thoroughly explore designs for any task. Even with a minor visual design task, the startup designer knows the power of continuining to explore iterations and alternate designs. Sometimes the best design is Frame 1, sometimes it's Frame 37.

• The startup designer knows that even unshipped designs provide value. These designs can show the team what's possible for the future vision. They can prove a certain direction isn't worth investing in. They can show why another design is a better choice. Some of the startup designer's best design work will go unshipped and they know that's okay.

• The startup designer is vocal. About product direction and requirements. About technical issues affecting users. About marketing and storytelling. About branding. About prioritizing issues. Not only about their own thoughts, but also about the customers' thoughts.

• The startup designer asks a lot of the same questions to drive toward simplicity. Is X even needed? How can we remove this step? Is this actually a problem? Why can't X and Y be the same thing? There's a myriad of basic foundational questions like this for any set of designs that can help frame the challenges in a new light.

• The startup designer never simply hands off designs. They care too much to treat them like finished objects to be lobbed over a fence. They document the basics but know there is no substitute for working closely with the team to build it together. New information, such as technical constraints, edge cases, and forgotten error states, always bubbles up while building, and the startup designer is there to help, often jumping into the code.

• The startup designer is technical. Not just to prototype ideas, help build features or add polish, but also to intimately understand technical constraints of the product which helps them with design exploration.

• The startup designer knows that new ideas need to be protected and nurtured to be able to have a chance at growing. They will set context with stakeholders, share exploratory visuals or docs, and continually find ways to evangelize.

• The startup designer talks to customers directly, shares concepts and synthesizes feedback. They tell everyone about The Mom Test.

• The startup designer knows what altitude to operate at. One feature might require a few optimizations via incremental design, while another may deserve taking a step back and rethinking the entire foundation or direction.

The startup designer may not know to do all these things on Day 1, but learns over time.

It was March 2020, I was in New England when covid quarantine had just begun and I found myself much more homebound. In these situations I'm not one to just do nothing. I always have some sort of project or hobby to keep me busy, be it taking and editing photos, writing detailed blog posts, or coding something.

I had always wanted to learn iOS development, so this felt like the perfect opportunity. I was particularly keen to learn SwiftUI to build my designs natively. Years back I had dabbled with writing an Objective-C app, but it never quite filled me with joy, to say the least. As a designer, I've spent the last decade getting good with prototyping tools and frameworks to mimic realistic, interactive mobile prototypes. Building it myself was the natural next step to give me even more control over the experience, and get even deeper into the craft.

I started learning Swift and SwiftUI basics with courses like Design+Code, and Hacking with Swift. But I knew myself—I learn best with a project of my own. I knew exactly what I wanted to build: a better stock portfolio tracker. The stock market had taken a plunge with covid and I was doing dozens of trades per week with everything on sale. It would be fun to have a simple app of my own to track the performance of my trades instead of dealing with the subpar sites and apps from my stockbrokers.

Little did I know this project would consume my nights and weekends for over two years, often spending 10-20 hours a week on it. I built a ton of functionality, sweat all the details, wrote a comprehensive node backend for it, created an LLC for it, and managed an active Testflight. I was learning Swift and SwiftUI along the way, so I was often redesigning and rebuilding as I went.

Eventually, I decided to stop pursuing it. I'll get into the why a bit later. This post is for me to document Stocketa. I designed and built a lot that I'm proud of and want to have somewhere to archive it before I pull the plug.

What is was Stocketa

Stocketa was a simple portfolio tracker designed with care. It came out of my frustration of having to check the clunky apps and sites that my brokers had just to get a glimpse at how my investments were doing. I'm a casual investor and don't need much from a tool like this but I had assets in various places, and I just wanted one easy and well-designed place to check them. I wanted to see real per-transaction gain/loss info, based on my own cost basis.

While there are tons of apps, brokers, and neobanks that address this, nothing quite felt like what I wanted. There were several types of solutions in this space:

• First off, there are simple stock apps like Apple Stocks that let you see stock charts, news, and more. They have good data and don't require any accounts to use. However, they offer no functionality to log your holdings and track your gains/losses.
• There are lots of broker apps (e.g., Robinhood) that let you trade and track your holdings, but they only let you see your holdings from them, not from any other financial services you might use.
• Then there's a whole category of what I'd call advanced stock services like TradingView (and several that have since died or pivoted over the years), but they're not mobile-first or as elegant as I wanted.
• There are broader investment advisor services like Personal Capital. While they do often have some aggregator functionality to link up your other accounts, they're not that powerful for diving into individual assets, aren't particularly well-designed, and are primarily focused on upselling you on their own investment advising services (seriously, I used to get endless 8am calls from Personal Capital).
• And there are lots of smaller apps on the App Store where you can track your holdings but the design and UX leaves a lot to be desired. I've tried most of them.

From a design perspective, I generally found that financial apps bias towards density when displaying your assets. They assume you have tons of stocks and prioritize a list view where you have to tap in to a detail view to see more info. I found myself constantly tapping in, manipulating a chart or looking at some basic stats, then swiping back and repeating all that for several stocks. It was not easy or the kind of at a glance info I wanted.

That left me with my challenge. I wanted a simple portfolio tracker aimed at the casual investor. It didn't have to do it all, but it should aim to do a few things well. An app just for me.

Going custom

I was more than thrilled to be working on a new app from scratch. After years of working at large companies with rigid design systems and gobs of stakeholders for every little design decision, I was yearning for some creative freedom. Freedom from process, freedom from typical design constraints. I would be in full control, designing and building it myself. It was my side project after all.

I had gotten tired of designing for traditional mobile apps. You know the type.. you add a tab bar, a typical navigation stack, page header and the app already feels significantly basic, muted, and limited out of the gate.

This was my place to have fun. I wanted to go custom and toss out whatever components the system gives you for free. And I knew that by having to figure out how to build various UI components from scratch, I'd learn a lot along the way. Almost all of Stocketa's UI is custom.

I will say that going custom is almost always the absolutely wrong thing to do 99% of the time. The operating system you're working in—be it iOS, Android, macOS—has invested a ton in a highly-considered suite of components. They're remarkably accessible, well-tested, and work on a variety of devices.

It's absolutely no small feat to consider creating a custom component for your app. However, when going custom does make sense and you're okay with the added scope and responsibility, the app becomes your canvas to do whatever you want and make it yours.

The first area where custom made sense for me was general app navigation. When I got started, I knew I wanted this app to have minimal app chrome. I didn't want a standard tab bar and header taking up space. I wasn't going to require much navigation: most things would just live inside the stock cards from the home timeline.

The app would be focused around showing more with less. Personally, I only cared about tracking a few stocks, but I hated the work of constantly having to tap in to see a detail view, or interact with the chart. As such, the main scroll view needed to be more immersive and not get occluded by unnecessary app chrome.

It started with app navigation, custom stock cards, sheets, and more. Needless to say, I spent a lot of time on the details with everything being custom. Below are a few examples:

Designing and building

I started with the basics: getting a scroll view of stock cards working, adding charts, and hooking it up to a database for persistence (initially Core Data before moving to Firebase). Then I added the requisite network calls and polling to update the stock card from a financial data provider. I started with IEX as the data provider as they had a decent API, reasonable pricing, and allowed commercial use, which would be required for a consumer app like this to go on the App Store.

One of the initial key decisions with Stocketa was that I wanted to track stock transactions in a comprehensive way. Simply logging the number of shares you had for each stock was not going to cut it. This ended up being a significant amount of work to do properly, but it was necessary:

• For each stock sale or purchase I wanted to be able to display not only the total gain/loss, but per-transaction gain/loss so you could tell if an individual transaction was a good trade.
• When it comes to stock sales, I needed to know the cost basis method (FIFO, LIFO, et cetera) so I could correctly calculate and display the realized and unrealized gains on a particular transaction. When selling shares, I also needed to know from which previous transaction or transactions the shares would be sold so I could get the correct cost basis and accurately calculate the gain/loss based on the cost basis method.
• And then there was dealing with stock splits, which seems simple at first glance but ended up being quite a bit of work to build in a robust way: not simply altering previous transactions. They should be automatically applied for new splits, but also able to be manually applied if you didn't log split-adjusted transactions.

At some point I gave it a name: Stocketa. In Greek you might say "marketa" (Μαρκέτα, though αγορά might be a more proper word) when referring to a market, so this was like coalescing Stock and Market with that in mind.

When I was interviewing for a new job in 2021, I created these slides as part of my presentation after talking about my work at Twitter for the previous 9 years. These weren't all of Stocketa slides, and there was a lot of additional talking points I had for each slide, but you get the idea.

A note about SwiftUI

I kept designing, building.. and then redesigning and rebuilding. One of the side effects of learning Swift and SwiftUI as I was building this was that I was constantly redoing specific pages and parts of the app as I went. I continually found better ways to build things, and similarly I would continually refine designs. About a year or so into building Stocketa I wrote about my experience with SwiftUI. Much of that still rings true.

SwiftUI has come a long way since iOS 13. It's more performant, there's more parity in available components and functionality compared with UIKit, and you get more control over things. And with iOS 17, you get some goodies like shaders, keyframes, scroll transitions, and more.

There's still a gap between the types of things you can do with AppKit and UIKit, but SwiftUI is undeniably a powerful tool that's dramatically more approachable. And not just a coding tool; it's a great design tool. Designers can quickly lay things out, hook up interactions, and get a real feel for a design using a native tool.

Almost all of Stocketa's UI is built with SwiftUI. There were only a few occasions when I found it necessary to use UIKit to achieve some goal.¹ None of this would have been possible, or drawn me to take a closer look into building iOS apps, if it hadn't been for SwiftUI.

What I built

I used the app daily and continued pouring time into every feature and detail to meet my high quality bar. While I initially planned for this to be a simple to build app that would not require a backend, or even any user accounts, that did not last for long. I quickly realized I needed my own backend to unlock a few things.

At first, this was so I didn't have to include the API key for my financial data provider inside the app for security reasons—I wouldn't want someone to find it and start running up my bill by abusing it. I created a backend proxy for the API with rate-limiting and throttling. Then, I wanted to have it be authenticated with user accounts, so I added Sign In With Apple along with a stock data caching system so that I only had to fetch stats for a stock once with a certain time period (depending on the particular stat that was either seconds, 24 hours, or weekly) regardless of however many user accounts needed that stock info. The main goal with that was to also reduce my costs associated with financial data API usage.

By this point I really started enjoying the speed at which I could update endpoints and business logic entirely on the backend. I started moving logic I had in the app to the backend. Stocketa was starting to come together.

Even though this was just a solo project, I used Linear to keep track of tasks, ideas, features, customer feedback, and milestones.

I had prioritized lists of things to build and bugs to fix. I was using—and loving—Linear for this. Here's a list of most of the things I built for Stocketa:

I ran a small TestFlight alpha with close friends, then increasingly I added more people. At one point I was up to around 1,000 people. That was the most I wanted to allow. I received lots of feedback from overall great first impressions (below), to general feature requests, and of course lots of bug reports.

Already the app is filling a need for me in its personal approach to tracking investments: no pushing for sales, no integrations with brokers and no unnecessary permissions. Brilliant.

Simply amazed at the SwiftUI work you’ve poured into this app. So beautiful. The onboarding alone is a masterclass in attention to detail. Bravo.

love it, this feels so polished and slick already... really great use of SwiftUI

Just got the invite, added my stocks... the animations are beautiful, design is clean and precise... it’s all around beautiful. Congrats!

F**k, man. This app is incredible. You’re building all of this on your own?

Dude. This app is f**king beautiful. Really great job. Just imported shares - super easy.

This NUX is insane. The particles when you add a stock. Gives me the happy brain chemicals..

I had thousands on a waiting list but there were API and hosting costs associated with the increased usage that I didn't want to bear yet, as well as a huge increase in support and customer feedback that took a lot of time to manage. You start to hear the same types of feedback, and it just becomes a chore to manage that many emails. That good news was that something was resonating and people cared enough to go through the work to send in bug reports and feature requests.

The website

At some point early in feature development I took a break to focus on the website. At first I wanted a simple landing page to build interest, and collect emails for a waitlist so I could keep people in the loop. And I didn't want to spend that much time on it.

There was nothing fancy or particularly special about this initial page. It was just something quick I wanted to get out the door. And now, a while later, there's a lot I hate about this early design. The background texture was too strong, the headline alignment feels odd with the phone.. but I digress.

In that initial design I did start playing with some wave-related elements—a loose reference to stock market charts going up and down. And then to add to that, I built a few mini stock cards gently hovering in place (thanks to offset-path CSS along with 2 keyframe animations) in the background. Each stock card had an SVG line chart—loosely based on that stock's actual performance around the time—that would animate on page load. I ended up keeping a version of these mini stock cards on the latest version of the website, and then on an onboarding screen inside the app.

The original inspiration for these random floating stock cards was from my now out-of-date work page where I highlighted projects with some large cards, each with their own intro animation based on the project. One of them was for my work on Twitter Video, where video clip thumbnails would fan out from the phone on hover (shown below).

Homepage design v1.0

In early 2021 I ended up getting around to designing and building out the first complete homepage for Stocketa. I had enough functionality and features built that it felt worthy of investing some time into showcasing them on the site.

Lots of app websites at the time (and still now) had the typical hero section on their homepage: some app screenshot in a phone frame off to one side, with accompanying header and subtitle text adjacent. Nothing wrong with that, but I wanted something a bit more engaging. I wasn't entirely interested in optimizing for conversion, and cramming a lot in above the page fold.

I thought it would be nice to try to do something where the 3D phone frame was angled and then began to change position on scroll while a brief teaser video of the app functionality played. Apple had done something similar in recent years with product pages, such as the first-generation AirPods Pro. They used over 100 frames of the AirPods that would progress as you scrolled:

There's a lot of ways to achieve an effect like this. One route route is using Lottie and essentially converting each frame of your video or animation to a base64-encoded string in a json file for the Lottie web player to manage. It's not a flawless solution, however, and can incur some large file sizes depending on what you're doing. It's best for vector micro-animations, not large devices with complex visual content. I also didn't want to incur the cost of that large initial json download blocking the very first thing you see on the site.

Instead I opted to have javascript display a sequence of frames composited to canvas along with an offscreenCanvas for performance. I used Rotato to import my short Stocketa screencast, create a 3D phone video, and then create a PNG sequence of frames. I wasn't super pleased with the quality—the phone frame didn't look super realistic and had some rough pixelated edges—but it was good enough compared to doing it all by hand with other design tools.

I then exported optimized transparent webp, and jpg files (with accompanying alpha masks created in Sketch to save bandwidth) and had the javascript detect which file type to use for the animation. While I was pleased with how this effect turned out, it ended up becoming a rather huge annoyance when I wanted to update the content later—it's a pain to generate, optimize, and update the image sequence each time.

And finally, as for the rest of the content on this site I went with a basic feature card approach, sometimes called a "bento box" layout; particularly when varying card sizes are used. This is a layout that I've grown to like a bit less over the years as it has become very common.

Homepage design v2.0

A year later, it was time for another redesign. Stocketa had more functionality, and a lot more refinements. I had more to share, and I had grown tired of the 3D phone frame interaction. It was neat but it was just there for show; it wasn't the best way to show off parts of the app as it scrolled off screen. It was also a pain to update the frame sequences. I essentially just wanted to take screenshots of the real app from the iOS simulator and upload them.

Separately, I didn't want a super long page with a lot of repetitive modules and screenshots. I wanted a skimmable feature list. I began to wonder if I could get away with just a single phone frame on the site that showed everything.

I eventually landed on a two pane approach: the device frame was always in view, fixed on the right side, while the scrollable left side contained the feature list. The trade-off with this design was that it would require hovering over each feature item to be able to update the screenshot shown in the device frame. I figured an interesting compromise to that would be having the phones stack up and away on scroll. Almost like the old Apple Time Machine backup UI.

I built several versions of this and found that it didn't feel great. There wasn't much scroll distance so if you scrolled at a normal or fast pace, you'd see a bunch of phones flicker by you as the animations tried to keep up. It was too busy and hectic, not to mention a lot of state management to deal with jumping between your current scroll-based position screenshot to a hover-based screenshot if you hovered over a feature list item. I ended up simplifying a bit and only having the scroll-based UI manage just a few states: the intro phone frame, the first feature screenshot, and then a final animation at the bottom of the page.

After sorting out the core interactions, I had to figure out how to deal with mobile and tablet interactions. The fix two-pane layout made this a bit of a challenge. I ended up turning the header into a carousel of device frames you could scroll through.

And then finally, I added a few small bits of polish ✨:

• Hero title text gradient changes based on scroll
• The icon accent color and background circle color change based on scroll
• When hovering over any feature list item, there is a subtle background color change created by an overlaid gradient. SVG-created noise/grain is also overlaid on top of the background.
• When hovering over any feature list item, or when you're reached the end of the page, there's a subtle icon particle emitter that floats up icons from the bottom. Each feature used a different icon for this.

Overall I liked this design, but looking back at almost a year later, the gradient text and background colors feel a bit too much for my taste now.

API troubles

Eventually it became clear that the quality of financial data Stocketa relied on was not cutting it. The first provider I used, IEX, would sometimes have charts outdated, inaccurate prices (especially for less frequently traded assets on the IEX exchange), and lacked data for OTC markets (they required you sign a pricey license directly with OTC), as well as significantly limited data for Nasdaq-listed stocks (even basic things like pre-market and after-hours data). The last straw was when IEX dropped mutual fund data entirely, all without any advance notice.

I later used another provider that allowed commercial use that didn't charge too much ($100/month) but I had even more problems with their data and reliability. Endpoints were even returning old and incorrect data, and even once alerted to issues, their team would not only ignore the bugs but claim they didn't exist. I couldn't ship Stocketa with unreliable financial data to people that would be paying me for a quality app.

I also could not get certain types of data with paid APIs. I had to build a scraping engine on my backend that would visit a few sites to get the data I needed for less updated data like dividend yield, earnings dates, and even for OEF data (other providers would be more than a day delayed for this at times).

Needless to say, this was all frustrating. It was a hassle, hard to maintain, and unreliable. At the same time, my backend continued getting more involved to deal with more and more of the intricacies of dealing with stocks. Things like dealing with companies merging or stock tickers renaming.

Starting out I thought getting access to a stock market data API would be the easy part. I quickly learned about the world of market data feeds, SIPs (Securities Information Processor), and vendor agreements.

Quality market data exists, it's just not made for indie app developers. It's very expensive. Several leading U.S. market data providers have commercial use data pricing starting at $2,000 per month. And that's not for everything, if you need things like index data or options data, there's more charges ahead.

I spoke with one of these providers last year, trying to get them to understand how small app developers need affordable commercial use data. They presented a startup-focused plan that they were pitching for $499/month in addition to a per-MAU fee. Even that I would still consider very expensive for my needs, and it seems like that may have fallen by the wayside and is no longer promoted on their website.

I could spend months developing Stocketa, incurring that monthly API cost until I went live (or risk getting shutdown if I tried to use a cheaper non-commercial plan during the TestFlight phase) then not make enough money to cover costs on the App Store and have to shut it down shortly after anyways.

Overall, it feels like no one in this cares to cater to the developer and startup crowd, or they believe there's not much money for them to pursue there. This was the same case with Plaid when I briefly looked into getting access to their investments API to automatically sync holdings data. They required some sort of minimum length contract.

Why I stopped working on Stocketa

When I started this project, I really began to wonder why where weren't any great indie apps focused on stocks like this. Just simple, well-designed apps to help the casual investor keep track of their investments. Well I think I was starting to get my answer: getting quality financial data, even just for the United States, is a nightmare. You can only get it if you have a lot of money to invest in your project. And good luck if you really want a great API with comprehensive international data.

I can't help but draw parallels to what happened recently with the Twitter and Reddit APIs. The risk of running your project or business solely on top of another company's API, no matter how reliable you think they may be, is extremely high.

Stocketa was always meant to be a side project—never a real business. For it to be a real business, I would need to keep adding functionality and introducing more ways to make money. I couldn't just have a simple and elegant little app tracking your stocks. It would have to do more, like dipping into financial advice services, or offering stock trading. That's a hyper-competitive space lined with massive companies. That would mean a busier, cluttered app. The exact reason why I started Stocketa was because of all those cluttered apps.

I decided to stop working on Stocketa for a few reasons:

• Data: As mentioned above, all the expenses and challenges associated with acquiring reliable, affordable, and high-quality financial data that would make it feasible to release this as a reasonably priced subscription-based app.

• Support: The associated investment in customer support. Based on how people were using my TestFlight, it was going to be a significant investment to keep up with support, emails, maintenance, and ongoing feature development. However, part of this was likely due to complexity incurred from having to fix or skirt around unreliable data. There were lots of things I wanted to keep improving and refining with the app and that wouldn't end any time soon.

  If I were to release and charge for Stocketa, I would feel especially on the hook to resolve issues in a timely manner and that's not something I can accomodate now because of the next point.

• Time: And most importantly, I've found something more worthy of my complete focus and attention: Rewind AI. I sunk a lot of nights and weekends into Stocketa over the years. It consumed every spare moment, even taking over my occasional time writing blog posts here when I had something to share. That was something I really missed. Now, I would much rather be focusing my creative thinking time on how I can improve and grow Rewind.

I originally started working on Stocketa with one goal: to learn Swift and SwiftUI my way with a project that was interesting to me. At the time that was scratching my own itch of keeping track of my investments. While it turned into a much larger and unshipped project, I learned a ton about native iOS development and was able to push myself creatively.

These days I'm happiest investing my design, product and development time into Rewind AI, where my SwiftUI knowledge learned with Stocketa has been tremendously helpful.

Footnotes

1 I only had to go down to UIKit a few times. One time for things like custom text fields for more control over interactions, styling, text input, and formatting. Another to use a CollectionView for drag-to-reorder stocks. A third time for creating particle emitters in a few places, like confetti effects, as well as one area where I have some twinkling stars in a night illustration when the stock market is closed. And one last time to get more control over gestures. I needed to get a location when a long press begins and SwiftUI LongPressGesture() didn't provide that, so I used UILongPressGestureRecognizer instead.

While I would go through the process of culling photos that I published online, I didn’t do that for what I backed up. I kept everything. I always thought, "what if I want to go back to this and edit it differently one day?"

I kept every RAW photo I shot, every video, every GoPro clip... I even kept every phone photo going back to my first iPhone. And why not, storage is cheap and easy, right?

The terabytes kept adding up. I added close to a terabyte with New Zealand. Hundreds of gigs with Africa. When you hit a few terabytes the obvious solution is to move to a NAS, or Network Attached Storage. I wrote about this extensively in 2015 with Storage for Photographers (Part 2).

Years back these were pretty dumb devices that would just appear as a networked drive for your computer to manage. Today, they’re full-blown personal servers, capable of running self-hosted apps and services. That makes it easy to have them encrypt your data, and automatically back your files up to cloud services, which is probably what you want if you’re paranoid about backups and try to follow the 3-2-1 rule.

Over the years I paid thousands of dollars just to keep those RAW photos safe. At one point I think I had copies on 3 or 4 separate cloud services.. you know, just in case. I later upgraded to another NAS that was physically a bit smaller.

In hindsight, I couldn't care less about 90% of all that data, if not more. The fact that I had terabytes of available storage made it all too easy to not be picky with what I was backing up and just archive everything.

When it was time to move to a different apartment, I took that as the perfect excuse to simplify. I no longer wanted a NAS in my life. A little whirring box, always making random hard drive noises, always taking up space, always making heat. Though I’m sure my perspective would be a bit different if I had enough space to hide the NAS in a perfect server closet completely out of sight and mind.

I needed to get rid of tons of RAW photos for which I no longer cared. I knew I wouldn’t be able to get rid of everything and I still wanted maybe 2 TB of local storage, separate from my computer. My first inclination was to just look for a tiny NAS that I could load up with 2.5” SATA SSDs, or something even better like M.2 NVMe SSDs. I didn’t find anything I liked—most small NAS devices would still require some massive barrel-jack power adapter.

Picking an M.2 SSD enclosure

I ended up deciding to get a small, simple external Thunderbolt SSD enclosure. In particular, I wanted an M.2 NVMe SSD enclosure. M.2 SSDs are much smaller and faster than other modern SSDs using SATA. I wanted an small, bus-powered enclosure that was Thunderbolt 3 or 4, and had some basic heatsink or thermal pad for the SSD.

There were a few options I looked at. The Sabrent Rocket Nano looked perfect at first glance due to its tiny size but they don't sell it as an enclosure, and it's only USB-C, not Thunderbolt, so I ruled that out. Then I looked at a Thunderbolt 3 enclosure from Sabrent. Unfortunately, some reviews pointed out issues with performance and reliability that had me concerned. There was also a new Thunderbolt 4 enclosure from Satechi, but it wasn't shipping (and still seems to be out of stock). That aside, it looked like a great option, but it was far too large for some reason.

After a lot of looking I eventually landed on the OWC Envoy Express. I was hoping for a more aesthetically pleasing option but OWC has been a reputable brand I've been familiar with so it felt like the safe option. I don't like how the Thunderbolt cable is part of the case design (you can detach it but you have to open the case), but it wasn't a dealbreaker for me. At the time I purchased this, it was a bit cheaper at $79.

The Envoy Express enclosure is all metal and seems very well-made so I'm quite pleased with it.

As for what SSD to use with the enclosure, I decided to use one I already had: an older 2 TB Samsung 970 Evo. At the time I was also parting out and selling my gaming PC (didn't use it enough after I got an Xbox Series X and it was taking up space) and I decided to repurpose the 2 NVMe SSDs I took from it. If you want to do the same, you can find affordable 1 and 2 TB options from Western Digital, Samsung, and SK Hynix among others. It's when you start looking for 4TB SSDs that the prices go up considerably.

Installing the SSD in the OWC enclosure took less than a minute. There's two screws to open the case, then one more screw to fasten the SSD. The case has a built-in thermal pad that touches the top of the SSD, though I wish it had some sort of cooling for the bottom as well.

Setup and disk encryption

The next thing I did was open up Disk Utility on macOS, format the SSD, then set up encryption. While there's lots of ways to encrypt your data—like VeraCrypt which touts plausible deniability with hidden volumes—I opted for the encryption functionality built into macOS for simplicity.

With the SSD ready to go, the hard part was determining what photos and data I wanted to from my NAS I wanted to keep and transfer to this SSD. This was made particularly hard as my NAS was very slow. I had gigabit ethernet but that doesn’t matter, these spinning disks are barely faster than 100MB/s for sequential read even with a RAID setup. So my long process over a week or so was transferring a folder or two to my laptop overnight, as much as I could with the available space I had on my MacBook Pro's internal SSD.

Once on my laptop I had to go through and decide what to delete and what to keep. There were a lot of easy ways I was able to save space by cutting things like GoPro videos of which I had hundreds of gigs from trips. I didn't care for that footage much and the important clips I had already used in other videos elsewhere.

But there's no getting around it, this was an arduous process. For some older trips I only kept the post-processed original size JPGs and deleted the RAWs. Then there were tons of just random photos I deleted. It took me a few days but eventually I was able to shave a few terabytes; enough to fit the important stuff on this 2 TB SSD. (I had a bit of overflow which I tossed on the other USB-C external enclosure I had which I won't use often so the speed isn't important).

Cloud encryption and backup

With the photos and data trimmed down and ready to transfer to the SSD, I needed to figure out how I wanted to have this SSD backed up and encrypted on cloud services. For that I turned to Arq.

Arq is a backup power tool for advanced users. It's a standalone Mac app that connects to just about any cloud service including AWS, Backblaze, OneDrive, Wasabi, Google Cloud, as well as all S3-compatible storage providers. The best part is that you bring your own credentials for those cloud services, and you have fine-grained control over how things are backed up, stored, encrypted, and much more.

I decided to separate my photos and other more important data into different folders with different backup strategies. Photos took up most of the 2 TB and I wanted them backed up but I didn't expect to access them frequently so I didn't want to use the Amazon "S3 Standard" storage class. I decided to use S3 Glacier Instant Retrieval for my photos.

I'm no stranger to Glacier, Amazon's slower and cheaper data archival storage tier, and have been using some form of it for a decade, but I never had a great experience. It always felt unpredictable and slow; yes, I realize that's the basically the trade-off you sign up for. As of 2021, Amazon added a new type of Glacier storage called Instant Retrieval. So you get the benefit of more affordable data archival storage along with quicker retrieval times.

There's quite a few S3 storage classes to select from: Standard, Standard Infrequent Access, One Zone Infrequent Access, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive. It's important to familiarize yourself with the functionality of the S3 storage class you plan on using. And that's just with AWS, you can to use any other cloud provider you like with Arq.

To give you a rough idea of the prices associated with some of these S3 storage classes, here's what it would cost to store 2 TB per month, with no other actions or transfers:

And then, for my other data, which was more important and not nearly as sizable, I opted for S3 Standard Infrequent Access. Here's how that looks in Arq:

Arq also lets you specify encryption for your data—separate from the macOS encryption I set up that's required to mount the drive—so I did that as well. It's important to note that you will need the Arq client to be able to access the encrypted files again; they're unreadable if you go directly to the storage bucket on S3.

That's it! I'm very happy with the new setup. I'm relieved to no longer have a NAS taking up space and making noise in my house. The external SSD is tiny and I still have control over where my data is backed up online. I can easily add more cloud storage destinations later on as I see fit.

Cloud control

However, after all this work slimming down my archives, the job is not done. My NAS was just the first target. I still have a stockpile of data and memories across other services like Google. Take Google Photos for example. Absolutely amazing service. I love the heck out of the product. And while Apple's Photos functionality is great, I've always loved all that Google Photos had to offer from amazing search to strong sharing functionality.

I just wish Google Photos wasn't owned by Google. I'm trying to reduce my reliance on consumer-oriented Big Tech products like this in favor of services where I have more control. Google has been heralded for their data portability tool Google Takeout, which includes Google Photos data, but in my experience using it was all but pleasant.

First, I had to wait days to let the archives prepare, which I understand what needs to happen with this much data so that's fine. But then, I had to download more than a dozen separate zipped files amounting to over 800 GB. I don't even think I had that much space on my laptop, let alone extra space to be able to unzip them all. And once unzipped, I don't recall the files having any sort of helpful organization to make it feasible to trim down moments you don't need. I gave up on that.

Cloud storage services make it all too easy to eagerly backup anything and everything without being intentional. Now we've all inadvertently become data hoarders.

Just because we have easy access to near-infinite and increasingly more affordable storage doesn't mean we should be using all that space. The next generation of cloud-based services need to design for curation and control. It doesn't feel like an immediate concern, but it will only continue to increase.

These days getting your Google account hacked isn't just about your email. It may be about your entire digital life. This is more than just decluttering, it's about control, security and privacy too.

A lot has happened since I published my article on the open source decentralized social networking service Mastodon a few weeks ago. I saw a lot of interest in and discourse around that post that was great to see. Since then, a few notable things have happened that have caused Mastodon usage to spike yet again.

Twitter unsurprisingly ended up entirely banning third-party Twitter clients, including hugely popular ones like Tweetbot and Twitterific. I briefly summarized the ebb and flow of being a developer working with the Twitter API in the last post:

"Long story short, Twitter made it hard. Hard to even get an API key and get your app approved. Hard to get bugs fixed or new features accessible via the API. Hard to access the data developers wanted. Hard to not hit arbitrary constraints or limits. Things were always changing, rugs were pulled, announcements about new priorities and new rugs were made, only for them to be pulled again (read this, this and this)".

Well, the final rug was pulled. Fortunately, there was a bit of a silver lining. The folks at Tapbots were able to launch their lovely Mastodon app Ivory. The launch went so well that a flood of people took that as an opportunity to take a closer look at Mastodon and join. Mastodon has grown from 500,000 active users last year to now being almost at 10 million.

Mastodon just keeps getting better. There's more authentic conversations and far less linkbait and thread spam from influencers. It feels like a place I'd prefer spending more of my time to catch up on things.

With my interest in Mastodon, I recently decided I wanted to take the next step and host my own Mastodon server for my account: @stammy@stammy.design. In my previous post about Mastodon I provided some details about different routes you could take to self-host Mastodon. Today, I'll show you how you can host your own Mastodon instance, step-by-step.

So you want to host your own Mastodon server?

And why you would want to do host your own Mastodon server? If you've read this far, you probably already have a hunch or two as to why, but here are a few excuses to choose from:

• You value being in complete control over your Mastodon identity, data, and privacy. You don't want to risk it on an instance where you don't know the moderators, don't want to be under their control, or simply don't trust them to maintain the server long-term.

• You want a speedy Mastodon experience. By controlling your own instance you can set it up with the appropriate resources and hosting location near you to keep Mastodon feeling speedy at all times. That's not the case with various instances, especially the larger ones experiencing rapid growth.

• You want a weekend project, because Mastodon is open source and able to be self-hosted

• You see lots of people running their own instance and it seems cool.

• You want a better Mastodon user name, one that speaks more to your identity or interests. Run Mastodon on your long-time domain name or an entirely new one, paired with whatever user name you like.

Whatever your reason for wanting to host your own Mastodon server, I'm here to help you get started. I'll walk you through the process of setting up your own Mastodon server. I'll also provide some tips along the way to help you get the most out of your Mastodon experience.

What you'll need

At a bare minimum, you'll need a domain, some money, and some time:

A domain. Picking the user name and domain name you wish to use for your new Mastodon instance is probably the hardest part.

You'll need a domain name you can connect with your new Mastodon server. You should also know the basics of how to modify DNS records on it. This varies by domain name registrar but is generally pretty easy to figure out. If you don't have a preferred registrar yet, Google Domains is pretty easy and you don't have to make a new account with two-factor auth if you're already a Google user.

Otherwise, I also like Amazon AWS Route 53, but it's a bit harder to use and they don't support nearly as many top-level domains (such as .design, .dev, et cetera) as other registrars.

Some money. For a single user instance you can get away with $6/mo with the lowest plan on masto.host. but if you have a lot of followers (or just want a beefier server), you'll want to upgrade to a bigger plan and that could run you closer to $50/mo.

And a few hours.

If you opt for a more involved hosting setup you'll need access to a few more things, such as an SMTP server to send emails, and optionally, access to a cloud service such as Amazon S3 to host media. I'll get into that in a bit.

Choose how you'd like to host

The easy way or the hard(er) way?

I'll show you two different ways to setup your own Mastodon server. For the most part I'm assuming you are only setting up Mastodon for yourself, or just a few people. This guide is not really meant for someone wanting to setup a Mastodon server that will accomodate hundreds of users as that will take you down a different path.

Option 1: Using a dedicated Mastodon host

The easiest way to get your own Mastodon server up and running quickly is with a host that specializes in Mastodon hosting. There are several, but I'll share how to use one of the most popular ones, Masto.host.

So what exactly do I mean by dedicated host? You won't have to worry about the typical setup and maintenance required with a regular host, like configurations, software updates, backups, et cetera. This might be route for you if you want the easiest possible way to get started, and having full server control is not as important to you. You won't have complete control over the hardware, the software (beyond Mastodon itself), how your media is stored and served, or anything lower level like that.

While you won't have the ability to tweak things and keep an eye on performance, but it's an easy way to get started for cheap. The most affordable Masto.host plan is only $6 per month for up to 20GB of media storage and 2GB database. For a casual single user without a lot of followers this should be okay. Masto.host lets you upgrade to higher plans if you need later on.

Personally, I did not want to use an option like this. I wanted to be able to serve my media files with a CDN, control the entire server config, as well as just know more about the hardware used in my server (SSD? NVMe SSD? etc). I always want to have significant headroom on my server in case any of my Mastodon posts goes viral. I don't want to have a bogged down server limiting the reach of my posts.

Option 2: DIY with a regular webhost and server

The other option is getting a VPS or dedicated server, setting up Mastodon and its dependencies. While this route takes considerably more time to setup, it's the most flexible by far. You control everything and you can eke out more performance and functionality. And some hosting providers will give you a head start with a Linux image with Mastodon pre-installed—there's quite a few things to configure but this makes it a bit easier.

Maybe you decide you want to modify the code to remove a rate limit, or change the character limit of posts? Maybe you want to move to a fork of Mastodon, like Hometown. Want to serve your media from a fast CDN on a subdomain that you have backed up? You can do all of that on your own server.

As expected, it will take longer to setup (a few hours) and it will probably cost more. But if you're reading this far, you probably already know your having own server is right for you.

Setting up Mastodon with Masto.host

Option 1, the easy way

This is by far the easiest way to get started. By the end of this section, you'll have your own Mastodon instance running on your own domain. You only need access to your domain name registrar (or DNS provider if use a separate service) so you can change a DNS record.

You don't have to worry about getting access to an SMTP server to send notification emails, nor will you have to figure out how to save media files to a cloud provider.

Sign up and change DNS

Visit Masto.host, choose a plan, and provide your domain name (though you can run it as a subdomain on masto.host if you wish). You'll be greeted with a page telling you to add a DNS A record so your domain name can point to your Masto.host server.

Every domain name registrar / DNS provider has a slightly different way of modifying DNS records, so I can't show too much more detail there. You'll likely need to log into where you have your domain name registered and look for some DNS or zone settings.

Installation

When you've successfully added that DNS record, Masto.host should automatically detect it and begin installation.

The installation screen said this process usually took a few minutes. Unfortunately, in my case it actually took a whopping 8 hours. I hope that's just temporary due to a temporary spike in new users.

Create your Mastodon user & upgrade permissions

Once that's done you can go right to your new Mastodon instance and create an account. This will be your Mastodon account, so choose the username you want.

After creating your Mastodon account, you'll just need to do one more thing. Go back to Masto.host and look for a button called "Change User Role." Here you can upgrade your new account to have "Owner" privileges. Now your account will have access to a new Administration tab in Preferences.

That’s it!

That's pretty much it! There are some things to fill out, and settings to change in Preferences which I go over later in this article, but your server is now online and ready to explore!

Aside from that, there's not much you can control or change with Masto.host. The site lets you do a few things like download daily backups for your own safe-keeping, change your plan, and opt to install ElasticSearch for an additional monthly fee.

ElasticSearch lets your Mastodon instance have full-text search for logged in users to search their own posts, bookmarks, favorites, and mentions on your server. I probably would not recommend it if you have the smallest server plan as it can use a good bit of RAM; it's unclear how much RAM your Masto.host server has and how much RAM ElasticSearch is configured to use.

What you can't do

There are a few things you won't be able to do with a setup like Masto.host where you don't have control over the exact configuration. One of these is so-called single user mode. This mode makes the homepage your profile instead of a timeline of users. Typically, you would just update your .env.production file enable it. Though this is a pretty easy thing for Masto.host to build into their web dashboard as a future setting.

Similarly, you can't do a more advanced username where you could have a username like you@example.com even though Mastodon may actually be hosted on a subdomain like you@social.example.com. This is described in the Mastodon documentation as WEB_DOMAIN.

Setting up Mastodon with a regular webhost

Option 2, the not-so-easy way (DigitalOcean VPS)

This section is for people like me that want more control over their server and the software that runs on it, and don't mind a few twists and turns to get there. In this section we'll pick out server hardware and options, create an account to send emails with SMTP, setup media storage with a cloud provider, follow a setup wizard in the command line and then configure a few things.

You should be comfortable with Linux and command line basics for this setup process as well as ongoing server maintence.

Getting an SMTP server

First, we'll need to get access to an SMTP server to let Mastodon send email notifications. While this seems like a step that should be optional, it's required by Mastodon to send emails used to verify new accounts. There are many ways to get access to an SMTP server:

• Setup and configure an MTA like postfix, exim, or sendmail on your server. This is not a particularly easy route. You may still have deliverability issues, or your webhost may restrict SMTP. It's also not advisable to run an SMTP server on the same IP as your web server.

• Use your email provider's SMTP server. If you use GMail (details linked), Outlook, Fastmail or similar email service providers, you can try to just use their SMTP server. This will require you to provide some credentials (either by generating a unique app-specific password, or your email password), and send from the same email address and domain you currently use with your email.

• Use a dedicated SMTP provider like Amazon AWS SES (Simple Email Service), Mailjet, Resend, SendGrid, Mailgun, SMTP2Go, SparkPost, ZeptoMail, Postmark, and many more. I personally use AWS SES and would recommend it if you're already using AWS services in some capacity. Setting up SES is a bit involved though, and you'll be in a sandbox period at first.

While I personally use AWS SES, I was looking for something even easier to setup for this article and after trying a few, had a great experience getting started with Mailjet. By comparison, trying to setup SendGrid was a disaster; way too many steps involved, including having to talk with support.

There's a few steps to follow before you can get your SMTP server login credentials but Mailjet makes it pretty straightforward:

• Sign up for a free account at Mailjet.

• Add your domain as a new sender domain. Click "Setup my SMTP" (or navigate to Sender domains from Account) to add your domain.

• Validate your domain by adding a TXT DNS record. You'll need to log into your DNS provider or domain name registrar to edit that.

• Authenticate the domain by adding 2 TXT DNS records for SPF and DKIM.

• Specify the email address you'll send from and marking it as transactional.

• Get your API key and SMTP server URL. This can be found under "SMTP and SEND API Settings" on the Account page. When setting up Mastodon, the API key will act as your SMTP username and the API secret will act as your password.

Keep your new SMTP credentials handy, you'll need it soon.

Picking your webhost

You can get a Linux server up and running from any number of hosting providers (like AWS EC2 or Lightsail, Linode, Hetzner, DigitalOcean, Vultr, etc) if you're comfortable with the standard Mastodon installation process. If you go this route you'll need to install various system packages, Ruby, Node, Postgres and nginx among others.

However, I'm going to focus on using a DigitalOcean "Droplet" for this article. Mainly because they have a 1-Click Mastodon installer. It saves you a good bit of time but there's still more to do after that I'll walk you through.

Droplets are DigitalOcean's name for their Linux-based virtual machines running on virtualized hardware. They have a good variety of hardware to choose from, including options for faster NVMe SSDs which I really appreciate.

Lets get started! Click "Create Mastodon Droplet" on the 1-click installer page and create an account if you don't have one yet.

Picking your hardware

After logging in you'll be sent to a page to create your new Mastodon droplet and select what hardware to use. How much CPU, RAM and storage space do you need? Storage doesn't really matter as we'll be hosting uploaded media on a separate cloud service. As for storage speed, DigitalOcean droplets only offers SSDs and faster NVMe SSDs; no slower mechanical hard drives. You can opt for the NVMe SSD if you wish (I did) but it's probably overkill for most people just setting up a single-user personal Mastodon instance.

With CPU and RAM, it's definitely a lot of "the more, the better" and whatever you can afford, but here's some additional context to think about it with:

RAM: When it comes to RAM, while you could get by with 1GB, I would say you'd want at least 2GB, especially if you plan to run ElasticSearch on your instance. I ended up going with 4GB and my machine on average consumes about ~2GB of RAM so I have a good amount of headroom.

CPU: CPU is critical to several parts of what run Mastodon like Sidekiq, a background job processor, and Puma, the app server on top of nginx. The more CPU resources you have available, the more processes and threads you can spin up without bogging down your system. With the web server for example, if you increase the number of threads you'll use more CPU, but if you create more processes, you'll use more RAM.

I picked a server with 2 Intel cores and it has been doing fine with my Mastodon activity with about 4,000 Mastodon followers.

After selecting your server hardware, you'll want to select the option to enable monitoring and backups. Then, click "Advanced" and enable IPv6. And finally, you'll need to create or provide an SSH key. I highly recommend following their SSH instructions so you can use a key that your computer has so you can easily access your server with your preferred terminal app. You can still use the web console provided by DigitalOcean but it's a bit clunky.

DB_SSLMODE=require
# You may also need to do the following as a hack
# More context: https://github.com/mastodon/mastodon/discussions/19917
NODE_TLS_REJECT_UNAUTHORIZED=0

Click Create Droplet and your server should be ready in about 30 seconds or so.

Adding your domain & setting up DNS

Next up, we'll need to add your domain name to DigitalOcean and setup necessary DNS records.

• Click the menu on your droplet and select Add a domain.
• Type in the domain you want to use for Mastodon, and select your droplet server from the dropdown.
• If you haven't done so already, you'll want to go to your domain name registrar and designate DigitalOcean as the DNS host by adding the 3 nameservers shown. More info can be found here.
• Finally, you just need to add an A record for your droplet. Just type @ for the Hostname and click the dropdown to select your droplet to automatically select the IP address needed.

After DNS propagates in a few moments you'll be able to directly SSH into your server with just ssh root@yourdomain.com, assuming you setup your SSH key earlier.

Setting up cloud file storage

Before we can start setting up Mastodon, there's one more thing we need to do: setup and get login credentials for cloud object storage for all user-uploaded files on your Mastodon instance. This part is optional: Mastodon can easily host files directly from your server.

However, hosting user-uploaded files on a cloud service instead of your Mastodon server has some benefits. First, it takes the load off your web server to respond to requests for media, freeing up your server to respond to other requests. This is especially important if you have a less powerful server. It's an easy way to make things more performant. Second, cloud object storage providers are made for serving static files quickly and that's especially true if you use one with a CDN.

There are a lot of services to choose from such as DigitalOcean Spaces, Wasabi, Minio, Google Cloud Storage, Amazon S3, and any service that offers S3-compatibility like Cloudflare R2.

I personally use Amazon S3 with a CloudFront distribution (CDN), used on a CNAME subdomain. It was a bit more involved to setup, including creating separate IAM and bucket permissions, so I wanted to show a simpler solution for this article, using DigitalOcean Spaces. If you're familiar with AWS, that's a great route to consider though.

The easiest way is to use DigitalOcean's own object storage solution, Spaces. It costs $5/month for 250GB of storage with 1TB of outbound transfer. That should be more than enough space for most.

To get started, click the Create button at the top of DigialOcean's dashboard and select Spaces to create a bucket for storing your Mastodon server's files. Here you'll need to pick a bucket name and location, which should default to the same region as your droplet server. The bucket name doesn't matter much as it's not readily visible to your users unless they dig into their browser web inspector. You'll also want to check the box to enable CDN.

After you create the bucket you'll need to specify a subdomain to access your files from and setup an SSL certificate so HTTPS will work. DigitalOcean makes this pretty easy. Go to the Settings tab of your new Spaces bucket and click Change → Edit CDN Settings.

Select a subdomain name that you'll use for hosting user-uploaded media on your Mastodon server, like files.yourdomain.com. While this is optional, it's a nice touch. After the certificate is created, the next step is to just select it from the dropdown on the Settings page under CDN as shown below. If you're lost at any point during this process, more details can be found here.

The final step is getting the API key and secret for your new bucket. On the main Spaces page (click Spaces from the sidebar) there is a link at the top right titled Manage keys. Click that and then you can generate a new key and give it a name. Once you're done with that copy your key and secret for use later.

Setting up Mastodon

By this point your DigitalOcean project should look like this: you have a droplet server, a Spaces bucket, and an attached domain.

You're ready to begin the actual Mastodon setup! Mastodon is already installed thanks to the 1-Click Droplet installer. You just need to access the setup wizard via the command line. You can use the built-in console on the website or SSH into it with your preferred terminal app. The website console can be accessed by selecting Access console from the ... menu on your droplet. I prefer directly SSHing into the server with ssh root@yourdomain.com.

When you're connected to your server, you'll instantly see the Mastodon setup wizard start to run:

You'll be asked to answer a few questions and fill in some details and credentials:

• Domain name: Your domain name for Mastodon.

• Do you want to store user-uploaded files on the cloud? (y/N): Type y for yes.

• Provider: Select DigitalOcean Spaces.

• Space name: The bucket name you chose.

• Space region: Type in the region for your spaces bucket. When you go to copy your Spaces endpoint, it'll be the subdomain after your bucket name that's short (like nyc3) depending on the hosting location.

• Space endpoint: Your Spaces "Origin Endpoint" as seen on the DigitalOcean website but with the bucket name subdomain at the front removed. Even though you setup the CDN, for this you need the non-CDN URL or it won't work. For me it was the following but this varies based on the location you chose:

  https://nyc3.digitaloceanspaces.com
  

• Do you want to access the uploaded files from your own domain?: This is asking if you want to use a CNAME alias for your hosted files, for example to appear as if they are hosted from your domain. I'll assume you followed the directions above for setting up Spaces CDN with a subdomain and certificate, so you can say yes.

• SMTP server: Check with your SMTP provider, but in the case of Mailjet it was in-v3.mailjet.com for me. This could be different for you.

• SMTP port: Depends on your SMTP provider, but likely 587.

• SMTP username / password: Provide the username and password for your SMTP provider. If you're using Mailjet as described above the API key will act as your SMTP username and the API secret will act as your password.

• SMTP authentication: The default plain should be fine. You may also be asked for an OpenSSL verify mode, for that you can usually input peer or none.

• Email address to send emails "from": Hit enter to accept the default notifications@yourdomain.com address.

• It is time to create an admin account that you'll be able to use from the browser! Username: Pick the username that you'll want to use for your Mastodon profile.

Your full Mastodon handle will end up being @yourusername@yourdomain.com.

At this point you'll be given a password to log into your new Mastodon account. You'll want to change it to something stronger after you log in for the first time (more on that later). But before that can be done you'll need to follow the instructions to setup your SSL certificate with Let's Encrypt so https will work for your domain.

If you find yourself struggling to get the Let's Encrypt process to work, check the DNS records on your domain to ensure everything is setup correctly, particularly the A record for the domain and that you've correctly added the DigitalOcean nameservers with your registrar. Also, you can just give it some time for DNS to propagate and try again later.

There's just a few more things to do before logging into your new Mastodon server.

Fixing the cloud storage config

Unfortunately I was unable to get DigitalOcean Spaces cloud object storage with CDN working flawlessly out of the gate and had to manually edit a few lines in a config file. We'll be editing the .env.production file—where a lot of Mastodon settings live— to adjust some of the media storage settings.

• If you're using the subdomain as shown during Spaces setup: You'll need to add a line for S3_ALIAS_HOST as shown below. This value is the same as the subdomain you setup earlier along with the SSL certificate. Then you'll need to modify the S3_ENDPOINT and S3_HOSTNAME values to be in this format.

  S3_PROTOCOL=https
  # Replace the following with your bucket name 
  S3_BUCKET=stammy-mastodon
  # Replace with your bucket region
  S3_REGION=nyc3
  # Replace with the subdomain you setup earlier for your Spaces bucket / CDN
  S3_ALIAS_HOST=files.stammy.social
  # Change the region in the URL below to match your bucket region
  S3_ENDPOINT=https://nyc3.digitaloceanspaces.com
  # This is your "Origin Endpoint" as found on your Spaces bucket page
  S3_HOSTNAME=stammy-mastodon.nyc3.digitaloceanspaces.com
  

• If you're not using a subdomain alias for hosting your files: You will need to remove the bucket name from your DigitalOcean Spaces bucket's "Origin Endpoint" that is used as your hostname. Ensure your S3_ENDPOINT and S3_HOSTNAME look like this. Remove any line with S3_ALIAS_HOST if it already exists.

  S3_ENABLED=true
  S3_PROTOCOL=https
  S3_BUCKET=stammy-mastodon
  # Replace nyc3 region in the next 3 lines with your bucket region
  S3_REGION=nyc3
  S3_HOSTNAME=nyc3.digitaloceanspaces.com
  S3_ENDPOINT=https://nyc3.digitaloceanspaces.com
  

• If you used Amazon S3 with CloudFront instead: If you went for the more advanced route of using S3 with a CloudFront distribution connected to a CNAME on your domain, you will configure it like this:

  # Your S3 bucket name. 
  S3_BUCKET=my-mastodon-files
  # Replace us-east-1 with your bucket region, lowercase.
  S3_REGION=us-east-1
  # Hostname is likely your bucket name + .s3.amazonaws.com
  S3_HOSTNAME=my-mastodon-files.s3.amazonaws.com
  # Only use if you've configured a CloudFront CNAME on your domain with SSL cert 
  # If you're not using a CNAME, remove this line and then change the S3_HOSTNAME to the default (such as s3.us-east-1.amazonaws.com based on your region)
  S3_ALIAS_HOST=turbo.stammy.design
  # You do not need an S3_ENDPOINT line
  

Once you've made the changes to your .env.production file, you'll need to restart the Mastodon services to apply the changes:

sudo systemctl restart mastodon-*.service

Upgrading your Mastodon account privileges

By default your new Mastodon account does not have all privileges available. Mastodon allows an account to have roles like Moderator, Admin, and Owner. You'll want to modify your account to have the Owner role. This can be done using the admin CLI tool called tootctl.

Connect to your server via SSH again (or DigitalOcean's web console) and run the following commands:

# Change from the root user to the mastodon user 
sudo su - mastodon 
# Change to the Mastodon bin directory 
cd /home/mastodon/live/bin
# Modify your account to have the Owner role
RAILS_ENV=production ./tootctl accounts modify admin --role Owner

This may take a few seconds then you should see "OK". If you have any issues, or are using a different webhost, just confirm that you're in the right directory. If you have an error running this and happen to be using the DigitalOcean managed database, you may need to configure the database in another file. Read the managed database section for details.

Enabling single user mode

If this Mastodon account is for you and you only, you can enable single user mode to have the Mastodon homepage be a profile view of your account. By default, this is not enabled and the Mastodon homepage is a timeline view.

To enable this, you'll need to edit .env.production and then restart the web server.

# Change from the root user to the mastodon user 
sudo su - mastodon 
# Change to the Mastodon web directory 
cd /home/mastodon/live
# Edit the .env.production file in Vim
vim .env.production

Now you'll need to create a new line anywhere in the file by moving the cursor with the arrow keys, tapping i to enter Insert mode, creating a new line, then typing in the following line:

SINGLE_USER_MODE=true

Tap ESC to exit insert mode, and then type :wq and hit enter to save and exit vim. And finally, exit mastodon user mode to go back to root by typing exit, and then restart the web server:

# Restart the web server, this can take a few seconds
systemctl restart mastodon-web.service

Ensuring your SSL cert will auto-renew without issue

Mastodon uses the popular certbot tool from the EFF to obtain certs from Let's Encrypt and enable HTTPS on your server. That part all worked great during the initial setup. Certificates from Let's Encrypt last for 90 days before they need to be renewed. Certbot makes them easy to auto-renew: it should have installed a cron with it either in a systemd certbot.timer (see it with systemctl show certbot.timer if you're curious) or in /etc/cron.d/certbot.

You'll need to ensure that your cert will auto-renew without issue. Shouldn't this work out of the box? It should, yes. However, I began poking around in my setup and noticed a configuration issue by default (not sure if this is a DigitalOcean Mastodon installer issue or a Mastodon issue) that would lead to renewal failing.

The default method used is called standalone mode and it only works when the web server is not running, which won't happen during auto-renewal unless you setup your own cron that also stops and starts the server for renewal. This is fine for the initial setup, but if you want to auto-renew your cert, you'll need to use a different method. For more context on this issue, see this commit has updated installation instructions that were never merged to Mastodon main, and this issue.

First, see if you'll even have an issue by doing a dry run invocation of the certbot renew command:

sudo certbot renew --dry-run

If the dry run says the renewal would be successful, you don't need to do anything else and your setup is all good. If it says renewal will fail, you likely need to do the following:

# Edit this config file, swapping out example.com for your domain 
vim /etc/letsencrypt/renewal/example.com.conf

Then find the line that says authenticator = standalone and replace it with these two lines below and save the file.

authenticator = nginx
installer = nginx

Now you can do a dry run again and it should say the renewal would be successful as shown below:

Final setup: updating packages, enabling the firewall, etc..

At this point you could skip ahead and check that Mastodon works and log into your account for the first time, but you'll need to come back to complete a few more things. For the most part you just need to follow this Mastodon guide where you'll update system packages, configure fail2ban to block repeated login attempts and setup a firewall.

The DigitalOcean website has its own interface for configuring a firewall but after repeated attempts I was unable to get it working, so I stuck with the route recommended by Mastodon: iptables.

Optional: Configure IPv6

During DigitalOcean droplet setup you checked a box to enable IPv6 connectivity for your server. Even though that is enabled, you will need to edit some files and add a DNS record. Follow this DigitalOcean guide.

Then you'll need to add an AAAA DNS record to your domain. An AAAA record is like an A record that points to your server, but for IPv6. DigitalOcean should automatically show you your server's IPv6 address in a dropdown when creating that record.

Optional: Setting up automatic database backups

If you opted not to go for the DigitalOcean managed database upgrade, you'll want to a way to export and save backups of your database on a recurring basis. The easiest way to do this is to setup a cronjob that runs a script to dump your database, zip it up, and save it to a cloud storage bucket with the Amazon AWS command line interface. Since we already setup Spaces for cloud object storage, we can re-use that to save your database backups, though if you want to spend the extra time to use a separate cloud provider or bucket for saving only backups, that is preferrable.

First, you'll need to install the AWS CLI. You could follow this guide to install the AWS CLI, but likely you can just install it with: apt:

# Run as root 
apt install awscli
# Provide your credentials for your Spaces bucket, api key and secret when prompted 
aws configure 
# Switch to the Mastodon user
sudo su - mastodon 
# Test to see that it works by listing what's in your Spaces bucket 
# Note: you need to replace the region with your region if different 
# Any time you interact with the AWS CLI, you need to use the --endpoint-url option to 
# specify that we are using DigitalOcean Spaces, not Amazon S3
aws --endpoint-url https://nyc3.digitaloceanspaces.com s3 ls

cd /home/mastodon

# Now we'll create the script to backup the database
vim backup_database.sh

Tap i to enter Insert mode in vim, and paste the following, replacing the Spaces region in the endpoint URL with your Spaces region code:

#!/bin/bash

# Create a filename with the date and time
FILENAME=mastodon_production_$(date +%Y%m%d%H%M).gz

# Dump the database, gzip it, and save locally 
pg_dump mastodon_production | gzip > ${FILENAME}

# Upload the file to your Spaces bucket
# Important: Replace the region with your region if different
# Important: Replace the bucket name 'stammy-mastodon' with your bucket name
aws --endpoint-url https://nyc3.digitaloceanspaces.com s3 cp ${FILENAME} s3://stammy-mastodon/backups/

# Delete the local file
rm ${FILENAME}

Save the script (Tap ESC to exit insert mode, type :wq, hit Enter), then made it executable:

chmod +x backup_database.sh

Now we'll create a cronjob to run the script every day:

# Enter cron job editor. If you're asked what editor to use, select vim again.
crontab -e

Create a new line after the comment block at the time, and enter the following to create a database backup every week. If you want more frequent backups, you can customize it to your liking, such as with 0 0 */3 * * for every 3 days. Take a look at crontab.guru to help you figure out what values to input.

# Backup every week
@weekly ./backup_database.sh

Save the file and you should be good. You may want to try manually running the script now (./backup_database.sh) to ensure it works, and check your Spaces bucket to see a new file was added to the backups directory.

Optional: Install ElasticSearch

If you want the ability for you and your Mastodon instance users to be able to search their own posts, bookmarks, favorites, and mentions, you'll need to install ElasticSearch. This is optional because it's really not that useful. You cannot search across instances, and it does not even support showing posts from other people on other servers that your server has seen but that do not mention you, even if you follow them.

It also takes a bit of RAM, so I especially would not recommend install ElasticSearch if you only have 2GB of RAM or less server. It can be done, but I don't think it's worth it.

To install ElasticSearch, you can follow these instructions from the Mastodon site. However, when you get to the part of the guide that tries to enable the service, you may see this error:

Job for elasticsearch.service failed because a fatal signal was delivered to the control processed

This is likely to happen if your machine doesn't have enough RAM. By default ElasticSearch tries to take a lot of RAM, so you'll want to configure it to use less. For example, if you only wanted it to use 512MB of RAM, you can create a new file memory.options:

# Create an elastic search config file to limit memory usage
vim /etc/elasticsearch/jvm.options.d/memory.options

Then enter these two lines to specify a min and max amount of RAM that ElasticSearch can use. For example, a min of 256MB and max of 512MB:

-Xms256m
-Xmx512m

Save the file and try to start the service again:

systemctl daemon-reload
systemctl enable --now elasticsearch

Run the rest of the steps mentioned in the guide and you should have functional search on your instance. You may run into one more issue resulting in a security warning. This github thread is helpful for resolving that (though I think it was also fixed recently in Mastodon 4.1.0).If you want to go down the rabbithole you can modify more security settings but it's likely not a huge deal as we'll be setting up a firewall that won't allow port access to ElasticSearch.

Logging into Mastodon

Changing settings, configuring scripts & testing

If you used a fully-managed host like Masto.host (mentioned earlier), you've already created an account and logged in. If you've followed the guide for creating your own server for Mastodon, then you were given a temporary password to login with. Now it's time to visit your website and sign into Mastodon. You'll also want to immediately enable two-factor auth.

After signing in, click Preferences in the sidebar. The first thing we want to do is confirm that upgrading your account to the owner role actually worked. You should see a tab for Administration along with others like Sidekiq and PgHero. It should look like this:

Feel free to browse the Profile tab to fill out your bio and related settings. Importantly, I think "Require follow requests" may be on by default which you probably want to disable.

Next, here's a few things to setup:

Fill out server details

Administration → Server Settings → Branding: Fill out the name and description for your server. This is displayed alongside your profile, homepage, and posts so it's quite visible. You can also specify an image to display there.

Disable new account creation

Administration → Server Settings → Registrations: If this server is just for you, you'll want to disable account creation by changing the Who can sign-up setting to nobody.

Disable unauthenticated access to public timelines

Administration → Server Settings → Discovery: This is just a preference but since this is my own server, I only want my posts easily accessible. I wanted to disable the /public (the "Federated" tab) timeline which displayed posts from other people. I'm also a little concerned about liability related to my server hosting content from other people (as mentioned in my last Mastodon post) so making those posts harder to find seems best.

As such, I unchecked Allow unauthenticated access to public timelines.

Adjust media and content retention

Administration → Server Settings → Content retention: This page has some important settings that control how much media and content is kept on your server. If you follow or interact with lots of people on Mastodon (or have any relays setup), you will see the size and costs associated with your cloud object storage provider rise.

You change safely set the media cache retention period to something like 7-30 days. I went with 7 and haven't noticed any odd behavior. This will delete downloaded media files (from other servers, stored on your server or cloud storage) after the specified period. If your server requests the media again, it will be re-downloaded so there's no real harm in setting it too low, you can always change it.

The other setting content cache retention period is a bit less safe to tinker with and will delete posts from other users on your server. I decided not to touch this and will see if I need to change it if my database grows too large over time.

Setting up a cron job for periodic cleanup tasks

The media retention setting in the admin interface is just one setting. You have far more control at your disposal with the tootctl admin command in the command line. In fact, running these commands regularly is a recommend part of setup, mentioned under periodic cleanup tasks.

For this, I have several of the commands running as a cronjob. I put them in a bash script for a cronjob to run. I could have put them directly in the crontab editor as a weekly task but it's easier to keep it in one file where I know it will run serially, without having to specify different run times for each job so they don't run at the same time, potentially bogging down your server.

Here's a list of the commands I run regularly. I put them in a bash script named cleanup.sh that I store in my home directory /home/mastodon:

# This does the heavy lifting and removes locally cached copies of media attachments from other servers
# By default its set to delete media older than 7 days. 
# Adjust days with --days, eg --days 3 for a more aggressive setting
RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove

# Remove local thumbnails for preview cards (the thumbnail when links are shared, etc)
# The default is 180 days and under 14 days is not recommended as they will not be refetched
RAILS_ENV=production /home/mastodon/live/bin/tootctl preview_cards remove --days 60

# Deletes remote accounts that never interacted with local accounts 
# Removes many avatar and header images as part of this
RAILS_ENV=production /home/mastodon/live/bin/tootctl accounts prune

# Removes files that do not belong to existing media attachments 
# For example if you attached a file to a post composer but never posted it
# This command and the one after it are slow to run, so I like to keep them for last
RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove-orphans

# Remove unreferenced statuses from the database, such as statuses that 
# came from relays or from users who are no longer followed by any local accounts, 
# and have not been replied to or otherwise interacted with
RAILS_ENV=production /home/mastodon/live/bin/tootctl statuses remove

# Switch to the mastodon user and home directory 
sudo su - mastodon
# Create bash script 
vim cleanup.sh
# Make the script executable
chmod +x cleanup.sh
# Add the bash script to crontab
crontab -e

In crontab, add this line and then save:

@weekly ./cleanup.sh

I set it to run weekly but you may prefer to run it more often. I've been running my own Mastodon server for a month now and with this setup my cloud media storage is only at 8.5GB with my usage.

Use custom CSS to hide or modify things

Administration → Server Settings → Appearance: This part is completely optional but I found myself wanting to hide certain parts of the site navigation that aren't useful to others as my Mastodon server is only for me. I hid the sign in buttons for logged out users. I hid the "Local" tab for me when logged in: useless for me as I'm the only account on the server. I also hid the "Learn more" button that shows up next to the server details (felt pretty obvious that the server was just for me and I wanted to simplify things a bit).

// hide sign in buttons (you'll have to manually visit /auth/sign_in)
.navigation-panel .navigation-panel__sign-in-banner, 
.ui__header__links a[href="/auth/sign_in"],
.ui__header__links button { display: none !important; }

// Hide the "Local" tab for logged in users (only do this if you're the only user on the server)
.navigation-panel a[href="/public/local"] { display: none !important; }

// hide server details "Learn more" button
.server-banner .button { display: none !important; }

Bonus: Clean up the admin UI with an Arc Boost

If you're running this Mastodon account for you, and you only, you may find the default admin dashboard has a lot of space taken up by useless information, such as showing you the number of new accounts created. I prefer to keep some of that hidden to clean up this page.

Unfortunately, just adding CSS to hide it as in the previous step does not seem to work for admin pages. So I turned to a feature from my browser, Arc, called Boosts. It's an easy way to locally inject CSS (or JS as needed) into any website. Other browsers have similar ways of doing things with extensions. I created an Arc Boost to simply hide a few dashboard modules:

# Not pretty, but it does the job
.dashboard .dashboard__item { display: none; }

.dashboard .dashboard__item:nth-child(3), 
.dashboard .dashboard__item:nth-child(9) { display: block; grid-column: span 3; }

.dashboard .dashboard__item:nth-child(12),
.dashboard .dashboard__item:nth-child(13) { display: block; }

Try posting an image

And one last thing you'll want to do is try posting with an image attached. This will confirm your cloud object storage configuration works correctly and that your system can resize images. What you'll want to look out for is that dragging an image into the post composer shows a thumbnail preview, and osting it shows the image without requiring you to refresh the page.

Migrating your account

If you have an existing Mastodon account on another server

Now you're ready for the fun part: moving your existing Mastodon account over to your new server, along with your followers. Mastodon does a great job with this and while it's not perfect for reasons I'll mention below, your followers will automatically move with you. You can read a bit about the process from the Mastodon documentation, but it unfortunately does not go into much detail.

Here are the key things to know about migrating your account:

• Your posts don't move with you. Posts on your existing Mastodon account do not move with you to the new server. This is unfortunate, but likely a product of how the federation is done (every server that interacted with your posts would have to update). If you only care about the content of your posts and not the engagement around them, you could repost them one by one to your new server (before you do the migration), and edit the date in the database to the original date. But that's weekend project territory to write a script to do that for you... I digress.

• Your followers move with you. Your followers will get transferred pretty immediately. When I migrated my account, all of my ~3,000 followers were moved within a day with maybe 75% in the first few hours. It's not entirely flawless though, I did lose about 20 followers in the process.

• You have to manually re-follow accounts you follow. You have to export a CSV file of accounts you follow from the old server and upload that on the new server. It's really easy, but it does mean that people you follow will receive a notification that you followed them. It's not ideal but people will start poking around and realize you just moved servers. I've noticed it dozens of times with people I follow and quickly pieced it together.

• Your old profile shows a banner that you've moved to another server. And your old account will be in a locked down state. You can login but you can't post or edit anything aside from exporting data from the preferences page.

• You can't migrate your account again for 30 days. So make sure you're using a username and domain you like.

Lets get started! The actual first step is creating an account on your new server, which you've already done.

Step 1: Create an account alias on the new server

Setting up a Mastodon account migration is a two-way process. The new server needs to be aware of the old account, and the old server needs to send everything to the new server that's expecting it.

So the first step is to log into your new server, open Preferences → Profile and click on the link under "Moving from a different account." On this page you need to provide your old Mastodon account in the format myusername@example.com.

This step is harmless and reversible—the actual migration does not start until the later steps.

Step 2: Export your account data from the old server

Next, you'll want to export data from the old server. Most importantly, you'll want to export a CSV of accounts you follow so you can later import this on the new server. You can also export files for your muted accounts, blocked accounts, bookmarks, lists, and blocked domains. Go to your old server to download these files: Preferences → Import and Export → Data export.

On this page you can also request an export of your posts and uploaded media from the old server. This is just for you to have as you can't import posts on the new server. Also, it may not work you depending on your old server. I've tried to request my archive on my old server numerous times and it never generated a download for me.

Step 3: Begin the migration on the old server

Now it's time for the actual migration. This will move followers from your old account to your new account. This cannot be undone, so be sure you're ready and have setup your server to your liking before proceeding. This is also a good time to edit anything on your old account (edit bio, delete any posts, etc) as you won't be able to change it later.

On the old server, go to Preferences → Profile → Move to a different account and click the link mentioned. This will take you to the account migration page. Carefully read the bulleted list to understand the implications of this move. Then, enter your new account's handle and the password used for your old server.

Now the migration will start. As mentioned earlier, your posts will not move to the new server, only your followers.

If you have a lot of followers or a particularly low-end server, it may be a good idea to keep an eye on your server as this migration process will keep it busy for a while. You can take a look at system resources with the top or htop commands.

And you can see what Mastodon is doing by looking at the Sidekiq dashboard, accessible in Preferences → Sidekiq. You can click around to see what jobs are running or failing. For the most part you don't need to worry too much. Common job failures are often related to other instances having timeouts. The only cause for concern would be an error indicating connectivity issues with your database, which could mean you may want to adjust the Sidekiq concurrency (mentioned a bit later) in /etc/systemd/system/mastodon-sidekiq.service.

Step 4: Import your following list

The last step of the migration process is to import the CSV files you exported in step 2, the most important of which is the list of accounts you follow. On your new server go to Preferences → Import and export → Import. Select what type of CSV file you're importing in the dropdown, select the CSV file and upload.

You can safely import all lists except the following list before you've actually started your migration (step 3) if you wish.

I recommend waiting a while after step 3 has had time to move most of your followers over before importing your following list. Your server may be quite busy with step 3 so it doesn't hurt to do this an hour later.

That's it! All of your followers should get moved over shortly and you're ready to start using your own Mastodon server. It's probably a good idea to have a post or two so your followers don't see an empty profile if they happen to venture to your profile.

If you want to have a bit of fun, you can start looking into adding custom emojis (sometimes called emojos in the context of Mastodon) to your server. Take a look at Preferences → Administration → Custom emojis. where you can upload an image and assign it a shortcode. You can even use them in your username.

What to expect

Missing some posts and replies? Yeah, that's normal...

After you've had some time to use your new server, you may see some odd behavior that may lead you to something is broken with your server. Profile pages for accounts may be almost entirely empty, or only have a few posts. Post detail views may not have all the engagement or replies you might expect compared to visiting the original post URL on the remote server.

I'm just here to tell you this is normal. It's not a good thing, but it's the current state of how Mastodon works.

Missing posts on a profile: When you follow someone on your server, or visit the profile of someone you don't follow, Mastodon does not go and fetch all of their posts. That would be taxing on their server and yours. So what happens instead is you get some basic profile info, a post or two (pinned ones) and that's it. Then, the next time your server sees a post from this user (because you follow them or other some action lead to your server seeing this post), it will then appear on their profile. This is not ideal and it wouldn't be unreasonable for Mastodon to fetch a few more posts with a way to request them on demand.

This will get a bit better over time. Your server is brand new, you only just followed accounts and your server has yet to see a lot of new posts and fill up profiles with new posts going forward. You'll still stumble across a user account that your server has never seen before an experience the same blank profile behavior but at least now you know why that is.

Missing replies on posts from other accounts (not your own posts) is a similar situation; your server may have low federation and not be aware of some of those replies. Understanding why this is the case ends up going down a rabbithole of understanding federation more and how your server even comes to know about posts, and under what conditions another server sends a post to your server.

This Mastodon GitHub issue outlines the situations where your server comes to know about posts:

• Someone on your instance follows the person who posted, at the time it was posted
• Someone you (or anyone else on your instance) follow boosts or replies to that toot
• Under some conditions, if that post was a reply to someone you (or anyone else on your instance) follow
• The post mentions anyone on your instance
• The post was a pinned post when the account was discovered by your instance
• Someone on your instance manually fetches a post by pasting the URL in the search bar

This is a hot topic these days and I've seen discussions happening around people wanting to add buttons in Mastodon clients to explicitly load all replies on a post, or older posts on a profile, from the remote servers. There's various technical issues with some of these routes, but I'm curious to see if this situation evolves as I for one would love a refined experience here.

Maintaining, debugging, and optimizing your server

A few things to be aware of

This section is for people running their own server, not through a fully-managed host like Masto.host.

Updating Mastodon

You'll need to keep up to date with Mastodon updates to get new features, performance and security updates. You can check for new updates on the GitHub project page but it's probably easiest to subscribe to the atom feed in your news reader of choice, such as NetNewsWire.app. Here's the releases feed, or the website if you prefer.

The steps you need to follow for each update may vary, but additional steps will be mentioned in the release notes for each release. Generally you'll need to SSH into your server, fetch the latest release with git, and restart some services. Find the complete steps here: Upgrading to a new release.

You should check now that your server is on the latest Mastodon version. At the time of this writing, the DigitalOcean 1-click installer is running an outdated version.

Updating your Ubuntu server

Along with maintaining and keeping Mastodon up to date, you'll want to do the same with your server. If you followed along with the DigitalOcean route explained above, your machine uses Ubuntu OS, apt package manager and has a specific package called unattended-upgrades installed by default. That package will automatically install essential security updates, but you can modify it to update even more.

I don't want to get too in the weeds about linux server maintenance as everyone seems to have their own specific practice about when to update things, how to update them, and when to leave it alone.. you know, if it ain't broke don't fix it. Some people may prefer to update all packages every week. Not including security essentials, that's a bit too much for me and feels like I'd constantly be signing up for a potential debugging session if anything unexpected happens.

Personally, I just update available packages whenever I get around to it, perhaps every month or two. Usually with these:

# Refresh list of available updates 
sudo apt update
# View list of available upgradable updates
apt list --upgradable
# Upgrade packages 
sudo apt upgrade
# Remove unneeded packages not installed by you 
sudo apt autoremove

# Alternatively, instead of the lines above:
sudo apt update && sudo apt upgrade –y && sudo apt autoremove -y

When things go wrong

I wanted to provide a few pointers for things to look into when things go wrong with your Mastodon server. There's no way I can provide a general solution to what could be a specific problem you may encounter, but here's a few things may be a good place to start:

• Check service status: Run this to get a quick look at the core Mastodon services: mastodon-web.service, mastodon-sidekiq.service, and mastodon-streaming.service.

  sudo systemctl status mastodon-*
  

  In addition to status of the 3 core Mastodon services (you'll want to see "active (running)" in green), this command will show the last 10 lines from the logs for each service.

• Check the logs: This may sound obvious but knowing how to check and work with logs is critical. It's the best way to know what's going on with your machine. To access any of the logs for the aforementioned 3 services, we use a tool called journalctl to read and filter system logs that are saved in the binary "journal" by systemd. You can always run man journalctl to see more details on how you can use it; it's very powerful.

  It's a good idea to go through the logs for each Mastodon service after you've set everything up to make sure that things are working smoothly. Here's a few examples of how you can use it:

  # Show the last 50 lines of the mastodon-web log
  # and keep showing new lines as they come in (that's the -f follow flag)
  sudo journalctl -u mastodon-web -n 50 -f
  
  # Or read the mastodon-streaming log 
  sudo journalctl -u mastodon-streaming -n 50 -f
  
  # Or the mastodon-sidekiq log 
  sudo journalctl -u mastodon-sidekiq -n 50 -f
  
  # Or only show me sidekiq logs that have priority level 4 (warn) or higher
  sudo journalctl -u mastodon-sidekiq -f -n 100 -p 4
  
  # And you can always pipe it to grep
  # For example to show any lines from the web logs that have a status code of 500
  sudo journalctl -f -u mastodon-web -n 500 | grep "status=500"
  

  You can do a lot with these commands. This helped me initially discover database connection issues when I over-eagerly tried to optimize configs, and helped me notice that I forgot to require SSL for my remote database.

• Restart things: You can restart or reload (like a restart but no downtime as it reloads the config, if supported by the service) these services with a command like:

  sudo systemctl restart mastodon-web
  

• Check sidekiq: Sidekiq is the background job processor for Mastodon. It's how Mastodon manages receiving new posts, sends our your posts, and more.

  Generally you don't need to worry too much about what it's doing, but there's one key scenerio to be aware of: if you have a massive queue of jobs that are piling up. What this looks like is the "Enqueued" tab in the Sidekiq dashboard will show a large number that's not going down in a reasonable amount of time.

  This would mean your machine cannot keep up. You may notice significant delays in receiving new posts on your server. A Mastodon instance running well would have likely have few to no tasks busy or queued, and when when queued tasks are added, they get processed quickly. If this happens to you, it could mean your server is underpowered and trying to do too much (don't use any relays if you are), or could benefit from optimizing your sidekiq setup (more later).

  There's also a tab for dead jobs in Sidekiq. These are tasks that have failed repeatedly and will not be retried. You'll just want to glance at those to ensure the issues are not related to you. Even if some jobs fail, you'll likely see that they are HTTP connection or timeout errors with other servers and likely not your issue.

Optional: Extend your post character limit beyond 500

It's your server, you control the code so why not extend your server's character limit well past the default limit of 500 characters? Doing this will take just a few minutes, all you have to do is change a number in 2 files, precompile assets, and then restart some services.

This article goes into detail about the process: Customize Mastodon to Change Your Post Character Limit. However, keep in mind that you'll have to reapply these changes with every Mastodon update.

I changed my character limit to 15,000. In reality I won't be posting things that long, though I did take advantage of a 1,000 character reply which was very handy and I didn't have to try to split it up into multiple replies or aggressively truncate my thoughts. The change works seamlessly: people on other Mastodon (or other ActivityPub software) servers will see the longer posts, and all Mastodon clients should see the updated limit in their post composer interfaces.

Optional: Change your join date

One annoying thing of creating a new Mastodon server, or migrating to a new one, is that your join date—shown prominently on your profile—reflects the date you created the new account. It doesn't inherit the date of your previous account(s) that you migrated.

Since you're running your own server and have access to the database, the join date is easy to change. You can change it to your original account creation date, or any date you like. Why not? It's your server, do with it what you want. SSH into your server, or use the web console from your hosting provider and run the following commands:

sudo su - mastodon 

# Enter PostgreSQL interactive terminal for the Mastodon database
psql -d mastodon_production

# Update the join date for your account...
# Replace YOUR_USERNAME with your username (does not include domain name)
# Replace date with your desired date, using the exact same format 
UPDATE accounts SET created_at='2018-01-01 00:00:00' where username='YOUR_USERNAME';

# Exit the PostgreSQL interactive terminal
exit

Optimizing Mastodon for your server

Proceed at your own risk

If you're just running your own single-user Mastodon instance that you expect to be low traffic, you don't need to touch anything in this section; the defaults are fine for your system. But if you have a beefy server with extra RAM and cores to put to use, you have a lot of followers, and/or you just generally want to nerd out on squeezing more performance from your server then read ahead.

As a word of caution, changing things in various Mastodon config files can easily take your server offline. I recommend doing this before you've done a migration, or late at night to minimize the effects of downtime. Also, I highly recommend setting up Rewind AI on your Mac so you can easily retrace your steps when you're changing things and running commands.

By following this guide, you've already done an important performance tweak: using a cloud object storage solution for hosting all media for your Mastodon posts. The most common things advanced users will do includes modifying sidekiq to use separate processes for each queue, as well as setting up pgbouncer for PostgresSQL.

Resources

Scaling Mastodon can be a deep topic depending on your needs. I'm only concerned with running Mastodon as a single-user instance, but it's helpful to better understand the pieces of Mastodon and what can and should be changed and when.

The Mastodon website has a page about scaling your server. It's particularly good to learn the relationship between threads and processes with the web server (threads max out your CPU first, processes max out your RAM first), as well as learning about pgbouncer to help reduce any database connection bottlenecks.

Then there's the lengthy and advanced article Scaling Mastodon: The Compendium. Most of the topics in there might be a bit overkill for a small single-user instance though.

Sidekiq

I mentioned a bit about what to be on the lookout for with sidekiq earlier in this article, such as having a backed up queue. The first thing I did with sidekiq is slightly increase the number of threads. By default using the DigitalOcean droplet, you may have a default of 25 for DB_POOL and the concurrency flag -c.

However, the number of max_connections for the Postgres database by default is 100. Counterintuitely, if you opted for a separate managed database from DigitalOcean you may have only 25 database connections available, in which case you may opt to setup their pgbouncer feature called "connection pools"; that's what I did. If you do the same, you'll need to change your database connection info so Mastodon connects to pgbouncer on a different port.

What I did was edit /etc/systemd/system/mastodon-sidekiq.service and change the DB_POOL value to 50, as well as the number after -c on the ExecStart line. You don't want to tell sidekiq to consume all of our available database connections as each Puma web server thread will need a database connection too.

Environment="RAILS_ENV=production"
# Edit this 
Environment="DB_POOL=50"
Environment="MALLOC_ARENA_MAX=2"
Environment="LD_PRELOAD=libjemalloc.so"
# and the number after -c 
ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 50

Then I also configured sidekiq to automatically restart every 6 hours. There seems to be an open issue where sidekiq memory usage continually creeps up over time. Honestly, this was one of the firs things I configured and never ran without this setting so I'm not entirely sure how necessary it is. But I haven't had any issues.

Restart=always
RuntimeMaxSec=21600

After modifying mastodon-sidekiq.service, you'll need to run these:

systemctl daemon-reload
systemctl restart mastodon-sidekiq.service

Puma

The other thing I did was adjust the number of threads and proccesses used by puma, the Mastodon web/app server. If you expect a lot of web traffic, or just like to be prepared, you may be interested in tweaking puma as well.

I initially looked into this because had some unused RAM on my server and wanted to let puma use a bit more. In the process I learned that the it's recommended to allocate 1.5 processes per CPU core. So my server has 2 cores, so I can get away with 3 processes for puma. I set it to also use 10 threads per process.

Edit /etc/systemd/system/mastodon-web.service and add these two lines (or modify if they already exist):

# Set this to 1.5 * number of cpu cores
# Find your # of cores by running: cat /proc/cpuinfo | grep processor | wc -l
Environment="WEB_CONCURRENCY=3"
# The number of threads per process. If you're RAM constrained, you may want to lower this.
Environment="MAX_THREADS=10"

Save the file and restart the service:

systemctl daemon-reload
systemctl restart mastodon-web.service

That being said, you don't really need to mess with puma much. For a single user instance the vast majority of your traffic will be from people interacting with your posts via a Mastodon app/client through their server—not directly via your website—which is not served by the web service.

This is barely scratching the surface with what's possible for optimizing and scaling Mastodon. I'm just running my own single-user instance and it's been running great so far. If you're not sure what to do, I would recommend not touching anything and seeing how your server works for a while. You can keep an eye on system logs as mentioned earlier, as well as sidekiq.

The end

This article has been in the works for a while now but hopefully it has helped you get a better understanding what's involved with hosting your own Mastodon server, how to keep it running smoothly, and how to tweak it to your liking.

It's a bit of work to get running but the benefits of owning your online identity and data with Mastodon are well worth it. If you've enjoyed this article, please share it with anyone that might find it useful, and of course follow me on Mastodon on my new instance: @stammy@stammy.design.

I first wrote about Twitter (née twttr) just over 16 years ago. Over the years, Twitter’s place and impact in the world has become clear. It’s not just a place to hear about breaking news, keep up with celebrities or see what your politicians are saying. It’s a place where communities are formed and thrive. It is the global town square.

But that’s all been changing daily ever since Elon Musk took over. This has become the tipping point for many to reconsider their reliance on big tech companies with closed platforms and to be in control of their data. This whole Twitter/Elon saga sucks, but maybe it’s just the kick we needed.

And with that, I’m starting to spend more time on Mastodon, and I’ll tell you why. Follow me on Mastodon: @stammy@stammy.design (you’ll have to search for it on your Mastodon server).

Part 2: Hosting your own Mastodon server

Want to have complete control and host your own Mastodon server?

Shortly after I wrote this post, I loved Mastodon so much I decided to host my own server and document the process for those that would want to do the same. In Hosting your own Mastodon server I show two ways to host your own server (using a fully-managed Mastodon host, and using a VPS provider). I go into everything from scripts to backup your database and run media clean up tasks, to advanced settings to optimize your server, and much more.

Twitter quickly became a core part of how I used the internet, made friends, learned things, kept up with the world, killed time, and so much more. I eventually went to work at Twitter for nine years. Twitter, the company, had lots of ups and downs, but the people behind it cared so much about the platform and its place in the world. It’s the critical conversational layer of the internet. Creators have active social media accounts elsewhere online, but they always relied on Twitter to truly connect and have conversations with their community. It was the vital hub.

Well, it’s a different bird site now. I don’t intend to summarize the series of events and drama that have unfolded ever since Elon Musk took over Twitter, nor do I have the energy for that, but if you’ve seen even a portion of all the headlines, you get where I’m coming from.

Seeing the company's culture get slaughtered so quickly was hard. It was a culture woven around caring for coworkers, caring for people that used Twitter, and caring about the good of the service.

A few weeks ago was the last straw for me. Reputable accounts were randomly banned, and Twitter announced that people could no longer Tweet links to other social networks that were deemed competitive. Then more people were banned for saying they were leaving. And then, suddenly, this big policy suddenly vanished.

I lost a lot of hope and confidence in Twitter and how it is being run. I still think Twitter will be around for some time, but I’m not sure how much I want to continue investing in it as much as I used to.

I had seen some folks migrating away to alternate services in recent months but didn’t think much of it. Twitter was here to stay, right?

Fool me once...

The Twitter/Elon saga has a silver lining that I can appreciate. It shows us that we’ve all become too comfortable with just a few large tech companies amassing our info, controlling our data, and what we do with it.

If you’re the typical user of internet services from large companies, you probably haven’t had too many issues. Sure, maybe you got locked out of your Google account once, and it took a long time for support to help you out, but for the most part, you didn’t have to think about it. The big companies were mostly staying in their lane and not doing anything too egregious (aside from miscellaneous privacy dramas). But they could have been.

This Twitter drama is a perfect example of what can go wrong and how quickly it can go wrong. It’s too much. I’ve invested a lot of time into Twitter (thanks to the 53,000+ of you that have been following me there).

I no doubt expect Elon to reverse some of his decisions from the regular backlash from users and press, but there’s no trust anymore. Even if a new CEO or a new owner is announced, I don’t know if Twitter can ever be truly trusted again. Fool me once, shame on you, fool me twice, shame on me..

All this to say, I think it’s time we take more control of our data. I’ve been trying to reduce my reliance on Google accounts and services already. I’m sure I end up moving on to Proton or elsewhere in 2023.

This does all make me a tad nostalgic for the early 2000s. We were all just running our own little blogs in a corner of the internet and keeping up with each other with RSS readers. Social media was just our own little websites. Why can’t we just go back to that?

Mastodon

A decentralized social network built on an open protocol

I’ve started spending more time on Mastodon, open-source software for running a decentralized social networking service that’s not somewhat similar to Twitter. It’s decentralized in that there’s no single website or company running the show. It’s not a single platform.

Instead, Mastodon is comprised of a network of independent servers, which you may see referred to as Mastodon instances. Each server is run by a different person that manages and moderates it. You can sign up for an account on any server you want, and you can follow people on any other server just like you would on Twitter. (There are exceptions, like if one server blocks another server—defederation).

Mastodon was first released in late 2016 by Eugen Rochko, who wanted to create a platform not controlled by a single company or person. Mastodon was developed as a non-profit, and the platform is ad-free. It has made specific design choices to reduce harassment and give users more control over their experience and create a safer environment.

As a long-time Twitter employee, I had heard of Mastodon many times (as well as a predecessor, diaspora) but never took much time to dive deeper. It always felt like a rudimentary platform 10 years behind Twitter. In hindsight, it was foolish to think of it in terms of features rather than protocols. That was the real innovation with Mastodon, not whether it had certain product features.

Mastodon servers communicate with each other with open-source software using a standardized, open protocol called ActivityPub for sharing updates. There are quite a few other open-source projects using ActivityPub, such as Pixelfed and Pleroma, but Mastodon is the most popular. You can even run your own Mastodon instance all by yourself if you want.

You may also see it referred to as a federated social network and fediverse. There’s also a bit of nuance here when it comes to federation. It’s a form of decentralization, but not every instance needs to connect with another instance. A Mastodon instance itself can be entirely self-contained, with users on it following each other only (though not common). While a huge benefit, federation also leads to some product constraints.

Federated, like email

Federation also means that you not only have to know someone’s username but also their server. This leads to email-like usernames, such as mine: @stammy@stammy.design. You need both bits of information to follow someone, which makes it a tad harder to use than a centralized service. Someone can always just search for you with your username only, but it’s not reliable for various reasons related to how the federation is done.

This also means your username can’t really be taken. It could be taken on a particular Mastodon server, but you can always use another server or self-host Mastodon on your own domain. It also leads to there being no such thing as verified accounts on Mastodon. There’s no central authority deeming which account is verified or not.

And it’s growing.

Mastodon is having a bit of a moment right now. The non-profit that runs Mastodon even turned away multiple VC investment offers. With all that’s happening at Twitter, people have been longing for a more stable product, one where their data could be more trusted, one that’s ad-free, supported by communities, and moderated by communities. One where terms and policies don’t change daily.

Mozilla announced they will be launching their own instance—Mozilla.social—next year in pursuit of building a healthy alternative to today’s social media platforms. Even the Washington Post wrote about how to get started with Mastodon.

"While there is no shortage of social media platforms new and old, this is a radically different approach to social media that offers something traditional social media cannot. This may be one of the reasons why Mastodon has recently exploded in popularity, jumping from approx. 300K monthly active users to 2.5M between the months of October and November, with more and more journalists, political figures, writers, actors and organizations moving over."

—Mastodon

Getting started with Mastodon

It’s not easy, but it’s worth it.

Now that we’ve got a basic grasp of Mastodon, how it’s federated like email but similar in functionality to Twitter, it’s time to give it a try.

But maybe a bit of a heads-up first. While Mastodon may feel comparable in look and functionality to Twitter, it’s probably best to approach Mastodon with the mindset that it is a new platform rather than trying to view it as a Twitter clone. There are key differences that will take some getting used to, and it will be a bit harder to get started.

The first challenge is signing up. You can’t just go to the Mastodon website and create an account. You first need to pick where you want your account by picking a Mastodon server you wish to call your home.

Pick a server, follow anyone on any server

The concept of Mastodon servers ends up being a confusing part of the Mastodon onboarding and usage experience. Even after you have an account on one server, you can’t just log into any other Mastodon server. You always have to log into yours. But you will be able to follow anyone on your own server, even if they’re on a different Mastodon server.

So how do you find and pick a server, and does it matter which one you pick? There are several schools of thought on this, but I’ll try to explain it as best I can.

• The argument for picking any server: You can easily change servers later on if you want. Just pick a server that looks interesting and go for it. If you already know other Mastodon users that you want to follow and don’t need too much assistance with discovering content and accounts, you’ll be okay.

• The argument for carefully picking your server: Picking a server is like deciding where to live in a city or what subreddit you want to frequent. You’ll more easily run into the same people and content if you pick a server that’s relevant to your interests. You’ll also be more likely to find people who are interested in the same things as you.

  This is especially important if you are new to Mastodon and don’t know of many other people you’d want to follow that are on Mastodon.

  With Mastodon, in addition to your typical Home timeline comprised of people you explicitly follow, you also get two bonus timelines: a local timeline comprised of people on your specific Mastodon server and a federated timeline of posts from people your Mastodon instance knows about (not a full firehose of all Mastodon posts, just the one your instance subscribes to via relays and from people the instance follows).

  Having a high-quality local timeline gives you an opportunity to more easily discover great content related to your interests, helps other people discover you, and vice versa. This is important for a lot of reasons, the leading of which is that it’s harder to discover people to follow on Mastodon. There is no algorithmic timeline injecting relevant content you may like into your timeline, and searching on Mastodon is not great.

  So that’s one part of it. The other part is maybe more important: picking a server is also like picking your landlord. Do you trust the admin of the server to host your identity? Do you think they have the technical know-how to maintain and secure the infra as needed? Are they making backups? What if they get lazy, and you’re stuck on a 2-year-old version of Mastodon lacking all the new features? Do they have a plan for financially supporting the infra? Or are they running an overloaded server that is extremely slow?

  And finally, each Mastodon server has its own set of rules in place. The rules give you an idea of the type of community you would be joining. People that don’t abide by the rules can be actioned on by the server’s moderators and admins.

Finding your server

If there are already a lot of people you want to follow on a particular server, that’s probably a good place to start. Examples of Mastodon servers I come across often include ones like mastodon.design, front-end.social, hachyderm.io, infosec.exchange, indieweb.social and more.

An easy way to find where your friends are on Mastodon is by using Debirdify or fedifinder. You authenticate your Twitter account, and it will tell you where people you follow on Twitter are on Mastodon if they’ve made Mastodon accounts. It’s an easy way to get an idea of Mastodon instances you may want to use.

You’ll quickly notice that not all servers have open, public registration. Some may just be entirely closed or require an invite and are meant for a smaller community. Others require approval by the admin before you can join. And others may only be temporarily closed, so the admins have time to upgrade their servers to deal with the influx of new users, and you may just need to try again later.

You can, of course, just browse yourself and see what’s out there. Tools like instances.social, MastodonServers.net, FediDB, and the official Mastodon servers page can help with that.

I’m on macaw.social, a small private Mastodon instance created by former Twitter employees meant for former Twitter employees and friends stammy.design, my self-hosted Mastodon instance.

If this is all a bit confusing, you can always just pick from one of the huge Mastodon instances like mastodon.social, mas.to, and mastodon.cloud. However, since most of these are getting a ton of new users now, they are more likely to feel slower until they scale up their infrastructure.

Self-hosting your own Mastodon instance

A bit more than meets the eye

Of course, the beauty of the Fediverse is that you can just host your own instance, own your data, and have complete control of your Mastodon identity! If you know that this is what you want to do, there are a few routes to take.

• Managed hosting: There are a few hosting companies that specialize in hosting Mastodon servers, such as Masto.host among others, though at this time some have paused new signups due to high demand.

• DIY hosting: And then you can just do it all yourself following the official guide on any server where you can set up Postgres, Redis, Ruby, and Sidekiq. You’ll need to have an email host so your Mastodon instance can send emails to you, and you’ll likely want some cloud storage, such as S3, for your media and files. You’ll also want to have a system in place for regular database backups. Here’s an article I found outlining someone’s experience setting up their instance on AWS.

  Running a server yourself is a bit more involved than setting up a simple static website or WordPress install. And depending on how many relays you set up (more on that later), you may find yourself tuning the Sidekiq background job processor config so it can run faster. If you still want to DIY but prefer a bit of assistance, the hosting provider DigitalOcean has a "1-click" setup for Mastodon. It’s still not a walk in the park, but it saves you quite a bit of work in the command line.

But with great power comes great responsibility. By hosting a Mastodon instance, you’ll be liable for the content on your server created by your users and anyone you follow as well as what they boost (boosts are like ReTweets).

Yes, you read that right. The way Mastodon works, everything you view on your Mastodon account, including media, is actually hosted on your server, even if the Mastodon user you follow is on another instance. Their instance just sent that post to yours, essentially. So any text or media in their posts is now hosted by you. And if your instance has any relays setup, you’ll have a lot more content being cached and served from your instance.

This goes down the path of needing to register a designated DMCA agent if you want to be careful. The EFF has a detailed article on the topic: User Generated Content and the Fediverse: A Legal Primer. This a long thread and accompanying blog post also outlining some of the legal ramifications of hosting your own Mastodon instance.

So until you’re 100% sure you want to take on that commitment and liability, maybe start off by joining an instance hosted by a seasoned admin and donate to help them manage infra costs and things.

How to find people to follow?

You’ve found a Mastodon server you like, created an account, and now you want to find out who to follow or how to find people you already follow on Twitter. There are a few great tools to help with this.

• Move to don: This is probably the easiest way to get started. Connect with your Twitter account, and it just shows you people you follow that are now on Mastodon, providing you an easy way to follow them all or individually. You’ll want to keep checking it over days/weeks/months as more people sign up for Mastodon. Update: It seems Twitter has disabled Move to don's API access but Mastodon Flock seems like a good replacement.

• Twitodon, Debirdify and Fedifinder: I mentioned some of these tools earlier for helping you find instances, but they also help you find people to follow from your existing network on Twitter. However, at the moment, they are a bit manual and rely on providing you with an exported CSV file of user accounts for you to upload and import into your Mastodon instance.

• Followgraph for Mastodon: This is another great tool, but unlike the others doesn’t need you to connect your Twitter account. Instead, you just provide it with your Mastodon handle (or anyone else’s), and it recommends other accounts to follow based on who your followers follow.

• Fediverse.info: Another tool for helping you find people to follow. This one works by letting you browse by hashtags people have put in their bio.

Following Twitter accounts directly on Mastodon And finally, if you’re devoted to Mastodon and don’t feel like checking Twitter all that often anymore, you can use some software called BirdsiteLive—an "ethical ActivityPub bridge to Twitter"—to follow people that are only on Twitter. It needs to be hosted to use, but you can find live instances of it on FediDB. Basically, you just type in a Twitter username, and it gives you a Mastodon username to follow. At this time, one example instance that’s online is Bird.makeup.

Cross-posting between Twitter and Mastodon If you’re interested in posting to both Mastodon and Twitter at the same time, you can use a tool called Moaparty or do it yourself with IFTTT. However, as a word of caution, some Mastodon folks don’t appreciate this behavior and may even consider it spammy. I agree with that sentiment: treat Mastodon as its own thing.

Mastodon apps

And how developers have truly embraced Mastodon

Now for the fun part: exploring the world of Mastodon apps and clients.

There are several ways to interact with Mastodon. You can, of course, use the standard Mastodon web interface for your server, as well as the official Mastodon iPhone and Android apps to log into your server.

If you want a more advanced web experience, you can go to Preferences ’ Appearance and enable the "advanced web interface" to give you a multi-column layout reminiscent of TweetDeck (there's also Mastodeck). And if you would prefer a simpler web client, take a look at Pinafore.social. Update: it looks like Pinafore is shutting down but the Elk web client looks amazing.

But I’m not here to tell you about the official apps. I want to talk about the growing and thriving developer community that is fully embracing Mastodon and the potential of the decentralized protocol. To paint a picture of why this is such a big deal, you also have to understand how much of a hassle it has been over the last decade to build anything on top of the Twitter API. It was especially hard to see as a long-time employee.

Long story short, Twitter made it hard. Hard to even get an API key and get your app approved. Hard to get bugs fixed or new features accessible via the API. Hard to access the data developers wanted. Hard to not hit arbitrary constraints or limits. Things were always changing, rugs were pulled, announcements about new priorities and new rugs were made, only for them to be pulled again (read this, this and this).

No one knows this pain better than the team at Tapbots, makers of a popular third-party Twitter client called Tweetbot. I’ll be the first to say I did not like Tweetbot—not due to anything about the app itself; it was beautifully executed and well-built—I was just designing for the official Twitter apps. Tweetbot had nice details, but I never really used it much, though oddly enough, quite a few of the Twitter iOS engineers used it over the years, if that tells you anything.

Needless to say, the Tapbots team had to deal with all the ups and downs that came with building on top of the Twitter API. Twitter wasn’t necessarily fond of third-party clients that they couldn’t effectively monetize or control.

Mastodon brought the winds of change, an open web not controlled by any single entity. Mark Jardine from Tapbots wrote a thread outlining his experience building on top of Twitter, contrasted with their new focus on Mastodon:

“As much as Twitter has brought us success, it has also been extremely frustrating for the past 6-7 years trying to build something great with a nerfed API.”[…]

“Building an app for an open and decentralized social platform felt so refreshing. Inspirational! I haven’t been so excited designing something in a long time. With Tweetbot, we were always fighting with the API limitations while knowing in the back of our minds that someday the API could be taken away.”

“I didn’t realize it then, but that killed a lot of our excitement and enthusiasm. With @ivory, we are just ecstatic every single day. It’s just been a pure joy to make software again.”

—@mark@tapbots.social

Tapbots is building a lovely Mastodon client for iOS and macOS called Ivory. But they’re not the only ones ramping up development on a Mastodon client. There’s also Mammoth, an app in development by iOS developer Shihab Mehboob along with his team. I’ve also been testing Mammoth, and if you’re used to the official Twitter mobile apps, you’ll find Mammoth familiar.

Then there’s Metatext, Toot!, tooot, Mastoot, Mast, Tusker, and Woolly, IceCubesApp, among others. Some of these are in Testflight and are best found by following the developers on Mastodon. The official Mastodon site has a list of public third-party apps as well.

Using Mastodon

Toots, boosts, and bad search, oh my!

So you’ve made it. You have an account, you’ve followed some people, and you have installed a lovely Mastodon app. Time to get to know Mastodon a bit better. If you’re coming from Twitter, you’ll pick it up quickly, but there are a few quick differences:

• Tweets → Toots: This was the Mastodon word for a post for a long-time, but a recent software update renamed the "Toot" button to simply "Publish." Some folks still refer to posts as toots.
• ReTweets → Boosts: Sharing a post on Mastodon is done by boosting, much like ReTweeting. If anything, boosting is encouraged and seemingly more common on
• Quote Tweets: Mastodon has no equivalent of Quote Tweets. You can only boost a post. This was an intentional design decision meant to curb abuse and harassment. However, with the Eternal September of Twitter users flooding Mastodon, it is a bit of a hot topic and has come up often recently. Here’s some more thoughts on the topic from an engineer I worked with at Twitter who knows the problem space well. But they eventually find their way on Mastodon; the Mastodon founder recently expressed some interest in a version you can opt out of.
• 280 character limit → 500 character limit: Toots are 500 characters! Enjoy the extra space to share your thoughts without easily getting misinterpreted. You can also reply to your own toots to create a thread, though the composer doesn’t have the built-in functionality to create a thread that Twitter has (and that I designed while at Twitter). However, since it is open-source software on top of ActivityPub, anyone running their own instance can modify this limit to be much larger.
• Verification: As mentioned earlier, Mastodon has no concept of account verification, though some users add :verified: to their username and it gets rendered as a checkmark on their avatar in some Mastodon apps. Separately, links on your profile can get verified if you add a rel="me" link on your site.
• Direct Messages: Mastodon doesn’t really have a concept of direct messages at this time. While you may see a DM tab in some Mastodon clients, they are really just toots with the privacy setting set to "only those mentioned." But the account you mention can mention someone else in their reply, and they will get added to the DM. It’s important to note that they are also not encrypted, so your Mastodon instance admin (along with the admin of any instance you're sending to) would be able to see it in the database if they really cared to look it up.
• Lists: While both Twitter and Mastodon have the ability to create and follow custom lists of accounts, they work a bit differently on Mastodon. You can only add people to a list that you’re already following. On Twitter, you could add anyone to a list even if you didn’t follow them, which made it great for creating separate timelines you could hop between as you wished. However, I did see some chatter about Mastodon considering this, under the moniker exclusive lists.

There are also a few other features like following hashtags (though it has some limitations) and the ability to put a post behind a Content Warning (the "CW" icon in the Mastodon post composer). Aside from that, you get the expected functionality of being able to attach video, images, and polls in addition to being able to adjust post privacy settings.

There’s one more thing, and this one may take some getting used to. Full-text search of the contents of Mastodon posts isn’t really a thing. You can search for accounts, and you can search for hashtags. Searching for accounts works pretty well, especially when including the full @username@example.com format. Searching for hashtags is a bit more limited and will only surface results that your instance knows about from local posts and federated posts. But your server doesn’t instantly know about all posts on the fediverse, so you may not see all the results you expect. You can get some very limited searching for your own posts, mentions, favorites, and bookmarks if your server admin setup ElasticSearch.

Search could get better if someone made their own service dedicated to indexing, relaying, and searching the fediverse, but that is no small technical (and expensive) feat.

Isn’t it pretty bad that there’s no good search? Well, along with the lack of Quote Boosts, this is framed as a purposeful design decision (though it also feels like a technical challenge):

"Mastodon deliberately does not support arbitrary search. If someone wants their message to be discovered, they can use a hashtag, which can be browsed. What does arbitrary search accomplish? People and brands search for their own name to self-insert into conversations they were not invited to."

—Mastodon

My thoughts on Mastodon

Vast potential mixed with non-trivial constraints

Mastodon brings a lot to the table with its federated model of sharing utilizing an open protocol. It’s easy for anyone to host their own instance and own their data while participating in a large network with many communities. It’s not owned by anyone, nor can it be. It’s an open-source project run by a non-profit. Anyone can fork the code and do what they wish.

But, it’s not easy for anyone to get started. There’s no question about it, you cannot come from a centralized and well-capitalized product like Twitter and expect the same of a decentralized, open-source project. Mastodon is very rough around the edges when you approach it from a mindset of the former:

• Hard to sign up. Hard to find communities: Okay, so I just installed the app... I can’t just create an account? I have to pick a server? Even with the official Mastodon app providing a list of instances to choose from, it’s still confusing. How can I see an example of the content and people on each server to know I’m choosing the right one? What are the implications of choosing a server? Is it publicly facing? Can I change it later? Is it easy to change? Et cetera.

• Hard to find people: Once you have an account, you’re still in for more uphill battles. How can you even find good, relevant, and interesting accounts to follow? You have to rely on word of mouth or third-party tools.

• Hard to find content: It’s hard to continually discover the type of content you enjoy. There’s no algorithmic timeline to inject new content into your home timeline. You have to rely on... hashtags, people you follow boosting content from others, and remember to continually check the federated and local timelines of your Mastodon instance. Using hashtags started to feel so thirsty even years ago, but now it seems like a necessity?

Federation brings power. It brings constraints.

Challenge 1: Following accounts and engaging with posts not on your server

One early challenge you’ll run into with federation is simply around following people as well as engaging with posts you find on other instances. Let’s say I find a link to a Mastodon post externally (as in not something I come across while logged into my own Mastodon server). It could be a link on someone’s blog, from a chat app, and so on. By clicking that link, I am going to the post hosted on Mastodon instance that is not my instance. Even though I may be logged into my own Mastodon instance, this other instance doesn’t know or care about that. I’m just a visitor and have no account with that instance. I can’t favorite the post, reply, or even follow the author.

Instead, the onus is on me to find a way to that same profile or post, but within my Mastodon instance where I’m logged in and can carry out any actions I want to take. This is super annoying and happens all the time. For example, I can’t link you to my Mastodon profile @stammy@stammy.design and have you tap follow. That would only work if you already had an account on stammy.design. So you have to copy the username, then go to your Mastodon website or app and search for my account.

What’s the solution? Nothing great. A partial solution for desktop is to use a Chrome extension that redirects profiles to your own instance, but it doesn’t work for posts (you can't just reformat the URL as the ID of the post isn’t the same across instances). And I’ve seen some chatter about an intents/handler-style way to deal with this.

Challenge 2: Sometimes you just don’t see things

A recurring theme with federation and Mastodon is around how your instance only knows about things it knows about. It doesn’t automatically know about every post across every Mastodon server online. This can lead to some unexpected behavior:

• Profiles you visit may be empty at first. They won’t have any posts if your server has never encountered this account before (and no one else on your server has followed or interacted with the account). Following the account will start to get new posts from that account, but don’t expect it to instantly fill it up with every historical post from that account.

• Not all public replies to a post may be visible. This one is the most concerning. Your server may not know about all the replies to a post, and therefore you may only be seeing a slice of the conversation on a post. Simon Willison has a great dive into the issue in this thread on his personal instance.

• You may not be able to see a complete list of someone's followers. Similar to the above, your server likely has a limited view into who follows that account.

• Boost and favorite counts may not be accurate. Same story here; your server only knows what it knows about. If you want to get a real understanding of a post's true engagement, your Mastodon client may have an action in a menu for something like "open original post."

So, how can you get your Mastodon server to know more? If you’re on a larger instance or tend to mainly communicate with people on the same server, you’re less likely to run into these issues. There’s not much of a fix aside from the admin adding a ton of relays to ingest as many posts from the fediverse as it can, but that’s not ideal for various reasons.

Challenge 3: Moderation and incentives

And one last challenge I see is typically listed as a good thing about Mastodon: moderation. I’m annoyed with Twitter because it seems like they are continually changing the rules, banning people arbitrarily, and I didn’t want my identity held hostage. Well, the exact same thing can happen on Mastodon and more.

How do you moderate a federated network? You leave it up to the instances to moderate themselves. You just have to trust the admins of each instance to do the right thing, and the idea is that by picking your instance, you’re picking a community you embrace and feel part of, and everyone will follow the established rules. And if you’re doing all that, you shouldn’t have an issue, right?

This quote from Noah Smith in his article The internet wants to be fragmented sums up nicely why moderation is great:

"Community moderation works. This was the overwhelming lesson of the early internet. It works because it mirrors the social interaction of real life, where social groups exclude people who don’t fit in. And it works because it distributes the task of policing the internet to a vast number of volunteers, who provide the free labor of keeping forums fun, because to them maintaining a community is a labor of love. And it works because if you don’t like the forum you’re in — if the mods are being too harsh, or if they’re being too lenient and the community has been taken over by trolls — you just walk away and find another forum."

That seems fine, and if you don’t like it, you can find another instance or host your own. But what if you couldn’t move your account? If you don’t get along with your instance admin, it seems they can even block your move to another instance.

Okay but that’s like the worst-case scenario, right? Yea, that’s true. But there’s one more unpleasant situation. Running a Mastodon instance is a non-trivial amount of work. There’s technical setup and regular maintenance to keep on top of, there are real costs associated with hosting, and there’s legal risk as well.

Since there are no real incentives to host and moderate a Mastodon instance, you could end up on a poorly run instance. If you’re not on a well-run instance, best case scenario, sometimes your server is a little slow or isn’t always running the latest software, but it is generally okay. The worst case scenario is that, uh, your server goes down permanently, along with your Mastodon identity and all your data.

All this to say, choosing your Mastodon server is an especially important task. One thing that would make this better is if Mastodon had a more streamlined way to be able to donate to Mastodon admins to pay for server costs. I imagine seeing some Stripe link in settings and being able to set up a small recurring donation.

Here’s why I like Mastodon

While those challenges complicate things, they don’t overshadow the brilliance of Mastodon and the protocol for me. One of those reasons is that it feels more intimate, just a small place with the people I follow. No one or thing unexpectedly forcibly getting injected into my home timeline.

On Twitter, you have three groups of accounts: celebrities and other verified accounts, brands, and then just regular people. On Mastodon, you only have people (and with so many instances to choose from, no one can really squat on your desired username). No ads either. The Mastodon home timeline is always in reverse chronological order—not algorithmic or ranked like Twitter’s timeline is by default. This means your timeline is saner. It’s not filled with threads spewing the same nonsense that gets injected into your timeline by the algorithm. It’s not filled with ads.

And with the longer character limit, you can more easily converse with people or share your thoughts without losing much in translation or spending lots of time trying to reword things to fit logically in one or multiple posts.

Mastodon feels like the early days of Twitter, with people just sharing thoughts, not worrying about how to optimize for engagement. It feels more intimate, authentic, and close-knit. My only advice for those starting out on Mastodon is to boost posts you think others should see to help with discovery, and also, you can favorite your heart out knowing it doesn’t do unexpected things like injecting the post into others’ home timelines because there’s no algorithmic timeline.

As I mentioned earlier, Mastodon’s open-source software, open protocol, and strong API without limitation (as compared to Twitter) make it a dream for developers. I’ve been seeing this flurry of excitement from developers building Mastodon apps. I’m excited to see what else gets built on top of, or for, Mastodon and ActivityPub.

The challenge will then be how the Mastodon project and broader community deal with the huge influx of new users. Will they develop efficient product development processes to deal with the flood of feature requests, complaints, and associated chatter in a principled manner? Will there be enough people to push for great design?

So far, everything on Mastodon feels like a page out of early Twitter. Nothing bad about that; it’s easy for people to join and generally understand how things work. But shouldn’t it evolve to best embrace the unique affordances and constraints of Mastodon? What will it mean for future functionality to look, feel and act like the decentralized network it is? People designing for the official Mastodon project need to think less about Twitter and more about what it means to be Mastodon. Perhaps third-party Mastodon clients and forks can lead the way before they get adopted.

An open web, owned by its users

Yes, another "bring back blogging and RSS"

This is the part where I talk about my growing desire to have more control over, and own, my data and my online identity. I want to move away from relying too much on just a few large centralized tech companies when they control too much of my data. I think about worst-case scenarios. What happens if I get locked out of this account for a day, a week, for good? It’s with that mindset that I need more control, access to the raw data, and more.

That way of thinking is often a bit overkill and can lead you down a complex path (have you ever tried hosting your own email??), but 2023 is the year I begin to detach myself from large tech companies like Twitter and Google. And for the services I do rely on, I expect encryption. And it was nice to see Apple roll out iCloud Advanced Data Protection recently. I love Signal and ProtonMail. It gives me comfort knowing that even if my account was compromised, the attacker would also have to know a separate encryption key to get into my mailbox.

I’ve been running paulstamatiou.com for 17 years. First hosted from a Mac mini in my dorm room at Georgia Tech. Starting this site and continuing to maintain it has been one of the best things I’ve done. It gives me a space to tinker, write, share thoughts, show work, and publish photos.

I miss the days when if you wanted to have a space online, you had to make it yourself. Personal blogs were their own communities. The comments sections were helpful and thriving. They were hard to discover, but we got by. We had feed readers, blog rolls, Technorati, and trackbacks.

Every day, I would be excited to open my feed reader and see if anyone whose feed I subscribe to had posted anything new. Seeing that unread count badge on a favorite blog was like a little present.

In those days, you followed people. Sure there were a few big publications you might keep track of, but you didn’t really follow "developer blogs" or "design blogs." It was always just people’s personal blogs publishing whatever felt interesting to them. They had their own take and personality.

We’ve seemed to have lost a bit of that personality and authenticity. We’re living in a world where it often feels like everything is carefully curated and polished just so for engagement. This was well before we became far too accustomed to busy feeds, videos, threads, gamification, listicles... the constant need to be entertained and get a serotonin hit. Personal blogs offered a glimpse into the real lives and thoughts of their creators.

In recent years, we made way for the rise of personal newsletters. It was only after my inbox had become unmanageable from Substack and other newsletters that I started using an RSS reader again. A modern one that could also manage newsletters and declutter my inbox. But the type of content I long for is not there. (By the way: you can just add .rss to any Mastodon profile or search URL and get an RSS feed).

I’m hoping that the recent interest in Mastodon will get people to start thinking more about taking control of their data and online identity. Mastodon has a great shot at recreating that feeling of community that personal blogs used to have. It can be your own space.

I only ask that you don’t think of it as a Twitter replacement but as a new thing. A new way to communicate, connect and build communities. A decentralized product like Mastodon will have some learning curves, no doubt. But it’s a start. And it’s a start that’s not owned by a billionaire.

If you’ve read this far, thank you! You can follow me on Mastodon by copying my full username and pasting it into the search of your Mastodon website or app to find my profile and hit follow: [object Object]

Much of my career as a designer has led me to hold product and design quality in the highest regard. It's not easy. I want to be proud of the things I ship and put my name on them (see also). That 10 year old post from Bryan Haggerty is still as true as ever:

“With small teams, the output, whether it’s an app, web site or any other product, represents the people behind it and the tremendous amount of effort they expended to make it. And it’s common for those people to willingly put their name on it, taking accountability for what’s great and what needs to be improved.”

I’ve worked on numerous projects with large teams where the work shipped felt like a string of excuses—a reflection of tight timelines, cut scope and endless constraints. It never feels great to ship something to real people that is not an accurate representation of the intent you and the team had.

As a designer I'm motivated not only by identifying and successfully solving problems for people through software, but also by the care, attention to detail and craft I'm able to put into it along with the team.

I want someone to use something I've created and feel that was intentional. That it not only had their exact needs in mind but went beyond to care about the details and have personality. This is a post about well-made, high-quality products and why shipping quality is hard.

I’ve always been something of a hybrid designer and developer. I initially studied computer/electrical engineering when I went to college in 2004. Eventually I felt that was too far removed from the end user experience of the devices we use. I transitioned to a major that combined design and computer science. However, when I graduated I felt like I wasn’t great at either. I spent the 5 years after college working on several startups I cofounded before landing at Twitter in early 2013.

When I joined the Twitter design team I was designing in Photoshop. For things that demanded higher fidelity, I would dive into After Effects to make small UI videos—a far cry from the interactive mobile prototyping we take for granted today.

The next year I became immersed with interactive mobile prototyping. I fell in love with a Javascript animation library called Framer.js—it felt like a superpower. I could make fully interactive prototypes for web and mobile experiences that felt real (old examples here and here).

Prototyping got me a step closer to what the actual product would feel like. It was my interactive canvas for testing out ideas and concepts rapidly. Prototyping dramatically elevated my design process, helped me think through implementation details, interactions, motion, and communicate concepts.

Of course, while high-fidelity visual designs and a complete interactive prototype can help you communicate your concept and get people excited, it won't help the final product get built.

For that you need a lot more. You need to make your case for what the problem or opportunity is—most often validated with at least directional data and/or research insights—and why your specific solution could work. You need to ensure it weaves into broader company initiatives as well as goals for your team and org. And you need a plan to get your product out there in a timely manner along with ways you'll further learn and validate your approach. An executive team won't be thrilled to hear you want to spend a year building something based solely on a hunch.

That's where the challenge of building quality products starts to creep in. The constant tension of shipping faster versus shipping better. Falling into a cycle of "Ship, then iterate" is a trap. It ends up being more shiterate. Things happen and that "fast-follow" V1.1 release or V2.0 you had imagined probably won't. There's always a new shiny initiative, re-org or new leadership hire that throws a wrench into things and changes all plans. Don't rely on a future release to clean up today's mess.

Having spent many years going through this constant quality versus speed tug-of-war I focused a lot of time and energy on product strategy as part of my design process. I crafted a story about our customers to our teams and leaders. I wrote a ton of internal documents; product briefs, design briefs, customer problems, product opportunities, vision, et cetera. I spent time evangelizing efforts, working on decks to show where we could go, how we could get there and what it could unlock, while addressing the opportunity cost as well as challenges like built-up tech and design debt.

But even that doesn’t ensure that the thing you've designed will result in the high-quality shipped solution you envisioned. There are a lot of reasons why shipping well-crafted, quality products is hard, especially on a large team.

What is quality?

And why is it so hard?

I often use the word quality when referring to apps, products and services I hold in a high regard but another word that often comes up in this context is craft. Craft, as in something that is handcrafted where something someone spent a lot of time on and maybe even embedded their own personal touches and personality in it. Often something handcrafted feels more premium.

There’s a reason high-end car manufacturers boast about their handcrafted cars. Something so premium that an individual person spent time obsessing over the details. Some even prominently display a plaque on the engine with the signature of the engineer that built it. This goes back to that quote earlier about putting your name on something and taking accountability.

Quality and craft are not just words designers toss around when referring to some veneer of polish adorned on top of a product with superficial visual design tweaks and unnecessary, over-the-top animations.

Quality is all-encompassing.

• It’s accessibility so that everyone can use it.
• It’s performance and ease of use so it respects the user’s time and helps them accomplish their tasks when they need.
• It’s reliability so they can feel good about having this tool in their pocket for when they need it.
• It's durability with designs and components that can scale to withstand future needs and uses.
• It’s well-considered.
• It’s the feeling that a lot of time and care went into creating the product: that someone has already thought of you.
• Of course, it can also be a bit extra and bring delight in unexpected places and important moments.

Apple gave a talk about the qualities of great design where they interviewed people on their thoughts around quality:

Quality happens throughout the entire project whether you're cognizant of it or not. It happens when identifying the customer problem to solve, designing a solution, validating it, building it, maintaining it, and even when you sunset the product. A focus on quality drives a way of working in which you dynamically either embrace constraints when you need to or challenge them when you see an opportunity.

People hire services not just based on what they can do but how it makes them feel.

Quality has a direct relationship to that. Quality products can take your users from "I'm merely using this thing to accomplish a task" to "this is something I love using and I'm telling everyone I know about it."

I’m writing this article in a macOS app called Ulysses right now. I love it because it’s quality software. It's approachable, actually easy to use, fast, and I can personalize it to my taste.

It makes me feel good about the work I’m doing. I could have written it in a myriad of other text editors filled with bells and whistles but I chose Ulysses because I know I can rely on it to let me focus on what I’m trying to write. Quality products make me excited to use them.

If we all generally agree that quality is a good thing, then why aren’t there more high-quality apps and services out there? Because quality is hard.

What affects quality?

Lots of things can affect the quality of your product, especially on large teams, including culture, incentives, skills and tools. Here’s just a few that are top of mind:

• Leadership, organizational support and incentives. Does the organization care about quality? What does quality mean to them? How does it tie into the career ladder, promotions and prioritization frameworks? Do they focus more on execution speed over quality?

  Is quality baked into the normal product development process, or is it often relegated to low priority "polish" tickets that pile up. Will leadership pause a launch if the quality is below their bar? What is that bar?

  If support for quality does not come from the top, it's far too easy for ICs to skirt over issues and pay a little less attention to details they think their reporting chain won't notice.

  Do different roles (like engineering, product, design) have different motivations for getting their work done? This, again, ladders up to what the org thinks about quality.

• Culture around quality. To maintain a shared, company-wide understanding of the company's specific stance is on quality, how does quality get rewarded, celebrated and prioritized? Is there a process in place for delaying a release and having a retro when the quality bar slips? Who decides when quality has slipped? Who's accountable for addressing it?

  Does everything need to have the same level of quality at the company? Are there certain things that need more or less? Unclear alignment around what deserves quality amongst teams can lead to issues.

• Trouble identifying issues. Do you have the right people with the right skills and motivations to flag quality-related issues? Do they have the right tools?

  Focusing on quality is often thankless work. Tons of time can go into rigorously testing builds, logging issues, providing feedback and coming up with solutions given the constraints.

  Does everyone have an eye and the time for design QA? For the items that are more visual/motion related, are the designers skilled enough at visual design to even know there are issues or be motivated enough to address them? Are there other designers they can rely on on the team for pixel-level details if that’s not their strength?

• Poor ticket/engineer fit. The onus is not just on designers to help identify and document issues to be addressed. What happens when a particular engineer picks up the next ticket and it involves a specific set of knowledge they may not have, for example like knowing about the nuances of animating collection views on iOS.

  Does the engineering manager wait until there's an engineer better suited to tackle this ticket? Does the assigned engineer compromise with the designer on a solution if this is too intricate to tackle for them? What resources does that engineer have at their disposal?

• Inadequate tooling for effective design/engineer pairing. Back when a designer and engineer might have worked in the same office with each other, they could sit down to iterate on a new build. They could easily try 10 or more different values for a specific animation, build and test together over the course of 30 minutes.

  Contrast that with the new way of working remotely. The designer may feel less comfortable going back and forth suggesting small tweaks to engineering builds, so they only suggest a few iterations so as to not feel like they’re annoying the engineer too much. And these iterations will be less refined because the pairing iteration speed is so much slower. Do you send over ipa/apk files? Does the designer have the dev environment setup on their machine and pull the branch to build and test themselves? Or, worse, does the designer just have to wait a day or two to be able to provide feedback on a build when the code is reviewed and merged into an internal dogfood build they can easily access.

  Relying on screenshots and video clips sent over Slack can only get you so far. Perhaps in the future there will be tools for this. I'd love something like high-fps, low-latency interactive VNC sessions for remotely controlling someone else's Xcode simulator for example.

• Liberal use of "MVP" or "it's just an experiment". Does the team use those terms to skirt around typical quality standards and ship something subpar? Does everything worked on, even experiments, demand the same care as a more mainstream release that goes out to all users?

  That's a slippery slope because it's all too easy to simply ramp up that experiment to 100% of your users if it performs well, without addressing quality issues that were neglected prior to shipping to that initial set of users.

  No one wants a slice of cake that is just a piece of the bottom layer. You need to have a taste of each layer with each bite, including the icing. So even if it’s not your entire vision, it has all the right pieces involved. Ditch the term MVP and use SLC (Simple, Lovable, Complete).

Most companies struggle to prioritize small quality and “fit & finish” design issues. On their own, these tickets seem like they'll have remarkably low impact for the product. How will fixing the alignment of this button help us have a better launch, higher customer retention or a more stable app? However, compounding effects come into play with this kind of work. One or two of them won’t make a difference. But when you’ve fixed a dozen or so? It’s noticeable.

Building that understanding into the way you work is key. But it's not the singular solution. It still goes back to many of points above. Does your team have the skills and incentives to identify and adequately fix those issues? Does the organization continually reinforce and celebrate work that ladders up to quality, craft and great design?

I didn’t write this section aiming to get to some sort of grand revelation about how you can build great software with one simple trick. Quality is hard.

I’m not saying designers, PMs and engineers should be holding up their projects for months to “get it right”. I'm saying that teams should be working in a way where everything is considered and there's a framework for identifying, discussing and prioritizing quality-related issues so that quality is a bit less of a sisyphian task.

“But the desire to ship quickly was counterbalanced by a demanding, comprehensive perfectionism. Most commercial projects are driven by commercial values, where the goal is to maximize profits by outperforming your competition. In contrast, the Macintosh was driven more by artistic values, oblivious to competition, where the goal was to be transcendently brilliant and insanely great.”

—The Macintosh Spirit

Quality is a way of working

It's not something you'll get to later

We've identified that quality is hard and that it's tied to a whole slew of things from culture and leadership to experience and tools. Quality is the way you work. Focusing on quality doesn't have to mean that suddenly your project scope has become bloated with a slew of tasks that will take 25% longer to complete. It can be prioritizing more complete, well-considered chunks of functionality (goes back to the SLC concept above).

What doesn't work in my experience is marking tickets you can't get to before your deadline as design debt, tech debt or polish to tackle later. Polish is an easy word to equate to design tickets but it's an especially poor choice as most people tend to think it's defined as optional, obsessive and unnecessary details.

I've been immersed in thinking about and working on quality for years at large companies. It's insanely hard to change a company's perception of quality and process, but here are a few things that help:

Balance long-term and short-term design

Build a working style that always pairs thinking about the long-term design direction of your surface area along with the short-term. By only thinking short-term it's far too easy to design or build yourself into a corner, only too realize you've built a cluttered UI or relied on complicated interactions and flows. Doing so also helps you become a strong ally to your product partners so you can craft a story of where you see the product going and how it could potentially best address customer needs in the future.

I used to think doing long-term (so-called vision work) was bogus. Designers would get assigned to these "vision projects" by various executives, spend months on some explorations and a deck, only for the work to be archived in some internal wiki, never to be touched again. They tended to be run only by designers, not informing or consulting with adjacent roles and teams along the way.

As much as designers want to go off in a corner and come back with magical designs and a roadmap, this really needs to be a team effort, even if your stakeholders are more in the "inform" role of the DACI framework.

Close the gap between design and engineering

Bring design and engineering closer. There’s still a ton of onus on the designer to help illustrate and share their vision with their team. Sometimes designers are limited by what they can make with the tools at their disposal and their skills. If they can’t design or prototype at least a sliver of what’s in their head, how can they expect their engineering counterparts to not only build it but build it well? It may even limit the types of design solutions you explore if you're unsure how to even communicate it. However, by building stronger relationships with your engineering coworkers you can try to bridge that gap more effectively.

For me, Figma is where initial hunches live; a starting point. Not final designs. it's not until I start building and really using it that I get more signal to understand what aspects of the design feel good and which aspects don't. That's a big reason why I dislike teams that treat their visual designs as complete and "ready for handoff." Please, never treat design as something you just handoff to engineers. That's a great way to devalue the contributions of the engineers on your team and lead to a worse product. Treat it more like a conversation between design and engineering.

Some larger teams have dedicated prototyper or design/UI engineering roles. That's one way to help bridge this gap, though for me they always felt one-step removed from product design and I wanted to also be leading the design in addition to coming up with the final solutions. If you have these roles, it's important to not just assign them from project to project merely to prototype something a team needs for a research study or other short-term need. Instead, have them paired up with design and research for 100% of the project.

It's also important as a designer to know when to push on something and maintain your quality bar and when to compromise. That's your superpower. Everyone will hate working with you if you hold a high quality bar but don't know how to work within the context of your business goals and customer needs. Getting as close to the technical side will help you. Here's a good post on this topic from an engineer's perspective: Effective Collaboration with Product and Design.

Then there's tooling that can help improve speed of iteration; making it faster for designers to receive and test builds from engineers (as mentioned in the previous section). And finally, provide resources for engineers to learn more of the intricacies of front-end development, UI and motion frameworks. This may be more important for companies that tend to hire more full-stack engineering roles.

Of course, all of this gets a lot easier if you're a designer who can also code your designs.

Determine what quality means for your team & set your quality bar

Depending on the company, industry and team, quality will mean different things. For one product and customer type it may mean a huge focus on reliability and speed while for another it may be a focus on delight and attention to detail.

A shared understanding of what types of work meets and what type of work doesn't meet your quality bar, along with executive support, can help with prioritization. Doing so can help realize the compounding effects of smaller quality and design tickets.

This entails understanding how a user-facing visual refinement is a very different type of ticket than something like a performance bug or crasher. If you only have one type of work queue, it's very easy to only prioritize the bugs and crashers. But when do the other types of quality tickets get prioritized? Try to dedicate a certain amount of time to each type of work for each sprint. This goes back to the SLC concept: you want your slice of cake to be vertical so you can taste all the layers, including the icing (yes, I love this silly analogy).

Don't always jump to using existing patterns

This is probably the most controversial one. In the design industry there's a remarkable push behind design systems. They have a myriad of benefits including speeding up design and development time, making it easier to maintain accessibility, as well as evolve and maintain large surface areas in your product. But if design systems are not run well, they can hold you back.

Poorly run design systems can preclude valid design explorations in pursuit of consistency and efficiency; just using what's already there.

For brand new products, don't to be too eager to start on a design system. You often don't know what this thing is yet. You don't know where the product is going, what needs to scale, what the customer needs are, how they'll react to your initial version or what the personality of the product will be.

But this familiarity with existing systems can get in the way of helping you tackle new kinds of problems. You may prematurely bucket it into a problem you've seen before. Design systems are just one of the tools at your disposal. Applying your design systems thinking (or any other patterns you've worked with before for that matter) all too eagerly may prevent you from noticing the obvious. That maybe there's a different way of thinking about the problem at hand. Apple touches on this a bit in this video about intentional design.

A related tool I like to employ sometimes, especially to break out of my own personal design aesthetic and tendencies, is to ask myself, how would [another company] design this? I might think to myself "Airbnb loves to have these huge headers, bold colors, dynamic cards and sheets, so they may approach it like this." Then I'd mock that up.. and do the same with other companies. I may hate it, but it will get me thinking.

Sunset or re-evaluate old functionality

Incentivize and commit to sunsetting features that are no longer your core focus, have low usage, or are otherwise detrimental to your product. If you work on a product with millions of users, even low usage things will be sizable and may have secondary effects that are hard to gauge. This is hard, thankless work. It requires support from leadership to allow a team to focus on removing something instead of spending that time that could more directly move tangible metrics.

But without this rigor, your product could all too easily become cluttered, slow and become harder to maintain over the years.

Use what you've built before you ship

I've seen it happen all too often. You're working on a project. You build a prototype and work with a researcher to get some initial qualitative feedback or you ship a small experiment to gather data. By the time the research insights have been finalized or the experiment data has had enough time to account for novelty, you don't have much time left to explore significant refinements or alternative design directions. Your team is already on the hook to ship this before the end of the quarter or has tight timelines to get this code merged before the biweekly deadline to ship to Apple. So you end up compromising with a less-than-ideal refinement, even though you don't think it's the solution your users really deserve.

Always leave adequate time after gathering new insights to not only design refinements, but build them and live with them for a bit first. It's too easy to compromise on quality in the face of existing timelines.

Joining Rewind

Why going to a startup is the perfect fit for me

Earlier this year I decided to leave my job, focus on my wedding and take a few months off. I had a lot of time to think about what I wanted to work on next. I wasn't sure if I wanted to join another large company, a startup, or transition to contracting with a few companies.

One thing was clear though. I wanted a different kind of design challenge. Designing for mobile had started to feel boring. It felt so repetitive. The same constraints. It felt like I was just going around employing the same few patterns, especially when working on larger teams less interested in taking risks and trying new things.

It would be a bonus if I could find a company where I could more readily influence product quality by diving into the codebase myself. I had a strong desire for interesting work with a great team where I could be proud of what we built together. That's what we all want right?

Dan Siroker happened to reach out to me around this time. Dan and I had crossed paths a decade ago in Y Combinator when he was starting Optimizely. We caught up and Dan showed me what he had been working on, complete with a live demo of Rewind. I was blown away by the ambition and concept. I immediately grokked it.

Rewind is the search engine for your life. It's a macOS app that fully utilizes the capabilities of Apple Silicon and macOS Ventura to record everything you see, analyze it and make it searchable in real-time. All while being private by design—everything is stored locally on your machine.

Rewind helps you out in those situations when you're racking your brain try to remember where you saw something. Can't find that tweet you know you saw once? Or wish you could go back 15 seconds to recover that long performance review you were writing before your browser crashed? You can search or rewind time. Once you've found what you're looking for you can even copy text from it.

It's the exact type of design challenge I was looking for. First, it's a full-screen immersive app with no peers like it. There's no playbook or existing design patterns for how to design something like this. Second, there's a ton of privacy implications to ensure people feel safe using Rewind and know that they're in control. And finally, since there's no product quite like this, there's a lot of hard product design and research iteration on the journey to find our specific product-market fit.

All this to say that Rewind was exactly the kind of team and company I was looking for. The product has the potential to change how we interact with computers.

How does joining a startup relate to craft and product quality? Isn't it harder for a small company to ship well-designed, high-quality software? Aren't most startups busy scrambling to find PMF, scaling infra and putting out fires?

There's no debating one aspect of startups compared to large companies with thousands of employees: startups are dramatically faster. Faster to make decisions, plan and build. You can talk about something in the morning then design and build it the same day. No more waiting until the next quarter.

But the main reason why I think it's easier to influence quality on a smaller team is that I'm able to have a more general design role. I can be relentlessly resourceful and put the full extent of both my design and engineering skills to use. And the best unintended side-effect? I'm also learning more on the coding side as the talented engineers I work with provide tips and feedback on my code reviews.

I've only been at Rewind for a few months but this has been the exact kind of role I've been looking for for the last decade and I'm confident we're going to build some great stuff.

Quality is hard

With the right team culture, process, tool, education, and incentives, achieving a higher level of product quality should be more attainable without dramatically impacting speed of execution. I'm not saying it's easy. Quality will always be hard, but don't you want to make something great?

1,000 songs in your pocket.

You’ve probably heard that iconic marketing slogan before even if you never had an original iPod. Apple referred to the iPod as a "breakthrough digital device" when they announced it. The first iPod came at a time when the portable audio player landscape was.. nomadic (pun intended) at best.

MP3 players were already around when the iPod came out in 2001. Sales of early MP3 players were growing but they all had key limitations. You had to choose whether you wanted a smaller, flash memory player with extremely limited storage or a larger hard-drive based player.

None of them were easy to use or elegant. They were often cluttered with buttons, had subpar software and were hard to navigate. There were also other options like MP3 CD Players and Sony MiniDisc players (I loved my MZ-R70).

The iPod was different. It was a sleek, shiny stainless steel and white device the size of a deck of cards. Its stellar industrial design turned heads. This was not just an audio player you used to play music. It said something about you the same way using a Mac vs a PC said something about you at the time. You were different; maybe a creative even. You valued well-crafted products.

The iPod was a noteworthy device for a few reasons:

• Size + Storage: While there were other devices like the Creative Nomad Jukebox and Archos Jukebox with 6GB drives, they were almost the size of CD players. With the iPod you didn't have to choose between portability and storage. This was made possible by the iPod's 1.8-inch hard drive, something Apple's head of engineering first discovered from Toshiba while on a trip to Japan. Other players used traditional 2.5" notebook hard drives.
• Speed: The iPod used FireWire 400 instead of much slower USB 1.1 like competitive devices used at the time. You could load a CD onto your iPod in 10 seconds; about 30 times faster than other devices.
• Scroll wheel: This usefulness and simplicity of this cannot be overstated. I'll dive into it more later.
• Elegant industrial design: As mentioned above, this thing is beautiful. Today we'd refer to it as a brick.. but it's still a shiny brick.
• Anti-skip protection: The downside with hard-drive based mp3 players is they would skip when moved around. The iPod had 20 minutes of anti-skip protection thanks to its built-in 32MB flash memory buffer. This also had the benefit of increasing battery life to 10 hours by limiting how often the hard drive needs to spin up.
• iTunes + Auto-sync + Playlists: Apple made sure to make it known that the iPod with iTunes was the first "complete and seamless MP3 music solution." Using iTunes to manage your music and automatically sync it with your iPod was a dream compared to the clunky software required for other MP3 players. Notably, iTunes made it easy to create playlists and the iPod made them easy to play.
• Large backlit display: Featuring an LED-backlit LCD display with 160x128 resolution, the iPod could display six lines of text and song details at a glance.
• CD-quality sound: While it wasn't a huge feature of the iPod, Apple boasted that the included headphones featured Neodymium transducer magnets to help you get enhanced frequency response to get the most out of the high-bitrate songs.
• White headphones: We expect it now with Apple devices, but at the time every other device came with black headphones and a black cord. Apple knew the iPod would live in your pocket and they needed a way to signal that you had one (and of course white to match the iPod itself). The white cord and earbuds became so popular Apple leaned into them for a whole series of iPod dancing "silhouette" commercials.

All of these things combined made the iPod something the industry had to take note of. It wasn’t the most storage you could get in an MP3 player at the time¹, it wasn't the first MP3 player and it definitely was not the cheapest with it's $399 price point at launch. But it was elegant, easy to use and when paired with iTunes, it was the complete package.

Using the iPod still wasn't easy by today's standards. First off, you had to have your own music library of MP3 files on your computer. The iTunes Music Store had not come out yet, nor were there any music streaming subscription services yet. So either you purchased them on some other website, pirated them from Napster, BitTorrent, Scour, IRC, Kazaa, LimeWire and their ilk or ripped them from a CD. Then you had to connect your iPod to your computer, fire up iTunes, sync your music, then disconnect it before you could play it.

But it was a different time. Managing your own music library was a burden to be proud of. People would boast about how many songs and gigabytes their library consumed and how they organized it. They were proud of the work they put into their libraries and cleaning up their audio file ID3 tags and customizing their WinAmp player.

Music piracy was an especially hot topic at the time. The iPod included no form of DRM and received some criticism that the iPod would only proliferate piracy. Anyone remember Apple's "Rip. Mix. Burn." ad campaign? They showed the ease of ripping music to your Mac from CDs you owned. Apple also packaged the iPod itself with a sleeve that clearly said "Don't steal music." on it.

Some industry critics lamented that Apple even bothered to enter the consumer electronics space; a space where products traditionally came with lower profit margins and stiff competition. The iPod was also Mac-only at launch. Would this turn people away or convince them to get a Mac? Eventually this was a non-issue as Apple quickly began supporting Windows PCs.

Here's the iPod announcement in 2001:

Design

While clear in hindsight, the iPod's scroll wheel² was core to the success of the iPod. It flawlessly solved the problem of scrolling long lists of songs, adjusting volume and navigating menus on a small display that lacked touch capabilities. Combined with audible click feedback, it was a breeze to use.

In particular, it was easy to use with one hand. Not many MP3 players at the time were. You could raise the volume, skip a song, scrub through a song or navigate menus easily—even without looking at the screen.

In addition, when navigating menus there was a simple horizontal animation to help you understand whether you were drilling into or out of the menu. This was something iPhone OS 1 (it wasn't called iOS until iOS 4) ended up doing as well when it came out years later.

The iPod wasn't the first time a portable device had a control like the scroll wheel. For years, Sony had some variation of their—failed if you ask me—"jog dial" on devices like PDAs. However, it always felt like some afterthought bolted to the side of their devices; not nearly as precise or quick to use. And of course, Apple got some inspiration from the B&O BeoCom phone.

While iPods are long gone and all iOS devices are touch-screen now, some of what Apple learned with the scroll and click wheel evolved into the digital crown found on the Apple Watch.

It's hard to imagine today what using an iPod in the early 2000s truly felt like. It was a dedicated device, singularly focused on helping you do one thing—play your favorite music—and do it well. It didn't need to multitask or have any other complexity to function. It was simple, elegant and polished device. We don't really have things like that today. Every mobile device is meant to be flexible, multitask and do just about anything for you, lending them to be more like a jack of all trades, master of none.

Finding an iPod

I have always admired the first iPod.³ In 2002 I purchased the second-generation 10GB iPod. I was in the middle of high school and that was a hefty purchase for me.

The second-generation iPod was nearly identical to the first-generation iPod except for more storage options (10GB and 20GB) and minor physical changes (notably, a touch-sensitive wheel replaced the mechanical scroll wheel, which was prone to getting dirty and requiring cleaning).

I eventually dropped that iPod with headphones plugged in and it broke the headphone jack. I opened it up, soldered it back on and unfortunately sold it. I’ve missed it ever since.

Earlier this year I began my search for a second-generation iPod like the one I had. I thought about looking for a first-generation but honestly I did not like how they had a piece of white plastic near the ports instead of the metal backing and was concerned about the high probability of the mechnical scroll wheel having issues.

If you decide to do the same⁴, I can offer a few suggestions. First, we are talking about a 20 year old device (older if you opt for a first-gen) so you should be concerned about the state of the battery and hard drive. It's quite common to find people on eBay selling iPods where they've already replaced the battery, so that might be of interest if you don't want to do the work yourself or have to deal with it later.

Of course, the vast majority of the early iPods you see for sale will have tons of scratches and maybe even some dings. That's to be expected for such an old device, unless you plan on spending much more on a near-mint model; I even saw one selling a never-opened, sealed box iPod for $10k! However, since the front of the iPod is just plastic, a devoted owner can find specific polishing compound and significantly restore the faceplate to its former glory. It won't be perfect (at specific angles you may still be able to see the original scratches) but you likely would not be able to tell from eBay pictures.

After some months of casual searching I finally found one on eBay in good condition with a newly replaced battery that wasn’t outrageously priced. I paid about $190 including shipping.

Connecting and using the iPod

A few days later my new-to-me iPod arrived!

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

Would I even be able to connect this FireWire iPod to my modern M1-based MacBook Pro running macOS 12? Not too long ago Apple Music (née iTunes) stopped syncing iOS devices and that functionality was moved to the macOS Finder itself.

All I needed to do was find a way to connect FireWire 400 to Thunderbolt 3. This took quite a few adapters and dongles:

• Thunderbolt 3 to Thunderbolt 2
• Thunderbolt 2 to FireWire 800
• FireWire 800 to FireWire 400 (couldn’t find an Apple adapter, got one from elago)
• FireWire 400 6-pin to 6-pin Apple cable

These dongles definitely add up in cost, though I got at least one of them used on eBay. In total, I paid just under $90 for all of these. I had another FireWire cable that would have worked but I was seeking an authentic Apple cable. All-in this iPod setup cost me about $280. Worth it? Absolutely.

Fortunately, it worked flawlessly after I connected everything. After a brief moment the iPod showed a "Do not disconnect" message and the Finder app in macOS displayed the iPod: both as an iPod and as a connected hard drive.

Selecting the iPod in Finder, you have the ability to sync music, podcasts and more. It's pretty basic and just loads up audio files it detects from your main Apple Music or Podcasts apps. Of course these are only for actual files you have; not for any music from Apple Music's streaming service for example. I selected a few podcasts and synced them. A few moments later I was listening to them on the iPod.

After syncing was complete, I ejected the iPod from Finder and removed the FireWire cable.

It took a moment to remember how to turn on the iPod. I had to turn off the Hold switch and press a button to wake it up. Then I navigated some menus to find a podcast to play. Scrolling line by line with the scroll wheel with its audible feedback was so satisfying. All the nostalgia came flooding back.

Then I heard the tiny 1.8-inch hard drive whir to life. I can't remember the last time I used a device with a spinning hard drive like this after so many years of using devices with SSDs. Though, at the same time I was a little bit paranoid about using a portable device like this with a spinning disk that felt so delicate.

Of course there’s no Bluetooth with the iPod so I found my AirPods Max 3.5” minijack to Lightning cable to connect them:

Impact

There's no need to state how influential the iPod went on to become: for Apple, for the industry, for pop culture and more. The first iPod is even in the Museum of Modern Art now. Some 450 million iPod devices have been sold.

Apple unveiled the iTunes Music Store about 1.5 years after the first iPod. It became dead simple to select a 128kpbs AAC song from their collection of 200,000 songs (today it's 43 million) at launch, pay 99 cents to download it and then sync with your iPod to have on the go.

The easiest way to fight piracy was with convenience and Apple really showed how powerful a complete package could be: elegant portable audio device, great music library software and a robust integrated music store.

The iPod wasn't the first MP3 player but it's impeccable industrial design, novel software and overall execution made it iconic.

What's next?

There's a lot of other interesting early Apple devices³ that I'd love to collect if I had the space but this iPod was the perfect start. I'm also a fan of the first-generation iPod Nano. If you're looking to get a taste of iPod nostalgia that might be an easy place to start. It was flash-based and had a USB connection.

Though I'm really curious about the tiny third-generation iPod Shuffle. It was poorly received due to its over-minimalism and lack of controls on device (Apple pushed the use of remote buttons on the headphones cord along with VoiceOver navigation).

Footnotes

1 A now-infamous comment about the iPod at launch was on the popular site Slashdot: “No wireless. Less space than a Nomad. Lame.”

2 The first-gen iPod had a mechanical scroll wheel while the 2nd-gen had a touch-sensitive scroll wheel. Later iPod generations called it the click wheel when the menu/skip/etc buttons were merged into the wheel itself.

3 In addition to most early Apple products, I'd love to own a Macintosh Centris 650, Apple ][, Macintosh Color Classic, Macintosh SE, G4 Cube, iMac G4, QuickSilver PowerMac G4, PowerMac G4 MDD, Clamshell iBook G3 laptop, 12-inch and 15-inch Titanium PowerBook, eMac, iMac G3... the list goes on. I have fond memories of using several of these machines many years back.

4 There's a whole community around iPod modding. People love to convert them to use SSDs instead of HDs, change the case and more. For example, the last generation iPod (the sixth-gen officially dubbed the iPod Classic, though you can also refer to all six generations as iPod Classics) can even be modified to add Bluetooth. I'm curious to look into converting mine to using an SD card for storage.

Early adopters face foreign terminology, complex UIs, unexpected and exorbitant fees, security issues, slow transactions, confusing errors, scams and more. That makes for one hell of an onboarding, even if you're lucky enough to have a friend showing you the way.

This is the state of crypto today. That can work for now—early adopters are motivated enough to jump through hoops to try something new—but this won’t scale as billions of users join the crypto ecosystem in the coming years.

But this is all known; there are many new technologies and protocols vying to evolve, change or fix things. I’m most interested in the design side of things.

Can we even design truly great experiences for common activities in crypto today? Does the underlying tech have to evolve significantly first? What's the best we can do with today's technological constraints?

The crypto users of tomorrow will have different motivations and expectations than the early adopters today. They won't put up with clunky, confusing, unreliable, unsafe and expensive systems. Great design—for wallets, exchanges, identity, dApps, marketplaces, DeFi and more—will be the bridge to help get us there.

Everyone likes to say that in the future maybe crypto users won’t even know they’re using crypto; that the blockchain and complementary systems are just the technology powering everything behind the scenes. We can only get there if we design for trust and use that as a critical lens through which we analyze every aspect of the crypto experience today.

Designing for trust

So you might be thinking.. okay this is totally wrong and even the Bitcoin whitepaper established that cryptographic proof should be used instead of trust for decentralized systems. And that the ethos in the crypto community today is "Don't trust, Verify."

Yea, that's all true. But what I'm talking about is one level up than the blockchain itself. I'm talking about the interfaces people interact with to do what they need to do, which may happen to be directly on or indirectly related to the blockchain. It's about elevating context and providing signals about their interactions so they can feel safer to make decisions about what actions to take and which actions to avoid.

Public blockchains like those that power Bitcoin and Ethereum are permissionless. Lack of trust, centralized servers and third parties is a feature. They're entirely open networks where any participant or machine can see what's happening. While this leads to a level of trust with the ability for anyone to track and verify all transactions, that’s where the trust ends.

As active web3 participants¹ we regularly interact with dApps, smart contracts and more that we should not simply trust by default. But there’s also a person's trust of the blockchain itself. Ever had a transaction fail due to gas issues? Or new tokens you just sent to your wallet from your exchange not appear in a timely manner? Issues like this won't inspire much confidence in crypto for new users.

A great crypto experience² designed for trust will help you make an informed decision by elevating all the information you need, especially if that information comes from multiple places. I’ll dive into that more a bit later.

What we can do today

One of the reasons I'm so excited about web3 is that everything so desparately needs design help that almost any attention to detail anywhere in any common flow would be tremendously valued. It's like getting in on the ground floor of helping define key interactions in browsers, email clients and other core tools during the formation of Internet.

You can design how people interact with anything related to the blockchain: wallets, exchanges, dApps and more. You could have a lasting impact in a ridiculously fast growing space.

Crypto has been around for about a decade—long enough to prove there's something here and see growth but still nascent enough that there's plenty of things left to figure out, define and invent. How often do these opportunities come around?

But I digress..

Today, we can get very familiar with the technical constraints of crypto systems and design for trust and clarity over all touchpoints of someone's journey. This article is in no way meant to be a complete overview of all design challenges in crypto. I wouldn't be able to write that; this is just meant to highlight a few areas that have been top of mind for me.

There's several high-priority areas to explore starting when someone first hears about crypto to learning about how and where to use it but I'm most interested in these:

• Exchange experience & Onboarding
  As hundreds of millions of people interact with crypto for the first time, it's very likely that their first experience will be with a centralized exchange where they can exchange their local fiat currency for their first Bitcoin, Ethereum, stablecoin or other crypto asset. There's lots of responsibility and opportunity here to set new users up for success.

• Wallet experience
  For some, just holding crypto assets may be enough, but many will be drawn to all that web3 offers from various dApps to NFTs and more. A crypto wallet is the passport to web3 and making it clear how to set one up, become familiar with connecting to other services, dealing with transactions and more will be a key experience to get right.

• Web3 guidance & curation
  This is the discovery phase for slightly more advanced users that are now asking "What can I do with my crypto?" There are opportunities to help people discover what exists, what is safe to use and guide people along the way. It's 1998 and people rely on AOL or the Yahoo! homepage to show them what's out there. What's the curated search engine for crypto?

  There are a few projects in this space like Rabbithole.gg, Zapper.fi's Quests and Layer3.xyz, though I think most of them are a bit too complex or don't yet do a great job yet on educating behind why someone would want to do a certain task. Another interesting one is Context.app, helping with NFT discovery.

I also think there's a huge opportunity around decentralized identity; I touch on that a bit in the next section.

Exchange experience & Onboarding

In the coming years, hundreds of millions of people will interact with cryptocurrency on-ramps—exchanges and similar services where they can receive their first cryptocurrencies and other crypto assets. For most people, this will be with a centralized exchange (CEX). Exchanges will be most people's first time truly interacting with crypto. Exchanges will need to simplify, educate and guide these new users every step of the way.

Exchanges should explain the difference between different types of cryptocurrencies (including stablecoins), potential for volatility and potential for utility of each type. They should equip people with a basic understanding of security should they transfer their assets to a wallet outside the exchange.

But before all that, there's a lot of opportunity to simplify the required KYC ("Know your customer") flows that require you to verify your identity. There's nothing easy about these flows as they require a tedious process of uploading photos of your id. Even small enhancements like integrated camera flows instead of requiring switching to the camera app, letting you easily resume onboarding if you're not in a place to do this yet (send me a reminder push notification in X hours) or letting you setup the rest of your account and upload your id when you can later would be welcomed.

At some point these people may want to do something more than just buy or sell their crypto. Exchanges can educate around dedicated, non-custodial wallets. Even small things like transferring Ether to a new wallet can be daunting. Exchanges can also begin to set the expectation that outside the exchange, transactions are usually not instant and that depending on the service, sometimes require significant fees and time.

I could go on and on. So much opportunity here.

Wallet experience (Transactions)

Wallets started out as only being responsible for managing and facilitating basic crypto asset transfers. Today they are responsible for a whole lot more. Modern wallets deal with showcasing NFTs, all sorts of tokens, dealing with complexities related to separate blockchains and Layer 2 assets, token swaps, connecting with dApps and more.

Wallets are a frequent and primary touchpoint for interacting with countless web3 services, protocols, other wallets and more. Designing for trust inside the wallet is of prime importance. There are no gatekeepers with decentralized services; just a lot of entities you'll individually interact with. As such it’s important to make it clear exactly what’s happening each time you interact with another user, smart contract, dApp, et cetera.

A core part of all wallets is a way to list transactions. Too many wallets today treat this as a list of data without much thought about what it means for the user and within the context of trust.

Here are a few things I've been thinking about in regards to displaying transactions and assets:

• Be hyper transparent around transaction status. We expect things today to be instant but the blockchain is one of the only pieces of modern technology that can feel very slow at times. We need to take great care in displaying transaction status. The average user should never have to visit Etherscan/Polygonscan/etc just to see how much time is left with their transaction. There should never, ever be any doubt in their mind about what's happening to their money or transaction.

  A basic "sending/pending" state is not enough. Can you imagine not having a progress bar when you were downloading an mp3 on dialup in the '90s?

• Make errors actionable. One of the most frustrating things is when a transaction fails. It's annoying, sure, but with Ethereum transactions it also probably means you lost a lot of money in fees! Elevate as much of the error messaging and description as possible to the user. Suggest solutions the user can take if feasible, such as trying again but with more gas if that was the reason it failed.

  Show me how much money I just lost on gas with this failed transaction. Don't make me go to Etherscan to try to piece it all together; it can be rather confusing to discern on Etherscan with gas price, transaction fee, gas fee and gas usage, especially with EIP-1559.

• Show more context. Transaction data is far too cryptic today. Any way to add further context and humanize is needed. See if there's ways to display social proof.

  Who, what, where, when.. I received an NFT from an OpenSea contract, which I've used and trusted before. Or show that I swapped a token via Uniswap. Did I receive an NFT from a smart contract or another wallet? Show me a visual preview in the list of transactions, along with any indication of the other party (be it an OpenSea logo/name, or associated ENS name and avatar).

  This can be taken much further, but may be better suited for future solutions where your wallet may be paired with a robust knowledge graph.

• Inform and put the user in control. Letting a user select how much gas to pay for a transaction is not enough. What other context can be provided to help them make a decision?

  For example, if they are interacting with a smart contract to obtain an NFT and the contract has a ton of pending transactions, maybe the wallet could see how many NFTs are left by checking the contract's remaining supply, see how many pending transactions would be ahead of them and try to roughly estimate how much gas may be necessary before the NFT supply runs out.

  Or perhaps the wallet could see how many recent transactions with the smart contract with other wallets failed, potentially hinting that this contract should not to be trusted (like those scams where it tries to get people to visit a website) or has other issues.

  Create first-class experiences around speeding up a transaction. If I have multiple pending transactions with the same smart contract, show me how this affects the queue and the position of each.

  These may be contrived examples but the point remains. Approach this with a user focus, think about what people may need or want to know in the moment and try to bring it forward.

• Make transaction state global. Wallets today are not simple single-page apps. They often have multiple tabs or sheets, they could have various sheets and they can be closed or collapsed entirely. Most people will want to know the status of their pending transactions at all times, regardless of where they are in the wallet. Make it easy to see status from anywhere, including using actionable in-app toasts or browser/app push notifications when it makes sense.

  A simple analogy might be a macOS menubar app like Google Drive. At a glance I can see that it's busy syncing files or that it's all done and at rest. I don't have to go anywhere or do anything to see its state.

• Give me an "oh shit" undo/cancel button. It's all too easy to make a mistake. Scenarios like trying to ape into a new NFT drop unfortunately mean that speed is the only way to have a chance.. but speed also means you might not be taking the time to think through your actions.

  Did you accidentally approve a token on a contract you probably shouldn't have? Unfortunately, scenarios like this happen more often than they should. Wallets need an emergency resources in times like this. Perhaps modern wallets could have a sort of emergency "oh shit" button.

  A button like that may try to pay the necessary amount of gas to quickly cancel that pending transaction before it's estimated to go through, or try evasive maneuvers like start moving your highest value tokens to a newly-created wallet on your behalf with extremely fast gas. I'd happily eat a huge gas fee if it meant saving much more valuable assets in an emergency.

  These are just a few examples, but there are lots of ways to interpret designing experiences to guide users when things don't go down the happy path.

• Show all assets across all networks/chains. A lot of things are being built on various blockchains and Layer 2 networks. With the exception of testnets, there's no need to require switching between the Ethereum mainnet and Layer 2 networks like Optimism and Polygon. Just show everything together. It's so annoying to hunt for your assets and forget what network they're on. Modern wallets like Rainbow Wallet do this today.

  Furthermore, more wallets should support multiple blockchains such as Avalanche and Solana. This is a tremendous amount of engineering work, so it's not to be taken lightly.

  Why should we put the onus on new users to know the difference between various blockchains/Layer 2s and know what their wallet can and can't support? It's already hard enough to explain how to safely backup a seed phrase. This lets the people use whatever web3 service they want with minimal overhead.

Wallet experience (Security)

And then there's a whole realm of things related to wallet security that could be made easier to access, control and understand.

• Make it easier to disconnect your wallet from connected apps and sites. Could a thoughtful implementation have preferences to enable automatically disconnecting after a certain time period, prompting you to disconnect older connections or only allowing a limited number of connections to be active at a time?

• Introduce education and user controls for token approvals and token allowances. This one is for the more advanced users today but it really shouldn't be due to the security implications. When interacting with a dApp that needs to access your tokens, you need to give the smart contract approval to use your tokens. Usually this allows unlimited use of all of your tokens and pose a risk where your tokens can be taken without further approval. It's a best practice to remove token approvals for services you no longer trust or use. Similar to removing OAuth permissions on your accounts.

  Services like Revoke.cash and Token Allowance Checker exist for this purpose but this could be easier if part of the wallet experience. Some services like Zapper.fi have their own way to adjust allowances. Needless to say it could all be easier. You can read more about the topic here: Unlimited ERC20 allowances considered harmful.

• Demystify common actions like connecting a wallet and signing a message. After you've used a few dApps, it becomes very common to see a lot of different dialogs you need to accept or confirm. This makes it all too easy for someone to absent-mindedly get into a habit of accepting these without quite understanding what's happening.

  Can modern wallets help educate customers about the risks associated with each action and provide ample recourse to undo them? Today, if you accidentally accept a dialog, most wallets don't make it clear what you need to do to be safe, or if there is any risk from the action you took.

  The team behind the WalletConnect protocol is working on a concept to merge "accept connection" and "sign message" that may only work for trusted apps and/or require strict restrictions.

What we can do tomorrow

Dealing with existing technical constraints can definitely feel like we're putting lipstick on a pig. If we put some of these shortcomings off to the side and consider a future wallet, things get a bit more interesting.

Here are a few potential areas of explore going forward:

• Fix wallet addresses. Every crypto user deserves an easy way to reference their wallet. ENS is the current solution and it works (I love it and have several, including stammy.eth), but it's not easy for a newcomer to setup, requires fees and has a small namespace where their ideal handle/domain is likely already taken.

  The next billion crypto users shouldn't have to pay to make crypto usable. They shouldn't have to deal with long addresses that could lead to huge issues like them losing funds. What's the Gmail of wallet addressing? What if you could pick from several providers for a free shorthand address for your wallet? If you want pay for yourname.eth, thats fine. But that's not for everyone. Could it be closer to email or ENS subdomains with providers you want to use or affiliate with like stammy.exchange.eth or stammy@MyDAO.

• Is wallet the right word? One challenge is that we’re designing for crypto as if it’s purely money (and maybe some NFTs) in a wallet. But the role of the wallet is growing and in the near future it will be so much more than that. Your crypto wallet can become your identity, your interests, your preferences, your knowledge graph, your communication. Perhaps we need a better word to describe its expanded role and control.

  Websites are more frequently allowing you to "connect wallet" when often they mean just login. Connecting your wallet with your money can sound scary. Which brings me to the next point..

• Clarity & control around privacy and public assets. It takes some getting used to having all your assets publicly visible by anyone on the blockchain if they know your address. This is going to shock a lot of people when they first setup their wallet. Can you imagine paying a stranger for a coffee and them instantly being able to see all of your transactions and holdings? Creepy. But that's what the blockchain enables.

  Advanced users today get around this by maintaining multiple wallets, but surely we can't expect everyone in the future to know how to do this on their own. Even then it's not hard to track transactions if you accidentally transfer anything between the two wallets instead of using an exchange for that.

  One partial solution is better wallet education and integration for supporting private-focused coins like Monero, Zcash and Mobilecoin. That's fine for things that can be done privately, but you can't exactly use those for other cryptoassets like NFTs or particular tokens. So what's a more robust solution?

  What if the wallet itself was safer by default? What if connecting your wallet to dApps was able to facilitate logging in, but by default did not show any assets. Depending on your permissions, the wallet could then allow exposing the wallet address where your assets actually live (potentially spread across multiple). Almost like Apple iCloud Private Relay for your wallet. I'm sure there are numerous technical and security feasibility issues with something like this, but I'm just trying to paint a picture of where we could aim in the future.

• Make it smarter, make it safer. Today “Connecting with wallet” is very convenient but very dumb. The dApp you connect to gets a unique identifier and some basic info about your holdings but not much else.

  How can we attach a knowledge graph to the wallet? A set of public and private preferences, a list of friends, a list of dApps you trust and how much, a list of blocked addresses, dApps and more. This graph data would ideally be a mix of public and private data stored off-chain.

  Not only is this getting at a basic storage system for each wallet, it's also getting at the start of a robust permissions system.

  But the real super power of an approach like this? It can bootstrap all sorts of trust and security signals. You could see that 7 of your friends have used this smart contract before and didn't report any issues, so you can trust it yourself too.

  You could block or report a token as being a scam and it would instantly be hidden for your friends too. You could follow curated blocklists from entities you trust to make web3 safer for you. If anyone steals an NFT the community could blacklist it quickly enough that all NFT marketplaces could prevent any sale of that asset. There's so much potential here. Companies like SpruceID and idx are exploring related things today.

What else?

It's such a promising time to be using web3 and especially working in web3. We haven't even seen the killer apps of crypto that will bring waves of people into crypto.

This article was only meant to touch on a few areas where design help is especially needed, and from a design-only POV. I'm sure there are astounding technical challenges as well that may lead to varying alternative solutions. But it's exciting to be here while it's all getting figured out.

As a designer, I love to abstract complexity away from the user by relentlessly questioning what part of an interface is even necessary to present to the user and what we can automatically do for the user.

However, this will be one area we'll have to be super careful about with crypto experiences. Crypto is different. It's not like yet another Web 2.0 experience where abstracting things away (and likely putting that power back in the hands of the app/service). Web3 is about putting the user in control of their data and assets; giving them ownership, not taking it away.

"Once understood, crypto is powerful in its simplicity. But it actually becomes more complicated the more you bury it under layers of abstraction. It’s clear to me now that the technology wants to be seen; it wants to be understood."

—"Crypto Wants To be Seen"

With that, we'll have to be careful about introducing thoughtful abstraction—simplifying and hiding complexity without diluting the essence of web3 or taking away control when it might be valued.

Examples of these types of decisions ahead might include:

• Do we hide that your wallet is non-custodial and introduce alternative recovery mechanisms? Or just do a great job at teaching people how to backup their key and understand the importance of that key.

• Do we try to hide that there may be multiple Layer 2 networks you're interacting with and automatically try to use the best network for the task at hand? Or focus on educating around what Layer 2 bridges do, the benefits of Layer 2 networks or other blockchains and provide transparency around where your assets live.

These are the kinds of details we'll have to figure out before we can get to that idealistic goal that everyone loves to talk about; that someday people won't even know they're using crypto. Is that even a goal? Or should we educate and empower people to embrace all that crypto and web3 have to offer? Of course, we'll need to fix a few things first..

There's a lot of noise in web3 today. It's hard to know what technology, dApp or community is healthy and valuable. We need to build experiences that act as a great host to new users as if they had a web3 expert friend next to them guiding the way.

Maybe we can get there if we think about designing for trust. People trust other people and if web3 is all about decentralized networks, maybe we need to start tacking on more of those networks to the daily experience to help guide, secure and curate.

Footnotes

1 I basically use the terms crypto and web3 interchangeably in this article but I realize there is nuance between the terms. Web3 tends to refer more towards the broader ecosystem and decentralized nature of how these systems work.

2 I reference "great experiences" often and I know it's vague but there are so many things it can apply to: getting your first crypto, swapping tokens, connecting your wallet with a dApp, sending crypto to someone else, et cetera.

3 For the sake of simplicity, lets table the discussion of Layer 2 networks and alternative, faster blockchains like Solana. The current state of Eth gas is untenable and hopefully a multi-chain/L2 future full of composability can abstract away all the rough parts here. Even today the L2 experience is poor; I've watched friends click around for hours frantically trying to find their assets, forgetting what blockchain and L2 they had it stored on.

4Another problem lies around proactively providing signals and controls to help users assess whether one of these entities can be considered trustworthy or not, but I'll mention that in the next section.

5Which thanks to ENS .eth domains it's really not that hard to find someone's wallet.

I first dabbled with cryptocurrency in 2011 when I wrote an article about mining Bitcoin on AWS EC2 GPU clusters. My interest in crypto ebbed and flowed over the years before actively avoiding the space until earlier this year. It felt like there was a lot of noise and hype around volatile, speculative asset holding and not much innovation happening.

It wasn’t until a few months ago that I began to take a closer look at the state of crypto and see how much the landscape has evolved. The big thing for me was seeing how the blockchain has become programmable with smart contracts, little pieces of automatically-executing code running on the blockchain.

The new functionality afforded by smart contracts, along with the relative consumer ease of simply being able to connect your crypto wallet with any decentralized service and be able to quickly interact, has led to a flurry of new product developments. Most of these are categorized under the moniker dApps (decentralized applications that run on the blockchain or in a p2p capacity). A large chunk of dApps are in the so-called DeFi, or Decentralized Finance, space (yes, there's lots of terms and abbreviations in the crypto space). I wrote a brief thread about what I learned about crypto and DeFi my first few weeks diving into it.

Ethereum was much more interesting to me now than Bitcoin. So much is being built on top of it with smart contracts and other Ethereum-based tokens. There are crypto-based games like Axie Infinity, robust decentralized exchanges like Uniswap and Matcha.xyz, to communities and DAOs built around their own tokens like FWB and Kong.land. There's far too much activity going on for me to accurately summarize the different types of innovation happening here and I'm definitely still learning myself.

NFTs are one particular realm of the crypto community that has been experiencing stratospheric growth over the last year. By now you’ve probably heard about them in some form. It could have been the news of digital artist Beeple selling his NFT artwork for $69 million dollars. Or maybe the news of Figma founder Dylan Field selling a CryptoPunk NFT for $7.5M.

NFTs are approaching mainstream status now—Paris Hilton sold her own NFTs, Jay-Z bought a CryptoPunk for $126k for his Twitter avatar and NBA player Steph Curry bought a $180k Bored Ape NFT for his Twitter avatar and even Mila Kunis and Ashton Kutcher launching NFTs that unlock TV show episodes.

One thing that stands out to me about crypto now, as opposed to the last time I was involved years ago, is that you can actually do stuff with your crypto now.

Before, it seemed like the most you could do was hold on to your crypto as an investment, sending it between wallets, or exchange it back to your local fiat currency. Now, people are able to spend their crypto.. largely on other crypto dApps or into the hands of creators with NFTs. And most of those people will continue investing in and building for crypto and decentralized services, so things continue growing and evolving.

However, all the press around NFTs reminds me of the hype around ICOs and speculative asset hodling of meme coins.. are NFTs just the latest example of a fleeting crypto fad?

What are NFTs?

Digital art, collectibles, identity, tickets and more..

I didn’t really get NFTs for a long time.. and honestly I don’t even know if I fully understand them now. Can’t someone just screenshot the NFT you paid a bundle for and have the same thing you have? That's the common question you hear from anyone when they first hear about NFTs.

That's like seeing the Mona Lisa in person, taking a photo, turning that into a print on your wall and saying yours is worth the same. It's not the original. With the public nature of NFTs on the blockchain, it's easy for anyone to verify who owns it, who has owned it and when it first appeared. Anyone can look up your wallet address (or more recently ENS domain name if you set one up) to see what NFTs you own.

But let me take a step back for a moment..

NFTs are unique, non-fungible tokens on the blockchain. Regular cryptocurrency tokens like Ether or other Ethereum-based ERC20 tokens are fungible and can easily be traded and swapped for one another. They're all the same thing.

By contrast, each NFT has a unique identifier allowing it to be paired with metadata that cannot be changed. While an NFT can be sold and transferred like any fungible token, each NFT has its own unique value and worth. This identifier also makes it possible to trace the ownership history for the NFT. It's also possible to prove the scarcity of an NFT and know how many of a certain type exist and how many can exist.

Being able to programmatically prove ownership is where it gets interesting; NFTs can also be used like keys or digital tickets to unlock certain functionality, experiences, membership, events and so on.

And an NFT can never be taken from you. There is no middleman. This is not like Amazon being able to remotely delete a Kindle book you purchased because they want to. No one can take your NFT from your (non-custodial) wallet.

These traits of NFTs lead to some unique value propositions and capabilities. They can be used for digital art, content, collectibles and gaming but they can also be used for utilities like .eth domains like with the Ethereum Name Service or even tokenized real-world assets.

NFTs are status, identity, community, self-expression, access and more.

I could go on and get philosophical about the different ways NFTs provide value, but I'll leave it at that. The value of an NFT always depends on what someone is willing to pay for it. The market always wins as they say; NFTs are no exception. Fortunately, now that market is open globally 24/7/365 and has a quick payment system. Not quite like the old days of trying to sell your Magic: The Gathering cards in person and not finding any buyers (just me?).

Even though NFTs have been around in some form since 2012 and then more media-focused from 2016, it's still very early. I’m sure we’ll continue see a significant evolution of how they are used and how they are valued. Right now NFTs may get a bit of a mixed reputation due to the high level speculation on collectible assets and many buyers trying to quickly flip NFTs that are part of a limited set.

There are also private communities focused on investing in NFTs that have been growing, such as with PleasrDAO and Flamingo DAO. While Flamingo DAO has done very well with their NFT investments so far, having experienced a 40X gain and owning NFTs worth $1B+, they take a longer view on what NFTs can provide:

The growth of NFTs is just beginning, because NFTs represent the digitization and financialization of digital property and intellectual property. Trillions of creative works swirl around the Internet and are difficult to monetize, except through licensing models. NFTs hold out the hope of bringing back to the Internet an ownership economy. Creators can create, sell, and fractionalize ownership in their works, opening up a new chapter for creative endeavor. NFTs can be:

• fractionalized
• combined into token sets
• used as collateral for lending and stablecoin protocols
• dynamic and interactive, incorporating outside data feeds

Over the longer arc, NFTs hold out the hope of becoming increasingly financialized, interacting with other core blockchain-based financial primitives. They may prove to be a core primitive for decentralized identity solutions, and may increasingly serve as a cornerstone for monetizing emerging metaverses and other gaming platforms.

— What is Flamingo?

Whatever your thoughts are on NFTs, it's hard not to pay attention to what's happening in the space. I very often think about how the next big thing will start out looking like a toy in the context of everything happening in crypto now, like the early days of the Internet.

Common types of NFT projects

10k PFPs, collectibles, games and more

With the basics out of the way, lets see what types of media-focused NFTs and cryptoart are common right now. First off, we have the very popular so-called “10k PFP” collections. These are sets limited to 10,000 media assets geared towards being used as a profile picture, usually because the image looks like some kind of being: human, alien or otherwise anthropomorphized entity.

There are the popular ones like CryptoPunks and Bored Apes and then there are the many derivative collections trying to capitalize on these types of sets. Owning an NFT from one of these collections has led to being a new sort of status and community.

There are interesting trading card-like NFTs like Parallels and gaming NFTs like Zed. And then a section of the NFT space that I'll just call experiments because I'm not sure what else to call them. Things like Blitmap, Loot and Tunes Project that test the waters of how certain types of NFTs can invite others to build on top of them. In this case of Loot, building a whole game ecosystem with characters, loot, music and more.

And of course, there's a ton of NFTs that encompass all other forms of art. It has also been inspiring to see artists adapt to the new format and reap the benefits; getting paid more easily and generously than previously. There are computer-assisted artists making 2D and 3D creations by hand and there are all sorts of artists making digital versions of their hand-made creations. There's even a painter selling NFT sketches that come paired with an offer to unlock a physical painting, shipped to whoever owns the NFT during a particular time each year.

But there’s one type of NFTs that I became particularly fond of: generative art. Generative art can be defined in many ways but at a high level it's any art that was created in part or in whole with the artist being hands-off and having an automated computer system or program do the rest, leading to each creation being entirely unique.

One of the popular players in this space is Art Blocks. This example below sold for 777 ETH (around $2.5M when it sold):

Wow... just shocked. When I set this price (yesterday) I didn't really expect it to sell this quickly. Thank you @tylerxhobbs for your fantastic work. I will certainly reinvest this in new and upcoming artists / donate a portion to charity. 🙏🤯 https://t.co/rbaJQ73D48

— Kevin Rose (@kevinrose) August 25, 2021

Making my NFTs

How I got inspired, built and listed them

I knew I wanted to get involved with NFTs somehow. Over the past few months I had been seeing designers I follow experiment with and find success creating and selling their own cryptoart NFTs. Friends and family had been suggesting I do something with NFTs; I just didn’t know what.

I’m a designer and developer but my forte is definitely not the type of graphic and 3D design I had seen as being common with NFTs: detailed illustrations, 3D concepting/rendering and 3D animation. I didn’t want to design another collection of PFPs. It had to be something that I could feasibly write a simple program myself with regular web and mobile languages I already know.

I thought about picking up Processing, which I had last touched in college more than a decade ago, and making some art out of things like Conway's Game of Life and other cellular automata. But I didn't find that to be particularly aesthetically pleasing or how I could make it pleasing.

I began thinking about modern, abstract art I like, wondering if I could do a "crypto" take on that. I like geometric art and something with simple geometric shapes would be feasible for me to code with regular web/software technologies I already know. And hopefully by being heavily inspired by existing traditional artwork, these NFTs would might already feel familiar to viewers.

A few years ago I visited Amsterdam (my photoset) and visited museums like the Stedelijk Museum of modern and contemporary art where I had seen lots of De Stijl pieces. Piet Mondrian's compositions came to mind along with pieces by Gerrit Rietveld.

I decided to try writing some code to generate Mondrian-inspired art that would be unique each time I ran it. But I wanted to make it feel like what crypto feels like to me at first glance. I think Mr. Robot, Shadowy super coders, dark web, The Matrix, Blade Runner, Altered Carbon, Ready Player One.. lots of neon colors, glows and darkness.

After I had a general idea of what I wanted to create, I thought about how to build it. I knew I wanted to do a limited set, something under 1,000. I figured 100 would be a nice way to get started and test the waters. Just enough that I would need to have whatever code I wrote be able to export directly to PNG. I didn't want to hack around with taking screenshots for each of them.

I decided to start by making a simple HTML page that used canvas and JavaScript to create the art and easily let me export the canvas. I had become familiar with canvas recently when making the Stocketa site:

Spent a good chunk of the weekend building out the last bits of the new @StocketaApp website. Happy with how it's turning out... will probably deploy later tonight Used Canvas to composite JPG frames (for smaller size) using PNG masks (for alpha) for Apple-like 3d scroll effect pic.twitter.com/2OBNhIR3y8

— Paul Stamatiou (@Stammy) April 20, 2021

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

After a Sunday afternoon of tinkering, I had a working concept. Every time the page loaded, a new random design would be created. I used the localStorage API to keep track of views and name each file for export, which I would simply do via a download button on the page. I was too eager to get this out and didn't spend much time on additional code to automate things.

Much of the code revolves around randomly selecting the number of iterations to complete, what color palettes to use, modifying colors and the intensity of the glows. Some of them used color palettes of 3-5 colors I put together myself, while others I had the code pick from a random color and then find pentadic, tetradic or triadic colors to use or use varying alphas of a single color. Figuring out the colors took a decent chunk of time and I think there was still some room for improvement. I ended up having around 15 different color palettes I was having the code randomly select between at one point.

This is what it ended up being—a simple HTML page with a few hundred lines of JavaScript and a download button to export the canvas to a 4800x4800 PNG.

One issue I ran into and was with color profiles. Dealing with very saturated colors and lots of glows, I wanted to use the P3 color space instead of sRGB, which was the default color space/profile when exporting the contents of a canvas. This is something I became quite familiar with years back when writing my post about building a Lightroom PC.

Relying on sRGB meant some visible color banding that annoyed me. Unfortunately, it seemed like this was out of my control and it's not yet possible to specify a color profile for canvas to use when exporting after a cursory investigation. It wasn't a huge issue, so I moved on.

Publishing PNGs as NFTs

Now I had a pile of PNGs and needed to list them for sale as NFTs. This started out as a small project so I just wanted something very turnkey to manually list each piece. I already knew I wanted to use OpenSea. It's hard to look at NFTs online and not come across them; something like 98% of all NFT trade volume flows through OpenSea.

The other nice thing about OpenSea is that there is no cost to the seller to mint each NFT. There's a one time gas fee the first time you sell anything but I had done that a while back with another NFT that I'm not even sure how much that cost.

Minting an NFT is the process of putting your art/media and its associated metadata on the blockchain by creating a new, unique token (usually ERC-721 but there's a newer format called ERC-1155 that supports both non-fungible and fungible tokens). In my case, I would be putting these on the Ethereum blockchain. It's also possible to mint on other blockchains for lower costs, such as the Ethereum-compatible sidechain Polygon, or a faster blockchain, Solana, but that's outside the scope of this article. For now, we'll stick with Ethereum. It's currently the most popular for NFTs.

If I was doing a much larger NFT project, I would probably spend a bunch of time and money developing and deploying my own smart contract on Ethereum. NFTs are minted through a smart contract, small bits of code running on the blockchain itself. Owning your own smart contract gives you complete control over your NFT collection and doesn't delegate any control over to a NFT marketplace. It just costs a lot to develop and deploy (for example, I tested deploying a simple smart contract and the estimated gas fees required to publish the smart contact to the Ethereum blockchain were around 0.25-0.35 ETH or ~$1,000).

This is a growing space so you're at no shortage of options for how you want to publish your NFTs from Nifty Kit, Bitski, Foundation, Rarible, Zora.co, UNifty.io, Showtime and many more.

Listing on OpenSea

So I ended up sticking with OpenSea: easy to get started and no fees to mint NFTs, but they take a 2.5% cut on each sale. Other marketplaces like Foundation require you to pay gas to mint each NFT, which can get expensive quickly if you're unsure your items will sell, with each item costing potentially around $100 of gas to mint.

There's a bit of nuance to how OpenSea does things. They do so-called lazy minting. While you may need to pay an initial gas fee to list a new collection, each NFT listing does not require any fees. This works because the NFT is not actually minted yet. It gets officially minted once the buyer pays the gas fees to mint the artwork on the blockchain.

I created a new collection then began adding each NFT one by one; first adding the item, then marking it for sale at a set price. If I had a more complex set, I might have spent the time to add detailed metadata such as unique stats or traits of the individual NFTs to help people more easily filter and find what they're looking for.

When it came to pricing, I wasn't really sure how to approach this. I started with the first few priced around $200, between Ξ0.05-0.065 (Ξ is the symbol for ETH, or ether). I wasn't sure if these would sell at all and since I was manually uploading and listing each NFT, I started slow and released them in batches over a 3 day period. I listed the first three in a new Crypto Mondrian //DARK collection, Tweeted about it and then went out to dinner that Sunday evening.

Surprisingly, all 3 sold quickly. The next day, I released 20 more NFTs. Every few minutes I would hear the ding from my email app and then open my Rainbow Ethereum wallet to see each new inbound ETH transfer from OpenSea.

I'm blown away by the NFT community.. already sold 12 of my Crypto Mondrian //DARKs. 🤯 I just listed another 20: https://t.co/lPHCzp5spT pic.twitter.com/nOEb7zGfEq

— Paul Stamatiou (@Stammy) September 6, 2021

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

I kept releasing in batches over a 3 day period at varying prices. As they started to sell I noticed people quickly listing theirs for sale at much higher prices so I experimented with increasing my prices.

It was interesting to see where the sales came from. While I think a good portion came from those that follow me on Twitter, I believe a large set of folks found me through various crypto community Discord and Telegram groups where my collection was eventually shared. I also saw lots of folks that purchased them ending up sharing the new NFTs they added to their collection with their own audiences. It was awesome to see it all come together.

By the end of day 3, all NFTs had sold (except #099 and #100 I wanted to keep for myself as a memento). To say that I was shocked that my Crypto Mondrian art was selling and selling well would be a huge understatement. The reaction far exceeded my expectations. The average sale price was around Ξ0.189, though that includes all sales (some of which were much higher like Ξ0.6-0.9) not just ones listed for sale by me directly.

My collection ended up being ranked #469 out of all NFT collections on OpenSea that week, and #132 in the Art category:

Breaking down the sales

The grand total was Ξ14.085, just over $50,000 at the current ETH price

One interesting thing about certain NFT marketplaces like OpenSea is the ability for creators to specify a royalty percentage when listing their collection. This means that the creator will continually receive payment for any sale of their NFTs, even if they are not involved in the transaction and it is between two other users. This is amazingly creator-friendly. Currently, this is a feature of some individual NFT marketplaces, not actually part of any NFT standard.. yet.

That being said, I did set a 10% royalty on my Crypto Mondrian collection. OpenSea batches up the royalties and delivers them in a separate, single payment every few weeks.

Here's a breakdown of the sales and royalties so far:

I'm extremely thankful and amazed at what was able to happen with this project, and the power of the crypto technology and community that enabled this to happen. It has been awesome to see creators quit their full-time jobs to pursue their passions, fueled by their newfound ability to quickly be able to earn a tremendous amount of money with NFT collections. It will be fun to see how this space evolves and what new types of things can be created using NFTs, even beyond art and collectibles.

On the other hand, it's clear that a lot of people are interested in NFTs to be able to quickly flip them (often within hours or days of a purchase) and make a quick profit. As a creator, the first time I saw someone purchase my NFT and then immediately list it for 13x their purchase price.. that stung a bit. I get it though, and I have definitely been on the other side before. I wish there was a way to specify separate types of NFTs that might let me sell differently to those that enjoy the artwork vs those that are in it for the investment and speculation.

For example, I might sell an NFT at a discount if it meant the buyer would either not be able to sell it, or would not be able to sell it for some period of time. Not unlike a 6-month IPO lock-up period for employees.

What's next?

Just tinkering and learning

I had a lot of fun diving into the world of NFTs lately. While I'm interested in continuing the journey with another collection, I won't do anything unless it's a slight evolution from what I just did with this set. Either a new style or something different (video? animated?).

I have been particularly interested in learning about smart contracts and would love to deploy a smart contract that is able to generate media completely on-chain. It's been fun to watch all the smart contract experiments that Dom Hoffman (creator of Loot, Blitmap, Vine..) has been tweeting out. As I wrote this, another interesting NFT experiment called Manny's Game was gaining popularity and had a unique set of rules.

But one thing seems to be certain with NFTs: creativity is valued highly. Being the second person to do something without evolving the format much won't get you too far, especially in the future as the popularity of NFTs go up and down.

Qualities to look for in NFTs on chain 🖼 good art 🌐 public domain 💻 open source 💎 unique 🤝 not anonymous 💗 healthy community ❌ not super markety 🧑‍🎨 committed artist 💸 you like it 💵 you can afford it 📉 ur cool if it goes down

— Dame.eth (@jacksondame) September 14, 2021

But, of course, I have lots of work left on my other project Stocketa, where I recently added basic crypto support.

It was just a year and a few months ago that I first began learning about and tinkering with Swift and SwiftUI. I followed tutorials and learned through lots of trial and error as I worked on my stocks tracker app, Stocketa. Picking up SwiftUI was one of the best decisions I’ve made.

SwiftUI is a massive advancement in making iOS development more accessible for all. I don't consider myself a seasoned developer but I know enough to build somewhat polished prototypes and sites for my projects. I've tried to get into iOS development years ago with Objective-C and UIKit but it was just not for me.

As a designer with many years of experience designing mobile interfaces, I always felt one step removed from the process and the final product. I could prototype a ton of stuff with web technologies and preview on mobile devices but it wasn't the same. I've always wanted to design and build natively, with Apple's own tools.

I love sweating the details of interactions and motion, but my ability to express myself and try out concepts using native devices and OS affordances always felt limited by my lack of knowledge of these tools. Sure, I could describe what I wanted to an engineer in many ways, but I wanted to build it myself.

There’s nothing quite like just doing it yourself, natively and SwiftUI has made this a reality for me. I'm here to share my enthusiasm and some resources so that it can be attainable for you too.

This is not meant to be a comprehensive guide or tutorial, but rather a brief reflection on my time with SwiftUI and some pointers on getting started.

Stocketa & SwiftUI

SwiftUI is not some beginner's toy for getting into iOS development (though some long-time UIKit developers may say otherwise). You can make beautiful, full-blown, real iOS apps with all the motion, delight and flourishes you want. And this will only continue to improve as Apple invests more into SwiftUI in the coming years.

I have only had to use UIKit for a few minor things like getting more control over custom textfield designs and interactions. I've built custom bottom sheets, menus, onboarding flows and much more purely with SwiftUI. Here are some examples of what I've been able to build with SwiftUI:

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

What is SwiftUI?

Let me take a step back and explain what SwiftUI is in the first place and why I think it makes iOS development much more accessible to all.

SwiftUI is a framework for creating interactive user interfaces for iOS and macOS. It goes beyond just the visuals of how the interface looks and helps with everything from taps and gestures to accepting data input via things like text fields, color pickers and date pickers to working with your iPad's trackpad pointer. And it does it in a way that, to me, feels very natural and fast.

It feels natural because SwiftUI code just feels like you're writing some new type of HTML markup. It's definitely way more than that, but when you're just getting started it doesn't feel foreign. You're not trying to figure out what "super" means, what function overriding is or trying to grok what viewDidLoad() is for.

And it feels fast because you're writing SwiftUI side-by-side with a live preview, so you see your changes as you type them. You don't have to compile and send a build to your device or the simulator to get an interactive preview of your view.

SwiftUI was introduced two years ago with iOS 13 and brings a declarative style of programming for your user interface. The general idea is that all views of your app are based on the state of your data. Instead of telling a view exactly how and what you want it to do with imperative programming, with SwiftUI you tell it what you want and the view will react automatically based on the underlying data changing.

Want a circle to move across the screen when the user taps a button? You have a value on the object that it reacts to, along with an animation between the old and new value. This declarative style is similar to React web development too.

I'm flying through this but once you wrap your head around the declarative style it really just speeds up development.

My SwiftUI first impressions

It's important for me to add the context here that my impressions of diving into iOS development with SwiftUI are based entirely on me being a designer, not an iOS developer already familiar with UIKit development. I've just been given keys to a Ferrari. Everything is amazing and I'm just happy to be in the driver's seat and press that red engine start button. I have everything to finally build an iPhone app myself.

Contrast this viewpoint with, say, an existing iOS developer. My perception of the broader iOS developer community is that SwiftUI isn’t exactly universally loved. SwiftUI does not have feature parity with UIKit. The SwiftUI alternatives may not be as performant or may not be possible yet. It's an entirely different way of crafting user interfaces and it has a few bugs here and there. I get that.

But SwiftUI is getting better every year and WWDC 2021 starts next week. With each iOS release we get more and more SwiftUI updates bringing us closer to parity. Swift 5.5 is coming soon and that brings lots of very intriguing improvements like async/await as well as #if for postfix member expressions (lets you do conditional view modifiers easily) that will be fun to explore.

But I digress... my first impressions of developing with SwiftUI along with some of my current thoughts:

SwiftUI live previews:

• First impression: Writing SwiftUI view code on one side of Xcode and then seeing the live, interactive preview of your interface is very slick and a fun way to learn as you figure out the ins and outs of SwiftUI.

• 15 months in: SwiftUI Previews get extremely slow to load and refresh once you start having a larger app. They also get more complex as you have to do more work to manage the example data to use for the preview. Especially if you have certain things that rely on user state (such as a logged-in user from Firebase). And due to the static nature of the preview code, if you want to change a @State for example you have to resort to tricks like wrapping the view.
  The key is to know what to use previews for. They can be very helpful for smaller subviews that work totally fine with static data. But it's up to you if you want to spend the time to get it working well for more complex views. I tend to use it for smaller subviews and then just test on device for the rest.

On SwiftUI giving you native access

• First impression: SwiftUI gives you access to so much. Native UI components. Advanced gestures (of which you can use multiple at the same time!). The ability to animate virtually anything. The ability to use lots of views however you like, even applying a mask over them at once. Access to device things like gyroscope, accelerometer and haptics. The list goes on. It's real, native app development and it's great.

• 15 months in: Yea this never gets old.

Building for native mobile vs Web

• First impression: Designing and developing natively for iOS feels so much faster and guaranteed compared to Web. There are only a few types of iOS devices so for the most part what you see on your device is exactly what someone will experience on their iPhone, down to the animations. You don't have to worry about testing across many browsers and viewports compared to Web, nor worry about heavily optimizing file sizes.

• 15 months in: You have to care about performance once your app does more. You'll have to think about what thread you're using else you may drop frames and introduce some scrolling jank. You'll have to think about optimizing your views and heavily using sub-views to reduce what gets redrawn to the screen. You'll have to care a bit about what functions do heavy computation and when.

  But for performance with animations and masks, that's still good. Most of the time when I drop some frames it's due to some underlying data issue, not me doing something too crazy with lots of views, animations and masks.

SwiftUI's modifier syntax

• First impression: Writing view code with all these chained modifiers (the .frame(), .foregroundColor() and other things chained under objects) is a bit funky and seems messy. Compared to web development where you actively try not to put too much style code in the view layout markup and abstract much of the styling out to a separate CSS file.

• 15 months in: The way SwiftUI does things with modifiers is great but you need to get into the habit of abstracting commonly used groupings of modifiers into custom view modifiers (think of it like using a class in CSS.. kinda).

Working with a strongly typed language While this is more about Swift than SwiftUI, you'll run into it regardless: Swift is a strongly typed language.

• First impression: It's extremely annoying. I was dealing with non-stop warnings and errors that I wasn't using the correct type when working with some data (Types are things like Bool, Int, Double as well as many other object types you can create). It was very confusing, especially trying to figure out why Optionals are a thing, how to unwrap them and so on.

• 15 months in: I'm very comfortable now with Swift's strong typing and really think it helps write faster, safer code. I'll still run into various issues but most of the time it's just Xcode looking out for me.

Learning SwiftUI

It's clear to me that SwiftUI is a powerful way to develop apps, especially for people with no prior iOS development experience. While there is always a learning curve with new frameworks and tools, especially code-based ones, SwiftUI is a fresh take on this with the Xcode live preview canvas that lets you see your UI as you're writing it.

My goal with this article is share my high-level thoughts on SwiftUI and pointers on how to get started with some great resources that have helped me along the way. I hope to write a much more in-depth post about Stocketa and SwiftUI in the future.

Where to start?

I learned Swift and SwiftUI like I learn most things: a few tutorials to get the swing of things, then trying it out with my own project and all the trial and error that follows. Fortunately, SwiftUI has a ridiculously healthy and active developer community so there are always places to turn to for help.

Here's the general flow you might follow while getting into SwiftUI:

• Install Xcode or Playgrounds.app. While you'll need Xcode to get the most out of SwiftUI and build a full app, there's another option. Apple has a MacOS and iPad app called Playgrounds that's perfect for prototyping and playing with Swift and SwiftUI.

• Get familiar with the SwiftUI basics. How to use frames, stacks and spacers to lay things out in your interface. Then how to use view modifiers to tweak visual elements of your designs.

• Dabble with basic interactions Advance to hooking up some button interactions with @State and bindings and trying built-in components like the ScrollViews, toggles and more.

• Play with animations. There's lots of fun to be had with .transition() and .animation(). Apple has a tutorial on the basics too.

• Work with data and dive deeper into Swift. Up until now you could get pretty far with a minimal understanding of Swift itself but you'll soon need to have a stronger grasp. Learning how to structure your models for objects, learn more about optionals and types, manipulating arrays, making network requests and so on.

• Getting better at manipulating data. At this point lots of your challenges will be around manipulating data and passing it around. Here you'll probably face some decisions for your app. How do you store your data: do you use Apple's Core Data, a SQLite library like GRDB or turn to a third-party solution like Firebase Firestore or Realm.

Resources

Okay, now to the actual resources I've learned from and come to rely on for staying up-to-date with all things Swift and SwiftUI these days.

Courses

• Apple WWDC Video: Introduction to SwiftUI — Start here and at least watch the first 10 minutes where it goes over SwiftUI layout basics. It pretty quickly starts going through states, interactions and gestures, which you might be better off learning more paced with some other resources if you're just getting started.
• Apple: Introducing SwiftUI — Apple has their own tutorial for getting up to speed with SwiftUI, but if this is your very first time I personally don't feel it's that great and that following along with a video where things are described step by step might be better.
• Design+Code — This is where I started. Meng To and the team at Design+Code have several SwiftUI courses for all levels of experience. When I took the course there was only one and it was great for me to get a solid understanding of view layout basics.
• Stanford CS193p - Developing Apps for iOS — Stanford has their own course covering SwiftUI, with all materials freely available online.
• Udemy SwiftUI courses — While I haven't done any myself, there's a lot of highly-rated SwiftUI courses on Udemy.

Hacking With Swift

You can't learn SwiftUI without coming across Paul Hudson and his website Hacking With Swift. It's a goldmine of material and practically every Google search I had when I was getting started had one of his articles in the top results. I recommend subscribing to get access to more of his tutorials.

Aside from a plethora of articles, Paul also has several Swift-related books and two amazing, free courses that break down Swift and SwiftUI into bite-sized videos:

• 100 Days of SwiftUI
• 100 Days of Swift

I dabbled with both but never fully finished them; I got too eager to start building my own project.

Reddit

There are a few solid sub-reddits I like to check occasionally to keep in the loop of things and sometimes share progress: r/SwiftUI, r/Swift and r/iOSProgramming.

Blogs

• Swift with Majid by @mecid — One of the first good Swift/SwiftUI blogs I found when just getting started. Lots of great articles written in an easy to digest way. Though some articles are definitely a bit advanced and not beginner friendly.
• Five Stars — An excellent resource from Federico Zanetello
• Peter Friese — If you end up using Firestore for saving your data, Peter (who works on Firebase) has some great tutorials to get started.
• Swift by Sundell by @johnsundell
• Donny Wals — He also wrote a book on Core Data and a book on Combine.
• The SwiftUI Lab — Not as many recent posts these days but I read a few while learning.
• Sarun Wongpatcharapakorn
• Medium — I wish there was a better way to link to this, but there are some occasional good SwiftUI posts on Medium if you search by tag. BetterProgramming is one Medium publication to watch too.
• Yet Another Swift Blog — A bit more on the advanced side but some good Swift and SwiftUI topics here.
• Ray Wenderlich — It's not a blog, but a sort of professional developer subscription service. But they have plenty of free tutorials related to SwiftUI. My only gripe is that much of the content is written from the perspective of a developer trying out Swift/SwiftUI things, not as an overall beginner for mobile development. For example their intro to SwiftUI makes various references to UIKit development.

Newsletters

• Recreate Code — A newsletter with videos diving into using SwiftUI to build layouts of common UIs and apps from Navdeep Singh and Jordan Singer.

• SwiftLee Weekly

• SwiftUI Weekly by Majid Jabrayilov

• Indie Dev Monday

• iOS Dev Weekly

GitHub & YouTube

Whenever I'm really stuck on a problem and can't find any relevant info on Google results, I usually turn to searching on YouTube and GitHub. I'm frequently surprised at what I'm able to find there that I wasn't able to otherwise.

On GitHub you may find various examples apps showing the concepts you're looking for. A few YouTube accounts that consistently have some SwiftUI content are Code with Chris, Sean Allen, Rebeloper, Kavsoft and of course Paul Hudson.

Tips from my experience

So I just linked to a ton of resources. I wish there was one single thing I could recommend but for me I learned through a myriad of sources over time. Here are a few things I learned or wish I had known as I started getting the hang of Swift and SwiftUI:

• Get inspired, find a project. I learn best when I have my own project to build instead of following tutorial after tutorial of a random app concept. If that's you, it may be helpful to try to pick an area of interest and see if there's a simple app you can build for it.

  If you're looking for app inspiration, or just want to discover new patterns or seek UIs to build yourself, I suggest continually checking the App Store and trying out lots of apps.

  For me, that was a stock tracker app, Stocketa. (Which is currently in limited Testflight testing now as I continue development). I’ve been so impressed with what I’ve been able to accomplish purely with SwiftUI in this app.

• Learn a few Xcode shortcuts. I wish I had taken a bit more time to learn more about Xcode's capabilities when I got started. There are so many handy shortcuts and settings that can make your life easier.

  Read this post on Xcode shortcuts from Peter Friese. Some of my faves:

• Auto-indent code: ⌃ (Control) + i.

• Refresh the preview canvas: ⌘ (Command) + ⌥ (Option) + p.

• Open a file quickly: ⇧ (Shift) + ⌘ (Command) + o.

• Customize Xcode to make ⌘ (Command) + d delete the current line.

• Building a custom bottom sheet is harder than it looks. Lots of app these days use nice, custom bottom sheets with varying capabilities. In SwiftUI we have the native .sheet() but you can't control things like how high it opens. I built a few custom ones and they're harder to get working flawlessly than you'd think. Especially if you want to be able to have multiple resting heights and seamlessly transition to scrolling with a single gesture when expanded.

• Use the value attribute for .animation() for more control over when something animates. I use this everywhere. I only discovered it after filing a SwiftUI bug with Apple and the Apple engineer suggested using this for a particular issue I had.

• Use a view model. Eventually you'll find yourself with increasingly more logic and functions in your views. It's time to move that to a separate View Model file. An example would be a class that is an ObservableObject that your view uses. Read up on MVVM (Model-View-ViewModel) for more info on this architectural pattern.

• .mask() is very useful. Especially if you're using gradients to color certain elements or if you need to apply an alpha gradient on a view. You can also use stacks to use multiple elements in your mask.

• Customize SVG assets with "Template Image" render setting. Want to add an SVG to your Assets.xcsassets catalog and then be able to change its color directly in SwiftUI? You'll need to set "Render As" to "Template Image" in Xcode.

• The @AppStorage property wrapper is your friend when you need to store tiny, non-vital local settings for the user. Out of the box it only supports a few value types, but you can follow this guide on RawRepresentable to store any type of data to it.

• The resetTransaction property of @GestureState can be handy to define the animation to use when a user releases their finger when doing a gesture (as opposed to applying a general animation for the entire view/object).

• Get to know the .simultaneousGesture() modifier. If you're doing anything advanced with gestures, it's helpful to know that SwiftUI can help you manage multiple gestures with this view modifier. There's also .highPriorityGesture().

• .contentShape() is your friend if some views are not tappable. Every so often you'll into a situation where you're trying to make a view tappable (either inside a button or with .onTapGesture()) and only a certain part of the view will be tappable. By placing .contentShape() on this view, say after any padding or other visual modifications you have, you'll make the entire area tappable.

• Disable interaction with .allowsHitTesting(false) when needed. This may come in handy when you're doing more advanced things with gestures.

• Need more performance? Start by splitting your view into smaller sub-views. There are a lot of reasons why your app could see some slow downs or have some janky, frame-dropping behavior. But in my experience the best place to start is abstracting your larger views into smaller ones. SwiftUI updates a view whenever any part of the view state changes, so by splitting your view into a set of smaller views, you're giving SwiftUI the ability to only update smaller views depending on what data changed state.

• Use .compositingGroup() to help with animation and rendering issues. This modifier basically applies view modifiers on the ancestor views before rendered. A bit hard to describe but in particular it's helpful when dealing with opacity animations or shadows. And if the view doesn't need to be interactive, there's and .drawingGroup() which is similar but flattens your views and uses Metal rendering for increased performance.

• Consider caching slow functions with memoization. This only works for certain types of functions, but something worth knowing about. Here's a great article on memoization.

• Core Data (storage) is not for everyone. I got it working in my early versions of Stocketa but then I wanted to have it sync with iCloud and found it to be slow and unreliable. The only answer was to do a lot of custom syncing another way. I moved to Firebase Firestore and was much, much happier (after figuring out how to best flatten my data structure a bit).

• If you just can't get it to work.. quit Xcode. If you've tried everything and it should work but doesn't, try quitting and reopening Xcode. Try "Clean Build Folder" in Xcode. Try clearing Xcode cache files (I like DevCleaner.app for this). If none of that works, maybe it's Apple's bug:

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

Before you know it you have a handful of different email addresses on different domains for various needs and you're paying $50+ per month for that privilege. And let's be honest, most of these addresses get just a few emails per week, if any.

There's really no one that makes it easy to own/manage lots of email addresses.
I probably have 10 for various needs/projects, all on custom domains, and I love G Suite but it's ~$6/mo per email. I use Fastmail for some too but it's a hassle to setup/manage them all.
— Paul Stamatiou (@Stammy) March 18, 2021

It's 2021. While email is becoming less and less the backbone of any new venture, it's still a core and required piece of being an Internet citizen. It shouldn't be this complex to manage and setup email for all of your domains.

There are definitely benefits to keeping all of our email accounts entirely separate:

• You want to separate business from personal.
• You want each domain to have its own password and 2FA/security key setup for security. Not great if you have everything under one account or admin control — if one account gets hacked, they're all hacked.

While certain email providers can let you maintain separate user accounts together, they all seem to have the same sort of admin setup where an admin account can still control user accounts. That's not quite what I'm looking for.

For something so common, it should be easy and not cost an extra $5 per month just to setup one more custom domain and a few addresses. I often don't need all the assorted Google Workspace functionality, in fact I often prefer not having yet another Google account show up in the user account dropdown.

What I'm getting at is nothing novel: just easy and reliable turnkey email hosting. But a solution that is optimized for keeping accounts separate for security but somehow allowing for one account to pay for them. Similar to how you need to fetch an auth code to transfer a domain, perhaps you just need a payment code to setup billing.

You can go down the rabbit hole of self-hosting (Helm is an interesting solution here but I don't want the server inside my house) and dealing with maintenance, deliverability issues and reliability. That's not something I'm interested in.

There's also a breed of services like Migadu that offer one place for you to manage your domains and setup hosting for each. It actually seems exactly what I want, though I do have one concern about having one service, under the same login, manage everything for all email hosting for every domain I own. It just feels like it's consolidating everything and making it dramatically easier for an attacker to gain access to everything in one go. It would be interesting if they had a way to have one payment account, but individual, 2FA logins for each domain (basically removing the notion of any sort of organization admin that can control all domains).

What about email aliases?

I'm holding off for an ideal solution like that but for now, there's an adjacent set of solutions for slightly different needs. If you don't absolutely need to have emails/domains kept separate and don't mind mixing up the inbox, you can use email aliases.

Aliases let you send and receive email for another address on another domain, but all inside a different email inbox. So if your primary G Suite email is yourname@domain.tld, you can have an email alias that lets you send and receive email from that inbox for your other email account nickname@otherDomain.tld. There's just one inbox though, but it's up to you to filter and organize as you please.

This could be handy for emails/domains you have that are related: for example you may have a business domain and then a few emails on a different domain for the product owned by the business.

I recently discovered ImprovMX.com thanks to some replies to that tweet above. ImprovMX makes setting up email forwarding for any custom domain easy and I've used it for one of my domains so far. The only thing I don't feel great about is that using this method, you'll have to specify an SMTP server to send your email with and unfortunately that connection is password-only, no two-factor auth (even if 2FA was feasible you'd probably have to be asked with every email you send and email clients aren't designed with that in mind).

Separately, someone also mentioned SimpleLogin.io, which helps you make unique, temporary email address aliases. This is similar to how Sign in with Apple can hide your real email from the service if you enable the "Hide my email" setting. With SimpleLogin you can create all sorts of aliases that forward email to your real email, and completely hide your address. You can of course disable/delete the alias at anytime. I think I'll be trying it out in the future when signing up for new things.

My girlfriend Katherine and I had plans for some big trips this year, which we of course shelved. In the past one of my most time-consuming hobbies was making really detailed photosets of my trips. Here's one of my favorite: Southern Serengeti, Tanzania.

I would spend months of spare time culling and processing thousands of captured shots and video clips then designing and building photosets around them. They were definitely a passion project, almost entirely for myself.

Over the last few years I was usually juggling 1 or 2 side projects: either writing some long article for this blog, or working on some large travel photoset. This year I didn't feel strongly enough about any particular topic to deep dive into writing a long article about, nor did I have any travel photos to work on.

I felt the need to do or learn something to keep me occupied (which I even feel a bit weird about, I find it hard to just relax and do nothing). I had always been curious about Swift and SwiftUI but really thought that was an unattainable goal for me to be proficient at. I had very, very briefly dabbled with Objective-C development years back and was turned off by the whole thing. It was so confusing to me at the time.

In March I decided to spend some time diving into Swift and SwiftUI. After reading some cursory guides and tutorials, I needed a project to dive into. That's how I learn best. I began working on a personal itch: having an easier, more approachable and elegant way to track my stock holdings. Since then I have probably spent 10-15ish hours per week for the last ~9 months learning and building my first real iOS app, Stocketa (Coming in 2021.. stay in the loop).

It wasn’t all kittens and daisies. There have been many frustrating back-to-back days and weeks where I’ve been stuck on a problem or not been happy with a solution so I’ve redesigned and rebuilt entire features. I think I’ve rebuilt the holdings view of my app probably 4-5 times by now.

I really, really love building for iOS. I love being able to control the entire lifecycle of a product: idea, sketches, designs, coded and working on a real device with native iOS code.

I can spend an insane amount of hours on a particular animation or flow and get exactly to the intended fidelity and experience I’m aiming for.

Now this has me thinking that as long as I have some app that I’m working on as my main side project.. I’m not so sure I’ll ever go back to spending months working on detailed photosets. While photosets are largely just for me, an app is a different beast entirely.

I can distribute and have others try out and hopefully find a recurring use for it. I’m not assuming my app or future apps will make me any money but there’s something nice about being able to share your work with others that they will be able to use with their own data, unlike my website where it’s a more defined one-way relationship.

But I digress, I’m sure I’ll find some lightweight way to share photosets in the future, but it likely won’t be to the level of care they have been in the past. Though I do plan to find time to pause working on the app to write about things I’ve learned and share more progress.

Designing and developing

Throughout the year all of this has had me thinking more about my career in the future.

When I went to college in 2004 I started out as an electrical engineering major. I grew up soldering and building little circuit boards so it felt like the natural thing to do. I was never really into software. Long story short, that changed for me and I became fascinated with the web, design and software world, eventually changing switching to a major that was a hybrid of design and computer science.

I graduated college not thinking I was a good designer or developer. I did both as needed with my first few jobs. They were startups, so wearing many hats is expected anyways.

I love working on design strategy, vision, visual design, interactions and motion just as much as learning how to setup a view model and pipe data through my app and having my designs come to life.

At times I feel like I’m hiding part of myself at my day job as I don’t really get to put all of my technical skills to use, aside from some interactive mobile prototypes (and I am trying to fit in more SwiftUI prototypes at work when I can).

This is not a dig at my employer or anything; just commentary on what I view as a slightly evolving landscape where development tools and frameworks have become so much more approachable that the definition of a "developer" is finally more accessible. This is a good thing! Designers that care so much about the end-to-end experience can now have greater control over the end result. I could have never been an iOS developer in the UIKit and Objective-C days.

I have no interest in going into full-time software engineering as a job. I don’t want to get caught up with process, semantics, code style and code reviews, I want to obsess over the (front-end) details and interactions until it’s right.

There are more and more design engineering roles these days but I feel like I would lose part of my autonomy as a designer in helping define the strategy, solution and experience. And some companies have design engineering roles that are much more on the engineering side where you’re going to be working in a production app. That’s definitely not me (please no UIKit!).

A common rebuttal to this is just "work at a startup!"—I am definitely jaded on that. Here’s a good read on the topic. I just think that the ROI is often so messed up with startups. Especially if you’re the first design hire and get to do all the fun and challenging 0-60 stuff. You’ll be putting in as much time and sweat as the founders but get 100x less compensation.

There's nothing I need solved now, nor am I looking for a job (the opposite, I'm very happy at Twitter).. just wanted to share that I really love building, from design to polished app.

But it really doesn't matter what I do with my digital documents as I always end up having some pen and paper on my desk at all times to take notes, quickly sketch designs and manage more to-do lists. I usually rely on plain printer paper or a Moleskine notebook.

I was wandering around SoHo in Manhattan a few weeks ago when I went to a small boutique pen and stationery store ("Goods for the Study" on Mulberry St). I eventually came across the BaronFig Squire and it was by far the best pen I had tried out there.

First off, it's a pricey pen. The stainless steel one I got is $95 but it starts at $55 for other metals and colors. But it has impeccable build quality: it's a twist-to-open style pen and there is absolutely no wiggling or play in the mechanism. It's also rather heavy which I appreciate. And finally the ink rolls out very smoothly, no matter what angle you're using it at.

It uses "Parker capless" style ink refills and I was readily able to find a few styles of compatible ink refills on JetPens.com: Schmidt P8126, Ohto Flash Dry PG-105NP, Uni SXR-600 Jetstream.

I purchased all of those refills looking for something slightly more fine but still ended up going back to the ink it came with (looked like a rebranded Schmidt P8126 anyways). My only complaint with it is that the default ink is ever so slightly too thick for my taste but I love how easily it comes out at all angles.

I used to follow a few hundred personal weblogs but eventually that number dwindled down as people stopped blogging. My consumption time naturally adjusted to focus on other sources like Twitter. Despite RSS standing for Really Simple Syndication, it couldn’t hold a candle to simpler and more interactive services… things everyone has like Twitter, Reddit, or even the Apple News app.

And then in recent years individual email newsletters became more mainstream with services like TinyLetter and Substack making it easy for people to build and reach their own community as well as monetize.

RSS has been considered dead to all but the most dedicated and loyal.

Modern RSS readers

It’s now almost 2021. Things I want to keep up to date with are now all over the place. My inbox is littered with various newsletters. I have to constantly manage Gmail filters (and remember to check them) for various subscriptions. While I get my fill of news and updates about interests from Twitter and some Reddit, I follow a lot and it’s easy to miss something.

This has been especially true in 2020 where there’s been enough political and pandemic news to dominate any platform. And beyond that, there are times when I want to step away from feeds of non-stop bad world news and go to a place that’s laser-focused on content from a few sources I’ve picked.

I decided to take a look at the current state of RSS readers in 2020. I was in for a surprise.

RSS readers have evolved. That’s not even a good term for them now as they do so much more. They know that you get your news from multiple sources: email newsletters, Twitter, podcasts, YouTube and of course RSS too. They know that there’s often a deluge of updates you need help sifting through or that you need help keeping track of articles you find elsewhere.

I looked at what RSS readers were popular by checking out my website analytics. I’ve always seen Feedly and Newsblur in there as referrers, but have also started to see Inoreader as well. Feedly has a robust offering, and it was a product I used a bit many years ago. It has a higher price point than some other services but in the end I just didn’t like the design. It felt busy. Like another inbox I had to manage instead of a calm place I can go to relax, similar to firing up my Kindle. I felt the same way about Inoreader and others.

Feedbin

Then I found Feedbin. I very quickly knew this is what I had been looking for. First off, it's not free. Feedbin is $5 per month. But on that note I don't think any RSS readers with any unlimited email newsletter capability are free.

Newsletter functionality is easy to setup. In the settings you'll find your own custom @newsletters.feedbin.com email address to use to subscribe to any newsletters you like.

There's not much to the user interface but there's attention to detail in a few places. I was pleasantly surprised to see that Feedbin has several Hoefler & Co typefaces to choose from. I then realized that Feedbin can even extract the full-text of any RSS post from the website directly, even when the feed only provides partial content.

Feedbin also has a browser bookmarklet so you can easily send any article you find anywhere on the web to Feedbin for reading later. I find myself using this quite a bit.

There's also some basic "actions" functionality. Actions work very much like Gmail filters. You provide some basic search terms, specify what tags and feeds to look in and then how to act on it. Right now the set of actions is pretty limited: you can have posts marked as read or starred. There's no way to entirely filter something out of a feed unfortunately. You can, however, setup push notifications for specific terms with Feedbin Notifier.

I use a few actions to star particular terms in high-volume feeds I follow. For example, I use it to search a few iOS-related subreddits for terms I care or am learning about (recently that was anything iOS 14 with Firebase) and star posts for me to browse through later.

That's pretty much it. I use Feedbin every morning on my iPad Pro with my morning coffee. It's a focused, dedicated place for me to catch up on a particular set of curated blogs, newsletters and news sources without getting distracted. And it helps unburden my inbox.

Feedbin only does a few things and I appreciate that it's a relatively focused experience; not some overbearing tool. However, I do find myself wanting it to be a bit smarter in places.

I'd love to be able to tell it more generally what niche topics and phrases I'm interested in and have it more proactively prioritize these for me as well as learn as I engage with posts. I'd love to be able to apply those filters across links shared in Tweets from people I follow. And I'd like it to help me discover high-quality blogs about the topics I'm interested in.

I'd also like to be able to globally disable unread counts. I don't want to have that kind of stressful inbox-like experience. I just want to be able to dip in and out as I please and not feel like I'm behind, as has always been my relationship with RSS readers in the past: an overbearing, incessantly incrementing unread counter.

Feedbin has an iOS app but there are lots of other RSS readers that let you log into your Feedbin account so you can maintain a synced consumption experience across devices. NetNewsWire, Reeder and Unread are some of the popular ones.

If you follow any great blogs on the topics of iOS/SwiftUI development, design, software, startups or product development, I'd love to find more sites to subscribe to. Let me know on Twitter or email.

Most of the time my side project has been this website. Redesigning it, debugging it, optimizing it, writing for it, shooting photos for it, editing photos for it, building out new functionality for it, managing servers and storage needs, et cetera.

For the last 6 months I have been working on a new side project (thread), a simple stocks-related app. It has helped me dive head-first into the world of Swift and SwiftUI, learn about Core Data, Cloudflare Workers, Sign In With Apple, TestFlight, Stripe Atlas, Firebase, Firebase Cloud Functions, Express.js, Hugo, Netlify and more. Not to mention that it has helped me sharpen my mobile, motion and visual design skills further.

Side projects give me a constraint-free creative outlet. I am the product manager, the researcher, the mobile designer, the web designer, the motion designer, the brand designer, the marketing designer, the mobile engineer, the backend engineer, the reliability engineer…

I can spend a month working on the animations of one view if I want. Everything is a blank canvas where I can try out different aesthetics, interactions, copy, motion and more. I can break as many design rules as I want. There are no gatekeepers or stakeholders.

I don't set goals or deadlines for side projects—I fear they will start to feel like work then. It doesn't matter it if takes me 4 weeks or 4 months to write a blog post or even longer to publish trip photosets or ship an app. I’m just looking to make things the way I want.

Side projects keep me fulfilled on so many levels. I can’t imagine not having one on hand (well, ask me again when I have kids).

Netlify will automatically generate and deploy your site, optimize assets and images, provide access control and more. It also brings some desired functionality to static sites like built-in form handling and server-side analytics.

While I was only using it for a basic landing page, I quickly began to admire how convenient it made the publishing process. Long story short, I moved this website to Netlify from my previous setup utilizing Amazon AWS S3 with CloudFront.

My previous AWS S3 + Cloudfront setup

I have been running this site for over 15 years now. The first few years I had a WordPress blog that I served on a bunch of devices ranging from a G4 Mac Mini in my dorm to a shared server and then to a VPS. Several years into that I wanted to change how I was publishing. I hated constantly updating the software due to security issues, keeping my VPS operating system and packages up to date and dealing with MySQL database backups (one of my early articles was about writing a bash script to save a WordPress MySQL database dump to Amazon S3).

I migrated my WordPress blog to Jekyll in late 2010 as part of my desire to simplify some of those performance and maintenance concerns. With Jekyll I had a site made up of fully static files and no database to worry about. I hosted my Jekyll site with Apache on an Ubuntu VPS for a while then landed on a Heroku setup with Rack::Static for a few years.

I eventually ended up hosting my site directly on S3 with CloudFront and AWS Route53 for DNS. I favored this setup for its pure speed and lack of a real server I would have to manage in any capacity. Having everything on your site served at the edge directly from a CDN is a big deal. I remember receiving a few emails from readers outside the U.S. saying they noticed a performance boost on my site.

But the S3/CloudFront route felt like a hack. I relied on a Ruby gem to manually configure redirects (years ago I changed my permalink structure and have about a thousand redirects I need to keep around for old links) as well as invalidate CloudFront files each time I updated them. I also had to manage the site generation myself before deploying. Not a huge deal but it did mean I had to ensure I ran a few commands in the terminal in the correct sequence before deploying, and hanging around the terminal to ensure everything worked properly. I knew I needed to find a better solution when the gem I used for S3 deploys went into an unmaintained state.

Why didn't I migrate earlier?

I first heard of Netlify several years ago. It seemed interesting but honestly I was not comfortable relying on a product from a relatively new startup for something as critical as hosting my sites.

Netlify the product kept getting better and Netlify the company kept growing, both in terms of employees, funding and customers. It was time to take a closer look.

At first glance I didn't think Netlify was anything special. A hosting service that builds your site/app with a git hook before deploying was nothing new. And I did not even want that functionality at first. When I work on my long posts I commit to git dozens and dozens of times before publishing. I want my drafts backed up, but I also didn't want to have to bother with a separate git branch for example.

Fortunately, there are several ways to manage your deploys with Netlify. Though for now I do have the default deploy-on-git-push behavior.

Moving to Netlify

The first step was authenticating my GitHub repository for this blog and seeing if Netlify could build it and deploy to a temporary site (Netlify issues you a subdomain of your choice on their netlify.app domain). This part took some trial and error with my Jekyll setup.

First, I needed to ensure all the Ruby gems I relied on were in my Gemfile so Netlify could install from that. I had to change a few things there. Second, I needed to find out how to get my SCSS and Coffeescript/JS generated. I figured I could just add the commands I usually run inline with the regular jekyll build command.

This part took some more trial and error. I couldn't get it to run my Grunt (JavaScript task runner) commands. I used Grunt to compile, optimize and minify my SCSS, Coffeescript and JS files. For SCSS, I decided to move away from my Grunt setup and just use the jekyll-sass-converter Jekyll plugin to handle this for me easily. As for the Coffeescript, I used this as an opportunity to go back to JS files—something I had been wanting to do.

But that still left me with the task of how to concatenate and minify my JS files. Netlify has built-in asset optimization to do exactly this. It detects a series of script tags in your markup and bundles them all together to serve as one versioned file. This worked at first, then I realized that it wasn't actually minifying the JS. I'm guessing it's an issue on Netlify's side after seeing someone else with the same issue, so I'll have to revisit that later. For now I still have to compile the JS locally before deploying whenever I change it.

The last thing I had to figure out was how Netlify handled redirects. There are two ways to configure redirects on Netlify, either with the netlify.toml config file or a separate plaintext _redirects file. I went with the latter as the format was similar to what I was using to manage URL redirects with the s3_website gem. It only took a few find and replace all commands to the redirects file formatted properly.

I want to revisit the way I'm doing redirects (over 1,000+ for individual old articles when I changed my URL format years ago) and use a one-liner as described in the documentation. Something like this:

# I have lots of redirects like this for older posts
/2005/09/13/nero-7-announced    /nero-7-announced

# Will move to something like this
/:year/:month/:date/:slug  /:slug

At this point I had the site successfully building and deploying on Netlify. Here's what my netlify.toml file looks like below. My setup is fairly basic so everything here can be controlled on the Netlify website as well.

[build]
  publish = "_site/"
  command = "jekyll build"
[build.processing]
  skip_processing = false
[build.processing.css]
  bundle = true
  minify = true
[build.processing.js]
  bundle = true
  minify = true
[build.processing.html]
  pretty_urls = true
[build.processing.images]
  compress = false

The only thing left was updating the DNS to point to Netlify. To make this as smooth as possible I first logged into AWS and visited the Route53 dashboard to see all the DNS records attached to my domain. One by one I added the exact same DNS records to Netlify's DNS. There there were quite a few records as I use both G Suite and Amazon SES on this domain.

I waited a while for Netlify's DNS servers to add those rules and then I made the final change to update the DNS servers on the domain to point to Netlify's DNS servers. Moments later the domain started loading my site on Netlify and then after that the SSL certificate was running.

A note about media uploads

While I migrated my blog to Netlify, I still keep my media assets hosted separately with S3 with CloudFront as I have for many years. I originally did this for a few reasons I mention on my About this website page. The main one being that I don't want ~30GB of media in my main git repository.

Netlify has a solution for this with their Large Media feature that uses Git LFS to store media, but I haven't looked into that too much.

Netlify first impressions

I'm only a week into my new Netlify setup but I'm really loving it so far. Here are some of my initial thoughts:

• Worry-free deploys: I'm coming around to this build system way of pushing git and knowing it will do everything it needs to build, optimize and deploy. I had something similar for my staging site back when I was writing on my iPad Pro and before I had my code-server VPS—each push would trigger AWS CodeBuild to deploy to a CloudFront distribution. Though that wasn't a great experience for a staging server I was using for quick previews (having to wait a minute or more before the deploy is done), it's fine for regular production deploys. I should also mention that with Netlify I can easily rollback to a previous deploy if needed.
• Built-in form handling: This was a really, really nice perk. With a static site hosted on S3 there was no backend that could accept any contact form POSTs; I had to use a hosted contact form from another service. Netlify has some magic attributes like data-netlify="true" you can apply to forms to get form handling and spam prevention.
• Asset optimization: I would love nothing more than to ditch all of my local asset pipeline management like concatenating CSS/JS files and minifying. Netlify handles this all for you (though as I noted I couldn't get it to minify my JS for some reason but I'm sure that will be resolved soon).
• Server-side analytics: This is neat. Previously if I wanted server-side analytics I would have to enable S3/CloudFront logging and then use a tool (either paid or self-host) to read through the logs. While I don't think I'll use it forever as it's rather pricey add-on at $9/month with far less functionality than dedicated analytics tools, it's a great resource for seeing things like what bots are accessing or what 404s I may need to fix.

• Build times could be better: While it's not a huge inconvenience, I do think build and deploy times could be faster, especially with the Pro plan that I'm on. It feels like they can vary between 1-4 minutes. Sometimes it goes by quickly and sometimes it takes more time between each file (maybe not cached?). I also think it must be running on some not-so-great hardware if it takes about 7.5 seconds to generate my jekyll site; something that takes 3.5-4 seconds on my MacBook Pro.

What's next

I'm trying to make it easier for me to write and publish articles, especially with my new focus on writing more with these short-form posts. Netlify has been a huge help here by reducing some of the friction around deploys.

Other things top of mind for making it easier to publish include migrating away from Jekyll to a faster static site generator like Hugo and considering an admin front-end for my site generator like Netlify CMS.

For about a year now I have been using a Lightsail VPS running VSCode code-server that I can access from any computer to write and deploy to my site. However, I'm now trying out GitHub Codespaces, which is basically the same thing.

I'm also exploring simplifying my local writing process by trying Nova.app from Panic to have an all-in-one writing, dev and preview experience—no need to flip between 3 apps (Chrome, iTerm2, Atom). Though I wish I could figure out how to get a live browser preview with Live Reload working as mentioned on their homepage.

Over the years my focus has been increasing the quality of my articles. They've ended up becoming increasingly time-consuming to create. The same goes for my photosets, which also often require a bit of custom design and development in addition to the many hours photo culling and editing.

While that will not change and I thoroughly enjoy spending months of spare time sharing details about subjects and projects that interest me, there's often a lot of stuff I would want to share here in between those ~annual, in-depth posts. These would be the types of posts that don't really meet my quality bar to deserve my typical long-form post process and treatment.

I want to get back to what blogging felt like when I started in 2005. Back when posting a few sentences and publishing it within the same computing session was so easy and fun. Where expectations were low and it didn't have to be perfect.

So I'm going to experiment with a section of my site for short little posts and updates. I want to share things I'm learning with Swift and Swift UI, how I'm thinking about certain design challenges with my side-projects, new products I'm using and more. I still plan to invest my time in long-form posts when it makes sense, but just want another outlet for different things.

As such, it felt like I would need to make a few layout changes for these posts to feel more casual and less refined. These short-form posts—which I don't have a name for yet—have smaller text, a narrower layout and generally less stuff. As of now I have a little module on the homepage for these, but may change how and where I display these posts.

Let me know what you think via Twitter or email as I try this out. These new posts will be incorporated into my existing RSS feed if you'd like to follow along there (I've been using NetNewsWire for RSS feeds lately).

Every week I come across another headline about how someone got hacked and within moments many of their online accounts had become compromised. These aren't simple cases of bad actors using account credentials from large public data breaches and the unfortunate result of people using the same password across many websites.

These hacks, horror stories rather, are all the result of increasingly common attacks that gain access to a person's phone number by exploiting vulnerabilities in phone carriers. More advanced attacks prey on SS7, the old protocol underlying our cellular phone networks that lacks authentication. We more commonly hear about SIM card porting and SIM swapping attacks. In general, these attacks work by socially engineering your phone carrier to convince them you need a new SIM card as you lost your device or are upgrading it, or that you just want to switch carriers.

Today, many online accounts and services request your phone number to use as a form of account recovery as well as playing a role as a second factor in two-factor authentication via SMS text messages.¹ These attacks aim to get access to your phone number so the attackers can reset whatever accounts are tied to the number.

Attackers especially want to reset important accounts like your email account. From there they are often able to reset other accounts that might not be linked to your phone number. It's a dangerous and all-too-quick sequence of events that can turn your life upside down in moments.

Increasingly, the end goal is to gain access to a cryptocurrency account like Coinbase or to steal a high-profile Instagram account handle; methods that can quickly be used to get money.

Just take a look at these headlines:

• Hackers Hit Twitter C.E.O. Jack Dorsey in a ‘SIM Swap.’ You’re at Risk, Too.
• The Most Expensive Lesson Of My Life: Details of SIM port hack
• Hackers Steal Over $300k From One of Blockchain’s Biggest VCs
• Wave of SIM swapping attacks hit US cryptocurrency users
• ‘I Lived a Nightmare:’ SIM Hijacking Victims Share Their Stories
• Everybody is getting tragically sim swapped and you will too
• The SIM Hijackers
• SIM Swapping Victims Who Lost Millions Are Pressuring Telcos to Protect Their Customers
• How to lose $8k worth of bitcoin in 15 minutes with Verizon and Coinbase
• SIM swap horror story: I've lost decades of data and Google won't lift a finger
• Hackers Are Holding High Profile Instagram Accounts Hostage
• FBI Issues Surprise New Cyber Attack Warning: Multi-Factor Auth Is Being Defeated
• Two-Factor Authentication Might Not Keep You Safe

A technology that can give you everything you want is a technology that can take away everything that you have.

—Dan Geer, Security analyst

I get freaked out every time I read one of those. As someone with a decent web presence, it feels like it’s only a matter of time before I become a victim of such an attack. While phone carriers have been working on making authentication better with efforts like Zenkey (née Project Verify) and the Mobile Authentication Taskforce, I think it’s best to take things into your own hands now, especially when technologies like Zenkey rely on mass adoption from third parties.

I've been a bit paranoid about security for a while now. It began as a curiosity for interesting new tools and services from installing PGP WDE in 2008 to encrypt my Mac (before FileVault 2 offered full-disk encryption) to exploring newer tools and services like VeraCrypt and Tarsnap.

SIM attacks like these, often the result of social engineering, are not the only thing to be worried about these days. Online phishing has become incredibly advanced, be it from official-looking texts asking for account info (smishing), malicious phone calls scams (vishing), email spoofing, brand impersonation, website spoofing and more. Take a look at this one:

Quick phishing demo. Would you fall for something like this? pic.twitter.com/phONMKHBle

— Mustafa Al-Bassam (@musalbas) September 9, 2018

A Tweet embed was not displayed. Read this article in a browser to see it as intended.

Paranoia is not entirely unwarranted with the plethora of these attacks today. It was with this mix of curiosity and fear that I began using hardware security keys two years ago. In a nutshell, security keys are little devices (typically USB, NFC or Bluetooth) that compute cryptography keys and serve as a more secure second factor² that only you can physically possess.

My evangelism of the benefits of these security keys amongst my friends has come up so often that I decided to write this beginner's guide (albeit rather detailed) to security keys—a topic generally left to very tech savvy people—to accomplish a few things:

• Encourage people to take a closer look at their personal online security.
• Explore what security keys are, understand the benefits and trade-offs, and see if security keys make sense for you.

Security best practices

A few basics for improving your online security right now

Before I dive right into talking about security keys, I thought it would be best to discuss a few security best practices: low-hanging fruit that go a long way for improving your security online. There's a wealth of information on this topic across the web, so this is in no way meant to be an exhaustive list.

In addition, it really depends on a few things like what you are trying to protect, who might want it and where along the spectrum from convenience to security you would feel comfortable. Security folks would take this opportunity to talk about your personal threat model to help assess what level of security paranoia and defenses are warranted for you. That could probably be it's own article describing various routes to take and is fairly outside the scope of what I want to do with this article.

You can be on the supremely paranoid end of the spectrum but it would just make simple daily tasks like checking email and browsing the web a chore, and most likely just increase the likelihood of locking yourself out of your accounts.

Authentication is always a trade off between security and usability.

—Bruce Schneier, "Click here to kill yourself"

• Use a password manager, religiously. Make sure the sync works or opt for a hosted cloud solution. Pick a very strong master password for the password manager and remember it. Don't use it for any other website or service. Backup the recovery key. Go through and change every online account password to something unique if it's your first time setting up the password manager.

  I use and love 1Password and pay for the cloud account but there are plenty of alternatives out there including DashLane, LastPass (some people avoid it due to a history of security incidents and their acquisition by LogMeIn), Enpass and open source options like Bitwarden.

  Set up Two-Factor Auth for your password manager if available. This is separate from 2FA for your accounts it stores and is just 2FA for the password manager itself. For example, a 2FA-enabled cloud-hosted 1Password account will ask you for your second factor when adding 1Password to any new device.

  Regularly take advantage of advanced password manager functionality that evaluates your accounts to see if they have been involved in any data breaches (1P calls this Watchtower) as well as informs you when you reuse passwords.

• Enable Two-Factor Authentication (2FA) wherever supported. Don’t enable SMS for your second factor if TOTP authenticator apps are an option.³ Enable 2FA using an authenticator app for all supported sites (we’ll get to security keys later).

  You can use an authenticator app like Google Authenticator, Microsoft Authenticator, Yubico Authenticator⁴, FreeOTP (open sourced by Red Hat), AndOTP (open source and has encrypted backups), Duo Mobile and Authy⁵.

• Backup account recovery codes if they exist, especially for important accounts and email providers like 1Password, Google and Apple accounts.

• Remove your phone number as a recovery method for your email account. Ideally from all of your accounts, but we’ll get to that later.

• Add a passphrase/PIN for your mobile phone carrier. This passphrase would be requested from the carrier to authorize any SIM port. Or at least that’s the idea. Unfortunately, phone carriers have been known to be socially engineered into not asking for it and attackers have been known to have insiders at telephone companies to bypass this.

• Be a savvy web surfer. Much easier said than done, but lots of attack vectors are much closer to home than you might think. Keep your software up to date. Use an adblocker and/or DNS provider that can help keep you away from malware and phishing. (I have been testing out NextDNS.io and liking it so far. It's like a cloud-hosted Pi Hole if you don't want to bother setting that up yourself.) More popular options include Google Public DNS (while not an explicit privacy/adblocker type of DNS provider it does protect against several types of attacks), Cloudflare 1.1.1.1 and Quad9.

  Consider using a VPN when you are on an untrusted connection, but know that a VPN merely changes who you are trusting but doesn't instantly make everything secure or private. Be skeptical of any browser extensions you install, links you click in emails, be careful when opening attachments and so on. Look for authentic website SSL certificates and correct domains when putting your credentials in a site. If your password manager can usually auto-fill in the details for a site but doesn't one day, it could be that you're not actually on the authentic site. So be sure to be suspicious if your password manager doesn't seem to be working as intended.

• Revoke permissions for unused authenticated services. Go through your accounts like Google, Facebook and Twitter and revoke authenticated apps/integrations you no longer use or don't recognize that have any kind of access to your account. There’s probably way more than you recognize due to past single sign on uses.

• Audit the authenticated devices linked to your Apple ID. Make sure you don’t have any old devices—maybe that you don’t use or no longer own—listed as devices in your account. And while we’re on the topic, make sure Find My iPhone is enabled so you can remotely disable a lost device in a pinch.

Getting more advanced

More tips for the increasingly paranoid

• Secure your account with your domain name registrar. If you’re using email on a custom domain, ensure your domain name registrar is locked down with a strong password and two-factor auth using either an authenticator app or security keys. Remove any recovery phone number as well.

  I’d recommend migrating your domains to something like Google Domains or AWS Route 53. Moving domains is easy. They offer strong 2FA solutions out of the box and I would trust them more than any other random registrar selling $5 domains.

  This step is important because it’s another easy attack vector. Someone can socially engineer your registrar or mobile phone carrier (if linked), get access to your domain, change DNS MX records and then be able to receive password reset emails and take over other accounts.

• Consider how and if you want to backup your authenticator codes. After you’ve got all your accounts set up with two-factor auth using an authenticator app, you need to think about what might happen if you lose your phone. With an app like Google Authenticator, you will lose the codes if you have to get a new phone and restore from an iCloud backup. There are convenient options like Authy and 1Password that let you easily backup these codes and access from any device. There's also AndOTP with it's encrypted backup capability.

  1Password has a really lovely integration to also store these one-time password codes (and automatically paste them in when needed, depending on your app/extension/OS), but if you’re storing your second factor alongside your first, then you don’t really have two-factor authentication.

  This solution is fine for most people, but this section is about being a bit more paranoid, so I would recommend not using the 1Password integration for your one-time password codes. Sure, you’re probably very screwed already in the unlikely event that someone gets access to your 1P database, but it’s even better if your most vital accounts require one more step by not having the OTP codes there.

  The more extreme option is to manually keep track of the QR code or setup key provided when setting up 2FA for a TOTP authenticator on each account. Backing up these setup codes is a bit controversial and not recommended by the more hardcore security folks as it introduces another avenue by which you could be compromised if not securely stored. If you opt to backup your QR codes, you may want to store them outside of your password manager and in an encrypted manner. This could be on a service like Tarsnap, an encrypted Mac sparse bundle image or VeraCrypt volume. But now you have a new problem: how to securely store the passphrase or key for that service or volume.

• Don’t set a recovery email for your email accounts. Depending on your level of paranoia, you may opt to remove any recovery email addresses linked to your email accounts. The logic here is that every linked recovery email is another potential attack vector that could be used to gain access to your primary email account.

  If this sounds like a bit too much to you and you’re worried about just locking yourself out of your account, you should at the least ensure that the recovery email account has a strong password and two factor authentication enabled. And ideally this account is with different email provider, not added or logged in on any of your devices and is only used for recovery.

Switch your carrier to Google Fi

If you want another safety net

Even if you have done all you can to not link your online accounts to your phone number, there are always those services that just do not have two-factor authentication options beyond SMS. And that will always be a weak link in your security. You can do something like get a separate phone number that you only use for securing those accounts and don't use for anything else. You could also create a separate Google Voice number for that purpose; the benefit being that it's protected by your Google account's 2FA.

Or you can move switch your mobile phone carrier to Google Fi. I find this to be the simplest solution and have been using Fi for almost 4 years now. The security benefit here is that your phone number is now protected by your Google account's two-factor authentication, and is significantly less susceptible to social engineering attacks to gain account access.

I asked Google for more clarity on Fi security and was told the following. Basically, nothing is possible without access to the Google account already.

[...] we check for the authentication of their account and if a user contacts us with an unregistered email ID then we ask them to confirm their identity by sending secret codes to the email ID which they claim that have been registered with Google Fi.

Enable Google Advanced Protection

Consider Advanced Protection for your Google accounts

Google began offering something called Advanced Protection in late 2017. It offers enhanced security for those that might be at increased risk of targeted attacks. According to Google that includes journalists, celebrities, activists, business leaders, political campaign teams, firms dealing with cryptocurrencies and law firms. Fortunately, this functionality is available to anyone with a Google account and it brings some significant changes.

Targeted attacks could be low volume, carefully crafted, phishing attacks, often personalized to individuals, and can be hard to distinguish from legitimate activity. This makes targeted attacks the hardest to protect against. The Advanced Protection Program is specifically designed to thwart targeted online attacks on Google accounts.

—Google

First, Advanced Protection requires that you use security keys. It won't let you enable it until you pair two security keys to ensure you have a backup key. The main benefit here being that security keys prevent phishing. Google accounts with AP enabled also bring stringent changes like:

• Very strict account access rules for your emails and Google Drive files. This means you won't be able to use your Google account outside of native Google apps, except for a select list of trusted third-party applications like Apple Mail, Apple Calendar, Apple Contacts and Mozilla Thunderbird.
• App passwords are no longer supported
• Exhaustive Gmail scans to catch phishing messages and attachments containing malware.
• No recovery code. That’s right. If you don't have access to your password and one of your security keys, there is no way back in. You must go through the recovery process, which is much more rigorous and includes various delays on purpose. They may ask recovery questions like what month and year you first opened the Google account.
• Enhanced web browsing safety when signed into Google Chrome. Google will alert you if it detects you downloading a file it thinks is unsafe according to its Safe Browsing policies.
• And finally, I feel like Advanced Protection is more suspicious of activities and will aggressively prevent logging in if it thinks something is astray. I recall trying to test it out and logged in and out of my account on various devices and different IPs on VPNs and it was quick to prevent access.

Google Advanced Protection may be overkill for some people but it's a good segue into security keys and how they can help enhance your online security.

What are security keys?

The small hardware devices to enhance your online security.

Security keys are inexpensive, little hardware devices that use public-key cryptography to securely authenticate the website to the key. Maybe you've seen them around; these security tokens tend to look similar to regular USB memory sticks. Compared to using an authenticator app (also known as a TOTP code generator) as a second factor for 2FA, security keys (also called external or roaming authenticators) are a preferred and more secure option.

When you go to log into a website where you have registered a security key as your second factor, you are first prompted for your username and password and then for the key. Usually this means plugging in and touching a special touch sensitive area of the key (for USB keys), but could also mean bringing the key closer (NFC) or pairing and pressing a button on the key in the case of Bluetooth security keys.

Okay, sounds easy enough.. but a bit more of a hassle to keep another device handy, right? So what’s so great about these security keys?

It’s no coincidence that Google requires hardware security keys as the second factor method for Google accounts with Advanced Protection enabled. Google themselves pushed for their employees to use security keys and they saw that it entirely neutralized phishing attacks on all of their 85,000+ employees.

Compared to TOTP authenticators, the key benefit of using a security key is that they are immune to phishing attacks.⁶ This is partially due to the fact that the origin/domain of the website is taken into account when you register your key. If you fall for a credential phishing email and went to log into a look-alike fake website, verification would fail, even if you thought the website was real.

Security key history

FIDO, U2F, CTAP, WebAuthn.. where did it come from?

But first I wanted to briefly dive into the history of security keys over the last few years. For the purpose of this article, I want to refer to these hardware authenticators and security keys as just security keys. You may have seen them referred to as FIDO U2F, CTAP, FIDO2 and WebAuthn. It’s all very confusing and even the newer overarching and correct term (FIDO2) doesn’t quite roll off the tongue.

You may be thinking, wait a minute, I used hardware tokens years before this. And you’re not wrong. Code generating hardware tokens like RSA SecurID have been around since the early 2000s. They would continually display newly generated codes on their LCD display: codes that would often be appended to a password when logging in.

Then there were USB security keys in 2007 that would identify themselves to the computer as standard USB HID keyboard input devices and as such, not require any special drivers. When pressed, they would input a one-time password string comprised of things like counters, timers and random values. The one-time password would then be verified by the server based on a shared state (like the usage counter and device id) between the server and key.

While those keys sound a lot like the keys we have today, their implementation is quite a bit different and they are still susceptible to phishing and man-in-the-middle attacks.

Fast-forward to 2012. Google and Yubico collaborated on a hardware security key based on public-key cryptography. This eventually became known as U2F (Universal 2nd Factor) and became part of the FIDO Alliance (Fast IDentity Online), an organization initially founded by PayPal, Lenovo and other companies to work on a passwordless authentication protocol.

In 2014, Google officially shipped FIDO U2F support in their Chrome browser. The next few years brought better security key hardware, increased support from large, mainstream websites like GitHub, Facebook and Dropbox, as well as increased support from browser vendors.

Now, in 2019, we have the FIDO2 project. It recognizes the growing need to enable easy and secure multi-factor authentication experiences across both desktop and mobile devices to further the FIDO Alliance's goal while making strong authentication more accessible. FIDO2 consists of two distinct parts: a client API called WebAuthn (an official W3C standard created in collaboration with the FIDO Alliance) and an API for hardware authenticators.

FIDO2 = WebAuthn + CTAP

The first part, WebAuthn (short for Web Authentication), is essentially the client/browser JavaScript API that allows websites to create and use credentials based on public keys, which may come from hardware authenticators. It’s huge news that this is now a W3C standard so that every browser manufacturer can begin developing and supporting it. WebAuthn is the core link between the website server—frequently referred to as the Relying Party—and the browser.

The second part helps define the link between the browser and the external authenticator device. This protocol is called the Client to Authenticator Protocol, or just CTAP.⁷ This aids in all the particulars of how various hardware authenticators communicate with the browser, such as via USB, Bluetooth Low Energy and NFC.

What is passwordless?

What is this passwordless thing all about?

One thing I keep hearing about with respect to authentication these days is passwordless auth. Honestly, it just seems like a buzzword.. so what exactly is passwordless? I'll briefly describe the premise here and why it's not the focus of this article.

One of the primary goals of the FIDO Alliance at its inception was to provide "open and free authentication standards to help reduce the world's reliance on passwords." So far in this article when talking about FIDO1 I have only mentioned Universal 2nd Factor (U2F), which eponymously refers to enhancing two-factor authentication by using hardware security keys as a second factor.

FIDO U2F became well-known, in no small part to strong support from Google and subsequent integration into the Chrome browser. And well, U2F is comparatively easy to understand for people already familiar with two-factor auth... you just use a key you plug in as your second factor. Easy enough.

FIDO1 also contained a spec for something called UAF, Universal Authentication Framework. Its original goal was to provide a passwordless authentication solution employing biometrics. Similar to U2F, UAF utilizes public-key cryptography to authenticate with each service.

The difference is that UAF does not require any password. The browser asks the user to complete their previously registered authentication gesture, such as tapping their finger on a fingerprint reader or typing in a PIN.⁸ As such, it's called passwordless since no password is actually sent across the network. The authentication is done with the standard challenge-response auth as part of public-key cryptography.

Okay, so what about FIDO2? FIDO2 brings WebAuthn, which essentially merges the capabilities of U2F and UAF into one API that can be accessed by any supported browser or OS. People utilizing FIDO2 for two-factor auth with a security key as their second factor now have the ability to use a broader set of authenticators, such as internal platform authenticators like fingerprint readers and facial biometrics built into their devices. And finally, FIDO2 provides various passwordless authentication formats into the same system: passwordless single-factor or multi-factor.⁹

All of this work is done to make passwords obsolete...why?

Passwords have several notable issues. Strong passwords are hard to memorize, they take time to type, many people still use the same password for all of their accounts and it's easier to be phished with just a password. And of course, should anyone get access your password, they can just use it right away to log in.

But these seem like relatively solved issues today, right? We have robust password managers and we have two-factor authentication. The thinking behind passwordless is that those are just workarounds to an ancient authentication system that should be re-imagined with the latest technology we have at our disposal today.

We already have a taste of what FIDO2 brings today with enhanced authenticator support: you can use Touch ID on your MacBook Pro in Chrome, the fingerprint reader on your Windows 10 device via Windows Hello or even use the Pixel 3 Android phone itself as an authenticator, storing credentials inside its Titan M security chip and more. And you can imagine that in the future smart watches could begin to function as authenticators too: Apple already lets you use your Apple Watch as a proximity-based authenticator to unlock your Mac.

The passwordless vision is compelling but feels quite a few steps away. First, barely any websites even support passwordless authentication flows.¹⁰ Second, passwordless functionality requires storing data like display name and relying party name on the security key itself—something that doesn't happen when simply using your security key as a second factor. This is called a resident key credential and this data takes up space. Modern YubiKeys only have storage room for 25 resident keys¹¹ for use with such passwordless auth. Sure that might be a moot point if we all end up using internal platform biometric authenticators¹² for everything, but biometrics aren't a flawless¹³ solution:

Biometrics are easy, convenient, and when used properly, very secure; they're just not a panacea. Understanding how they work and fail is critical to understanding when they improve security and when they don't.

—Bruce Schneier, Security expert

The very compelling counter-argument is that, well, people just know how to use passwords and not everyone understands (or cares!) about security. We've finally made some headway on getting people to use two-factor authentication.

It's for those reasons that I would like to focus on the here and now: learning about the benefits of hardware security keys and how you can begin using them today with many services you already use.

Security keys vs. auth apps

Are security keys really any better than TOTP code generator apps for 2FA?

Before I go into detail about how security keys work and their benefits, it might make sense to talk a bit about the issues with using authenticator apps for two-factor auth.

TOTP risks

Why authenticator apps aren't perfect

Even though they are a vastly preferred second factor compared to SMS, authentication with TOTP (Time-based One-Time Password) has some risks and inconveniences compared to security keys employing public-key cryptography.

• Lack of phishing prevention. A huge issue with TOTP is that there is no inherent replay attack protection. You could still fall victim to a fake website (or real one being proxied via man-in-the-middle like with Evilginx 2 and Modlishka) looking exactly like a website you visit and supply your password and TOTP codes to them. The attacker or bot can then log into the real website as you and still be within the TOTP time limit.

• TOTP employs a shared secret. With TOTP, the website has a secret key it provides to you. This is the key your authenticator app uses for initial setup. The TOTP authenticator then generates a hash with the secret key and the current time. The website does the same thing on its end, using the same secret key it has, and compares the two.

  The issue is that the user and the relying party website share and store the same key. Unless the website followed the security recommendation in the TOTP spec to encrypt the secret key and only decrypt when in use to limit exposure in memory, it’s possible an attacker could generate TOTP codes for any account.¹⁴

• Manual code entry. A significant and frequent annoyance with TOTP codes is that you have to manually type in the code each time: not to mention open your phone, then open the authenticator app. There are, however, methods of simplifying this with desktop authenticator apps, especially with password managers like 1Password automatically copying and pasting it in for you, but you don't really want to have your password manager also store OTPs.

• Backing up TOTP authenticators is a hassle. Lose your phone where you had the only setup of Google Authenticator? You will need to proceed to account recovery for every account you had in there, which may go through an SMS (hopefully you’ve disabled this already!) or email reset flow. That’s annoying.

  There are some modern solutions to backing up and syncing your authenticator app in the cloud like Authy, using the OTP integration in 1Password or managing andOTP encrypted backups. But that’s up to you to decide if those routes are for you as they have some downsides. You can also decide if you prefer to backup the TOTP setup secret key or QR code, but it would need to be stored securely as to not introduce another attack vector.

  But I digress, my point here is that backing up your authenticator is yet another thing to think and worry about with TOTP.

Security key benefits

No shared secret, phishing prevention and much more

On the other hand, security keys work in a very different manner and avoid many of the issues inherent with TOTP authenticators. Security keys are based on public key cryptography, meaning there is no shared secret between the user and the website. The benefit here is that even if a website was breached and an attacker gained access to a user's public key, they would not be able to do anything with it.

In addition, security keys are designed to make it impossible to get the private key out of the security key itself as cryptographic functions are computed locally on the device and never exposed to the computer.

• Bulletproof phishing protection. The largest benefit of security keys is that they entirely thwart phishing attempts unlike TOTP authenticators. The exact domain name of the website is taken into account when the security key is registered. Even if the user willingly tried to log into a fake phishing site, the security key authentication would not work as the domain would differ. There's also support for token binding which furthers this protection, though I'm not sure it is widely supported yet.

• Security keys prevent replay attacks. Security keys are designed to never expose private keys outside of the hardware. However, should they somehow be cloned, they contain a signature counter. The WebAuthn spec says the security key should provide an incremental counter to the relying party on each successful authentication. Should the value not match the last known value, the authentication should fail. I say should because this is not a strict requirement for WebAuthn and it doesn't appear to be common yet.

  In addition, security keys and the relying parties utilize a challenge-response authentication flow to ensure single use and further prevent replay attacks.

• Built-in user presence required. One of the core features of security keys from the beginning has been that they require user presence before the key can do any cryptographic operations. All security keys require you to prove your presence by physically touching a capacitive touch sensor (or button for Bluetooth keys). This prevents remote takeovers as the user has to prove their physical presence to the device. Newer FIDO2 keys support user verification where you need to provide a PIN or a biometric gesture like a fingerprint tap (like with the upcoming YubiKey Bio with integrated fingerprint reader) if configured as such.

• No typing in codes. And after you tap the key, that’s it. There’s no more work to do, you’re already logged in. However, this assumes you already have the key plugged in your machine and don’t have to fish it out of your pocket or bag.

• Easy to backup. Backing up a security key is easy—just buy spare security keys and register them on each service!

• Privacy as default. And finally, since security keys generate unique public/private key pairs for each website, it is impossible for anyone to know what sites are registered to your security key. Even if your key is stolen, there is no way to know what websites it is used with, or any associated data.¹⁵

Types of security keys

How many keys do you need? How much do they cost?

That’s a long way of saying that security keys are a terrific option to increase your online security. Now we can go into some more actionable info: basics about the security keys themselves, how many you need and what kind.

You’ll need to buy some security keys of course before you can get started. FIDO2 and WebAuthn paint a vivid picture of the future of authentication from supporting more types of authenticators—from numerous internal biometric sensors to more types of mobile devices—to supporting passwordless authentication flows.

As I mentioned earlier, external security key authenticators are the easiest to incorporate into your daily life today compared to passwordless auth. It won't be perfect though: there are still some inconveniences and support issues associated with using security keys for your two-factor auth that I’ll dive into later.

How many do I need?

Yes, you need to purchase your security keys and they are not free. This is quite different than past solutions like SMS and TOTP authenticator apps. But it’s a small price to pay for enhanced security and phishing prevention. Security keys come in many varieties (USB-A, USB-C, NFC, Bluetooth LE and most recently, Lightning connector) to interface with computers and mobile devices.

There are benefits to using only one security key, but having multiple keys to rely on as your second factor is ideal.

• Purchase two or more keys if you want to rely entirely on security keys—and fully disable SMS and TOTP authenticator apps where possible—you will want at least 2 keys so that you can have a backup key. That being said, most services let you program many keys so there is not much harm in having a few more (unless they are too easily misplaced or haphazardly stored and fall into the wrong hands). You may also find it handy to have small "nano" keys that always stay plugged in your computer.

  You will need at least two keys if you want to consider enabling Google Advanced Protection on your account.

• Purchase one key if you want to test it out. There is still a strong benefit to just using one security key as a second factor in addition to a TOTP authenticator app as your backup. By relying on your security key to authenticate as much as possible, you’ll still receive the strong phishing protection that comes with security key usage.

How much do they cost?

Depending on feature set and durability, security keys range in price from around $10 all the way to $100+.

• Entry-level: At the entry-level, we have security keys that cost something like $12 HyperFIDO Mini, $20 for a Yubico Security Key and the open source SoloKey.

  These cheaper keys tend to be strictly for authentication via one protocol only and won't support additional protocols and software customization that pricier keys have—which is totally fine. Some keys in this price range may only support FIDO U2F and not the latest FIDO2 spec (aside from the model by Yubico). This means you can't use them for new WebAuthn passwordless functionality if that matters to you.

• Mid to top tier: The main players in this space are Google (with the Google Titan Security Key bundle as well as the just-released USB-C version that is similar to the Yubico 5C) and Yubico with their latest YubiKey 5 series offerings like the flagship $70 YubiKey 5Ci featuring dual USB-C and Apple Lightning connectors.

  At this level you start to see more durable keys with better build quality, as well as support for many applications in addition to FIDO U2F and FIDO2¹⁶, such as Yubico OTP, Smart Card, OATH and OpenPGP. But most of these probably mean very little to you unless you're a developer.

• Advanced & specialized: At the high-end there are devices that do much more than just U2F authentication and have robust, integrated password managers and cryptocurrency wallets. Trezor and Ledger both offer models in the $50 to $120+ range.

I should also mention that there is a slowly growing category of devices not listed above that will become more important in the future as passwordless auth expands: external FIDO2 biometric authenticators. These devices are full-fledged FIDO2 security keys but also contain a biometric sensor like a fingerprint reader.

The fingerprint reader comes in handy for local user verification (instead of a PIN) for multi-factor passwordless auth. For example, like this Feitian BioPass authenticator. But I can't vouch for that brand and don't know if it requires special fingerprint drivers like similar models do. But I digress, this doesn't matter right now, especially as I'm focusing on two-factor auth security key uses.

Update (Nov 2019): Yubico has since announced that they are working on YubiKey Bio, a security key featuring an integrated fingerprint reader that has no battery and requires no additional drivers or software to function. Unfortunately, it appears that this first biometric security key from Yubico is only USB-A.

Compatibility issues

A look at what supports WebAuthn

There are two pieces to successfully adopting security keys: support for FIDO U2F or FIDO2 WebAuthn from websites you use and the same support on the browsers and devices you wish to use to access those websites or apps.

Both have been a bit confusing for various reasons. Take website support of FIDO U2F or FIDO2 WebAuthn for example. A website may support one of those and let you register your security key, but it's up to the site's specific two-factor auth implementation to determine whether you will be allowed to register multiple security keys and/or use security keys as your only type of second factor. One reason is that that website's accompanying mobile app may not support security key login and they don't want to have to explain this trade-off to users.

Spotty browser support has been a big issue over the years. This really comes down to the devices you use, as well as their current state of support for security keys. While security keys come in many flavors spanning USB-A, USB-C, NFC, BLE and Apple Lightning connector, just because the port fits into your device doesn't mean it will work everywhere on your device.

Support for security keys is by no means ubiquitous across devices, operating systems and browsers and websites. Things have gotten much, much better over the years and really, the only real rough patch lies with iOS. I'll dive into a brief description of the current support landscape right now, but one way to keep up to date on WebAuthn support status is by checking CanIUse.

Android - Great support

Android support for security keys is in a great state, and that's no surprise with Google's push for U2F, and now WebAuthn, since the beginning. Chrome and Firefox enjoy full FIDO2 support and this means you can easily opt to use USB, Bluetooth and NFC security keys, along with any integrated biometrics such as your device's fingerprint reader. (However, Brave browser and Firefox Focus did not appear to have functioning security key support at the time I wrote this.)

In addition, the Android OS itself is FIDO2 certified. The OS-level integration means that browsers and other apps only need to make an API call to trigger Android's robust auth flow that handles everything.

iOS - Great support (Updated 2024)

Update 2024: Things have come a long way and you're no longer at a disadvantage using a security key with iOS.

---

The state of security key support on iOS used to be utterly horrible. The native Safari browser didn't support any kind of web authentication. The only option was to use a special Lightning connector security key and a different browser that had security key support baked in (Brave for iOS).

The only other way to work around it was with custom solutions employing Bluetooth security keys. Google lets people use security keys on iOS by redirecting to a separate app called Google Smart Lock that can pair with Bluetooth security keys—an annoying, one-off and clunky solution only for Google services.

Fortunately, things have changed for the better. They're still not great, but they're on the right track. As of December 2019, Apple released iOS 13.3 which brought Safari support for WebAuthn using USB, NFC and Lightning connector FIDO2 security keys.

Even though Safari supports WebAuthn now, this does not mean that everything on iOS will. Many apps are in need of software updates to let you use security keys. Since iOS had no security key support for ages, it's likely that many apps just incorrectly assume that iOS as a whole can't interface with security keys and won't even let iOS users provide their security key. Gmail is one such example: both the iOS app and website in Safari won't let you use a USB, NFC or Lightning connector security key yet. Update (Jun 2020): Google now supports USB, NFC and Lightning connector security keys for WebAuthn on iOS!

This is also the current state of support for the aforementioned YubiKey 5Ci Lightning connector security key. It only works with a small set of apps and browsers like 1Password, LastPass, Safari and Brave browser.

A note about NFC keys Don't modern iPhones have NFC? Can't we use that along with NFC security keys for authentication?

Fortunately, the short answer is yes! Unfortunately, this was literally only possible until late in 2019 with iOS 13 bringing full read/write NFC support to devices like the iPhone 7 and newer. And then it wasn't available to consumers until iOS 13.3 brought NFC key support into Safari in December 2019.

In the past iOS provided read-only NFC access on iPhones. You might have seen some examples of NFC security key authentication on iPhones in the past (in case you've seen the LastPass integration advertised). Those solutions have also been proprietary (sound familiar?) and required custom integration with the YubiKey Mobile SDK as they did not use FIDO U2F or FIDO2/WebAuthn, but instead used the proprietary YubiKey OTP. That was the only option at the time because FIDO U2F and FIDO2 require NFC read-write access to function, which iOS did not allow at the time.

Safari does now support the use of NFC keys and it's a great and easy experience. App and other browser developers (looking at you Chrome!) will still need to manually add support for this functionality. Yubico Authenticator for iOS was recently updated to support NFC keys so you can also use the key for TOTP code generation purposes in addition to WebAuthn. However, NFC is not a perfect solution with mixed support: current iPads and older iPhones don't have the necessary NFC hardware.

Update (Jun 2020): Google now supports NFC security keys for WebAuthn on iOS, so if you're primarily using a security key for Google products and services, now is a great time to consider an NFC key.

Buying your keys

NFC, BLE, USB-C, oh my! What to choose?

Hopefully you now have enough context about the compatibility landscape to help you make an informed decision about what security keys to purchase given your mobile and desktop computing needs today.

If every type of security key was well-supported everywhere, you would probably just want a USB-C key for your computer and NFC key for your mobile devices. Holding your NFC key up against your phone for a moment is such an easy task compared to plugging anything into the USB-C port—dramatically easier than using a Bluetooth key that constantly needs to be charged, uses an archaic Micro-USB port and has to be paired.

But that would be too easy. Unfortunately, we're stuck with a not-so-great matrix of varied security key support across devices, operating systems and browsers. Below I've put together some personal security key recommendations depending on what mobile device you use. I focused on mobile devices as the differentiator as desktop support is already fantastic for any USB key.

An ode to Yubico

I really love Yubico security keys. It's no surprise that one of the original companies pushing for strong authentication online knows the importance of high quality, durable hardware. I’ve never had any issues with Yubico build quality and their higher-end YubiKey series supports a robust feature set that's customizable with software. It costs a premium but you can trust it and they are known to do recalls if they suspect there are any issues that could affect security (they replaced one of my older 4C keys).

If I had to nitpick, their software (YubiKey Personalization Tool, YubiKey Manager, Yubico Authenticator) isn't simple or well-designed.

There is, however, one significant criticism about Yubico keys from security folks in the industry. It's that Yubico's keys are closed source, preventing developer community-sourced verification of secure code along with the ability to update and modify the device however the owner wishes. For customers that fall in that camp, there are open source options like SoloKeys.

Hopefully that all made some sense! If you're still not sure what you need, it might be worth checking out this quiz from Yubico to help you find the right security key for your needs.

Registering your keys

Using security keys for two-factor auth

So you've purchased a security key or a few and are ready to set things up.. great! Each security key you own must be registered with each service you wish to use it on such as Google, 1Password, Facebook, GitHub, et cetera.

You'll register each key one by one. Usually navigating to the website's settings page related to two-factor auth and finding a button to add a key. This assumes you've already setup two-factor auth. Then when prompted you plug your key in and tap it. Depending on the website you may be prompted to type in a name for each key. This step is vital as it helps you identify which key to remove from the service in the event you lose that key and have multiple registered on the same service.²²

And that's pretty much it. Once a key is registered with a service, the next time you log in ²³ it's as easy as touching your security key when prompted after entering your username and password.

That's generally how two-factor authentication with security keys works but these things differ from website to website depending on how they've implemented things. For example, you may be prompted for a code from an authenticator app instead (if you have one added as a second factor option) and are in a browser that does not support FIDO U2F or FIDO2 WebAuthn.

You can check to see if the websites and services you use support security keys by taking a look at DongleAuth.info. It's also easy enough to search the settings pages of the websites you use for any mention of security keys for two-factor authentication.²⁴

Setting up Google Advanced Protection

Google's strongest, security key-required security program

I mentioned the benefits of Google Advanced Protection earlier in this article. It is designed to help thwart targeted attacks by requiring the use of security keys, in addition to numerous enhanced security measures.

Signing up for Advanced Protection follows the same process I mentioned above: enable two-factor auth, register and name two security keys and you're ready to go.

Advanced Protection has some aggressive requirements: you must register at least two security keys, you can't add any TOTP authenticator apps as a second factor and there's no recovery code. You can however add an approved Android device as an authenticator. Google requires having two keys with Advanced Protection so that one can operate as a spare should you lose one.

Use G Suite? You'll have to enable it first.

If you use the enterprise G Suite for your email, you may not have the option to even enable the Advanced Protection Program until your administrator has turned it on. If you run G Suite for yourself, you can read about enabling the beta here.

What about regular Google accounts?

If you're not ready to make the jump to Advanced Protection

If you just want to test the waters a bit with security keys and don't think enabling Advanced Protection is for you at this time, you can always just register keys as part of any Google account's regular 2-Step Verification settings.

The process for adding a key is similar to the Advanced Protection flow from above but you just navigate to Google Account → Security → 2-Step Verification → Add Security Key.

With regular Google accounts, you're free to mix second factor authentication types from SMS to authenticator apps and even other phones using Google 2SV phone prompts. Of course, I strongly advise against using SMS at all.

1Password

If you use the hosted option for 1Password password manager, adding your keys is a simple process as well. Just log into 1Password.com, click your name in the corner then navigate to My Profile → More Actions → Manage Two-Factor Authentication → Add a Security Key.

You can add as many keys as you like. However, the current 1Password implementation does not yet allow you to remove the authenticator app as a second factor. Since people often use 1Password on their mobile devices in addition to their desktop computers, they would likely only support security key-only authentication once every 1Password mobile app offered security key support.

Only the 1Password iOS app supports physical security keys at this time and via a custom Yubico Mobile SDK integration only supporting the new and expensive Lightning connector YubiKey 5Ci.. so definitely not for everyone just yet.

Update (May 2020): 1Password for iOS now supports NFC security keys, though only the YubiKey 5 NFC for now it seems.

Will 1Password ask for my security key every time?

Adding a security key does not mean that 1Password will ask for it every single time you need to open 1Password to log into an account: something that likely happen many times throughout the day for you. 1Password only really asks for your security key when adding your 1Password account to an untrusted device like a new browser or desktop app.

Fastmail

Fastmail is a popular non-Google email service that has supported security keys for years now. It also lets you entirely remove SMS, recovery codes and authenticator apps if you so wish. Setup is trivial as well: Settings → Password & Security → Two-Step Verification → Add Verification Device → Set Up Security Key.

Facebook

Of course, you can register your security keys with your social accounts like Facebook as well. The process is the same: find the two-factor auth section in the account settings then add and name each of your security keys.

Registering keys on other services

If you have any questions about how to set up your security keys on other services, Yubico maintains a well-documented section on their site for just about every supported service.

What about mobile?

It's easy on Android, less so on iOS..

By now you've registered your security keys and figured out how to log back in with them on your desktop browser. But how do you login on your mobile devices with security keys?

As I mentioned in the Android section earlier, it's a breeze. The operating system itself (well, Google Play Services technically) supports FIDO2 so any website or app should trigger this authentication activity view, giving you numerous authentication options such as with NFC, USB and Bluetooth keys.

It's not the same with iOS. You're out of luck if your main browser is Chrome for iOS as it does not have support yet. While iOS 13.3 brought support for USB, NFC and Lightning keys to Safari, not all apps and services have taken note yet.

If you use a Google account on your iPhone or iPad, however, you do have another option. Google has a separate authentication app called Google Smart Lock for this purpose. You log into all of your Google accounts in the Smart Lock app—it supports Bluetooth security keys—and it can redirect you back to the app you came from to complete your authentication. This works for native Google apps as well as apps utilizing Google login.

It's not a perfect solution but you don't have much of a choice for Google apps and services on iOS right now. Even attempting to log into Gmail in Safari does not let you use a security key directly in Safari; instead it tries to redirect you to Google Smart Lock.

Having to install a separate app just to use your security key is a hassle. Then you add on to that some general Bluetooth security key woes: having to pair the key, having to keep your security key charged at all times, having to carry around a MicroUSB cable around to keep the key charged, having the key's button always accidentally get pressed in your bag and drain the battery. Annoying.

However, I'm hoping that in the first few months of 2020 we'll begin to see more apps and services update to support security keys, at least via utilizing SFSafariViewController to take advantage of the existing WebAuthn implementation.

Bonus: Pixel 3 as a security key

Take advantage of the integrated Titan M security chip

This probably isn't what you have in mind right now when you think about a security key. For most of this article I've been talking about external hardware authenticators that you plug into your computer or mobile device. But they don't always have to be separate from your device.

More and more devices have integrated security chips, some Google Chromebooks even have an integrated "H1" chip that can be used for FIDO U2F auth. These integrated security chips may go by various names like secure element, TPM and Apple's Secure Enclave, but the gist is generally the same. They are secure cryptoprocessors that have a secure boot process and microkernel to completely isolate itself from the rest of the hardware. Much like USB security keys, the system cannot access the secrets stored on the security chip: the chip itself just runs computations. Now, with WebAuthn and initiatives like this Google solution I'm about to describe, there are more ways for these chips to be used for web authentication.

But I digress... the Pixel 3 has a "Titan M" security chip that can be used to store your cryptographic keys for second factor authentication. This is similar to how an external security key is used to generate a unique public/private key pair for auth. When you go to Google account settings to add another second factor for 2-Step Verification, it will display a prompt to add your Android device if it recognizes that your Google account is logged in and supported. While it supports any Android device running Android 7+, it's only the Pixel 3 (and I'm guessing the new Pixel 4 can do the same) that features this enhanced protection. (Update January 2020: Google has updated the Smart Lock app for iOS to enable similar functionality for iOS users.)

It's important to note that this is not the same type of phone prompt you may have seen in the past where your phone receives a login request notification via the cloud. This new implementation is quite novel: it's local proximity based, and as such it requires Bluetooth to be enabled on both devices. Also, Google was able to get this working entirely without requiring Bluetooth pairing, which is always a hassle. They developed an extension to WebAuthn that introduces pairing-less secure communication between your computer and the mobile device.

When you log into your Google account, it will communicate with your phone locally via Bluetooth. Similar to an external security key, user presence is required in the form of a physical press. Google had the security chip hardwired to the Pixel 3's volume down button. As such, not even malicious software running on the phone would be able to control the Titan M chip on its own.

Why does it ask for a PIN?

Set a PIN to enhance user verification on your FIDO2 key

If you're using a FIDO2 security key you may have been prompted at some point during the registration process or elsewhere to set or enter a PIN for the key. This was confusing to me the first time it happened, especially when I was using my key as a second factor.

Of course, there is a reason for this. But first, I'll go ahead and say that for the purpose of using the key as a second factor only, you don't need to set a PIN.

The PIN is there to enable a form of multi-factor authentication for passwordless authentication flows. We're not quite there yet as not many services support passwordless functionality, but the modern security keys support it. FIDO2 keys have the ability to store username and password credentials directly on the key, via FIDO2 resident credentials.

This is a significant change to how things were done with FIDO U2F where it was not possible to know which services had been registered with the key. Now with resident credentials it's possible for someone to ask the key to list out what domains it has been registered on or just what accounts exist on the key for a given domain. As such, you need a way to add a stronger user verification step to limit that access. In this passwordless world, your FIDO2 hardware key can require user verification with a PIN that is local and stored directly on the key itself, or it can require something like a biometric gesture if the device has such sensors/readers and was configured that way.²⁵

But wait, I thought this was supposed to be passwordless.. why do I need to set and remember a PIN? Yubico has the reasoning here:

A PIN is actually different than a password. The purpose of the PIN is to unlock the Security Key so it can perform its role. A PIN is stored locally on the device, and is never sent across the network. In contrast, a password is sent across a network to the service for validation, and that can be phished. In addition, since the PIN is not part of the security context for remotely authenticating the user, the PIN does not need the same security requirements as passwords that are sent across the network for verification. This means that a PIN can be much simpler, shorter and does not need to change often, which reduces concerns and IT support loads for reset and recovery. Therefore, the hardware authenticator with a PIN provides a passwordless, phishing-resistant solution for authentication.

—Yubico

Final words of advice

Keeping track of your keys

If you're like me you probably have quite a few websites you will be using your security keys with. If you have more than a few security keys it may be handy to make a spreadsheet of each key you own and each service it is registered on (or in your password manager, add a note for each login about what keys are registered with each service.

Done. Now I’ll just have to wait for banking hours when I lose my other u2f keys and lock myself out of my accounts 😂 pic.twitter.com/kC2NmX8TTa

— Paul Stamatiou 📷 (@Stammy) August 15, 2018

This is particularly handy if you store any of your keys at separate locations for safekeeping and need to know which ones to register on new services when you get a hold of them next.

Which brings me to my next point, if you have more than one security key, you should keep the spare somewhere safe. That could be a trusted friend or family member's house, it could be your place of work, a bank safe deposit box, et cetera. Unless you think you could be targeted, this is likely just to prevent you from misplacing the spare security keys at your place.

Pro tip: Disable Yubico OTP mode

There's one common annoyance with the default YubiKey configuration: accidentally tapping the button on a YubiKey will make it begin spewing out a large string of random characters each time. Contrary to popular belief, this is not related to actual FIDO/FIDO2 functionality. It's a mode specific to YubiKeys for another type of authentication that you probably won't be using: Yubico OTP.

This is distinct from the TOTP you already know about for generating app codes, and different from using your YubiKey to store TOTP secrets. Here's more detail about Yubico OTP.²⁶

The point here is that having a long string accidentally get inputted into whatever application or document you were working on will drive you crazy. It happened to me one time when I was working in Adobe Lightroom as I reached over to plug in a USB SD card reader and accidentally tapped the YubiKey in the other USB port.. and let me tell you, Lightroom went crazy and interpreted every keystroke as a command. It took me a while to undo that mayhem.

Needless to say, I disable Yubico OTP mode on every YubiKey I own. Fortunately, it's very easy. Install the YubiKey Manager app and uncheck OTP mode:

On the Interfaces tab uncheck OTP and save.

FAQ

Because this is entirely more complex than it should be

What is a security key?

Security keys, security tokens, U2F keys, roaming authenticators, platform authenticators—whatever you want to call them—are hardware authenticators that run public-key cryptography operations in a manner that is entirely isolated from the rest of mobile device or computer. There are two general classes of security keys: internal platform authenticators and external roaming authenticators.

Platform authenticators are integrated inside of a device. They may take the form of an integrated security chip accessible by software for the purpose of web authentication, such as the security chip in the Pixel 3, or biometrics devices like fingerprint readers and facial recognition sensors.

This article has primarily been about other variant: roaming authenticators. These are the little external hardware authenticators you connect to any device (via Bluetooth LE, NFC or USB) to carry out your authentication needs. They communicate with your computer via FIDO CTAP (Client to Authenticator Protocol).

In one sentence, why is a security key better than an authenticator app for two-factor authentication?

There are several reasons (view the keys vs TOTP section above), but the main one is that security keys prevent phishing by using public-key cryptography that verifies the domain you're attempting to authenticate with is the same one you originally registered your key with.

What services and browsers support WebAuthn?

See the compatibility section above. For the most part, support is great across Windows, Linux, ChromeOS, macOS and Android. iOS is getting there with recent Safari support for USB, NFC and Lightning connector security keys. However, many iOS apps and browsers still need to catch up.

As for what websites support FIDO2 WebAuthn (and the earlier FIDO U2F) for two-factor auth, it's probably easiest to just log into the website and poke around the security and two-factor auth sections. You can also check DongleAuth.info or the Yubico catalog. FIDO2 WebAuthn also supports passwordless functionality but the vast majority of websites do not support that at this time.

How often do I need use my security key?

This depends on the exact implementation for each website, but for the most part: not that often. Most services only prompt for your security key if you are using an untrusted browser or device. For example, after logging in the service will mark your browser as trusted for 30 days, or until you log out. However, if the service thinks something is weird like you are logging in from a different IP in another country or you're in a new browser, you will need to do the full two-factor auth login with the security key.

For mobile apps like Gmail, it seems to not automatically expire the trusted client status. You only need to present the security key the first time you add your Google account to the phone.

Whether this means you should carry around your security key with you at all times is up to you. But if you're traveling, I would definitely take it. And a second key as a backup (assuming you still have a spare somewhere else safe) that you store in a different place while traveling. This is similar to how I travel with SD cards when on photography trips. I keep a set of SD cards on me and a duplicate set of SD cards (or imported to my computer if traveling with one) at my lodging, until I'm able to get home and load it on my NAS.

What happens if I lose my security key?

You just log in with your spare security key and remove the security key you lost from the account. Easy.

To get more specific: This depends on the service, but it's almost certainly the case that you have several other second factors you can use to login with (be it backup security keys or TOTP authenticator apps) or that you have a recovery method configured (email reset or recovery code). Since you are still able to log into your services, you just need remove the lost security key from your account. That's why naming the key something specific, like the model name of the key, is handy to help you figure out which key to remove from the account.

Removing the lost security key also protects you in case you happen to lose your remaining second factor key(s) or do something like accidentally wipe a phone that had your only TOTP authenticator app that wasn't backed up. If that happened, the service would still think you have your second factor handy and would prevent login. Of course, depending on the service and how you configured it, it might still allow recovery.

What happens if someone else gets access to my security key?

The short answer here is that you're still protected. Someone can't use your security key to log in as you wherever you have it registered as your second factor. For one, it's a second factor. They would still have to know your username and password. Second, they would have to know what websites you have your key registered with. And they cannot get that from the security key—it doesn't even exist in the key. This gives you enough time to remove the key from your account when you notice it's lost or stolen.

The more complicated answer emerges if we begin talking about newer FIDO2 functionality intended for passwordless authentication. FIDO2 resident key credentials are a way of storing the username along with other data on the actual security key itself. When the server requests a credential from the client and only provides the origin to the key, the key has to know which resident (on the key) credential to provide. If there are multiple resident credentials for that website, it must provide a way for the user to select which credential to use.

Needless to say, the security key itself needs to have this info locally for this functionality and as such, there is a way for someone with access to your security key to list out the saved resident credentials.

However, it's important to note that this can be safeguarded with an optional user verification step requiring a PIN or biometric (PIN is more well-supported today). This only applies to services utilizing resident key credentials, which seems like it's only going to be single factor passwordless and not multi-factor passwordless configurations that have that extra verification step.

And finally, it seems like the ability to list out all resident key credentials is nascent, with only Yubico starting to offer this ability.

But for the most part, unless part of a highly targeted attack, chances are anyone that found the key would think it's a broken USB memory stick. Or if they know what it is, they could start using it themselves for their own U2F/etc needs and it would work just fine. You should be more concerned about attackers stealing your info online. Using a security key as intended is your best defense there.

Can I log into my Mac, Windows PC or Linux computer with my security key?

Support for using your security key to log into your computer is varied and in most cases will require a Yubico brand YubiKey, not a regular security key from another provider that lacks certain functionality.

Support for Windows login has had some ups and downs over the years but it just became officially supported with the new Yubico Login for Windows. Unfortunately, setting it up seems quite involved. It used to work with YubiKey 4 series keys alongside a Windows program called YubiKey for Windows Hello but that was deprecated and Yubico then pointed customers to a much older implementation called YubiKey Windows Logon.

MacOS users can use certain YubiKeys to log into their computers, but installation is definitely left to advanced users. And the story is the same with Linux: it's possible but challenging to configure the pam_u2f module properly.

Why does my YubiKey print out a bunch of random characters when I tap it?

If you tap your YubiKey—this only applies to YubiKeys— while your cursor is focused on any sort of input field, it may spew out a ton of seemingly-random characters. It's triggering a proprietary feature called Yubico OTP that is unrelated to standardized FIDO2/WebAuthn stuff. You can easily disable Yubico OTP mode on your YubiKey.

What else can security keys do?

Yubico brand YubiKeys feature a variety of technologies beyond FIDO U2F and FIDO2 capabilities, including: PIV/Smart Card, OpenPGP, OATH-HOTP/OATH-TOTP and Yubico OTP. You can manually configure your key to store ssh keys, GPG private keys, sign your git commits and more. It was also recently announced that OpenSSH will be receiving support for U2F, enabling your security key to be your keypair.

Personally, I find one of the more intriguing YubiKey uses is using it for TOTP code generation. This is handy for websites that don't yet support FIDO U2F or FIDO2 security keys but do support TOTP authenticator apps. Once configured, the YubiKey can store up to 32 credentials. They are accessible by plugging in your key and opening up the desktop or Android Yubico Authenticator app. Yubico has hinted that iOS app is on the way (Update: Yubico Authenticator for iOS is out now and supports the YubiKey 5Ci and NFC keys).

What's next?

A recap and look at the future of web authentication

Today we learned about improving your online security through several facets from using a password manager, removing your phone number from your online accounts and then migrating to security keys to protect against phishing attacks. However, being diligent about your online security and using security keys won’t protect you from every attack vector. If everyone began using security keys overnight, attackers would focus all their efforts on other attack vectors.

Not everyone needs the most paranoid level of security. It's always a trade-off between security and convenience. The more paranoid you get, the more likely you are to just lock yourself out of accounts.

On top of that, we need more sites to treat security keys as first class citizens. I can't even use multiple security keys on Amazon AWS yet and that's the place you would think would need it the absolute most. Why can't I opt out of SMS entirely on every service? Why don't more services let me only allow security keys as my only type of second factor?

As much as I want to evangelize how great security keys are today, lets face it— they're kinda annoying. You have this new device—probably several—to keep track of now. I don't expect everyone reading this post to go out and start using security keys right away. We shouldn't have to go through this much trouble to be a bit safer online.

The goal post with FIDO2 lies one step beyond what I've talked about here today about using these security keys as a second factor for two-factor authentication. The vision is around using devices you already have—phones with face scanning cameras, laptops with fingerprint readers, maybe even smart watches one day—to help authenticate you on websites securely.

The hope is that authentication may happen as passwordless but I really think that is a hard concept for people to grok after decades of being primed on how passwords work. I'll be keeping a keen eye on this space over the next decade.

Recap

Because this was long and complex

• Seemingly everyone is getting hacked today. SIM port and SIM swap attacks involve someone taking over your phone number, typically by socially engineering your mobile phone carrier. With access to your phone number, attackers can rely on your various online accounts having your phone number added as a two-factor auth method with SMS. Attackers can then begin gaining access to every such account (or via your email) and wreak havoc on your digital and financial assets.

  These attacks are becoming more common. If part of a targeted attack, it may not even matter if you have a PIN/passphrase set with your mobile carrier.

• Don't use SMS for two-factor auth. Google has shown that utilizing SMS as a second factor is still beneficial (compared to not having two-factor authentication at all) for automated attacks using stolen credentials, such as from data breaches. However, SMS is horrible for targeted attacks.

  But, in an abundance of caution, it is highly recommended to remove phone numbers and SMS recovery methods from every account where possible. Enable two-factor authentication everywhere and start with using an authenticator app/TOTP code generator for the second factor instead of SMS.

• You can increase your online security in a number of ways. There are numerous other security precautions and best practices one can follow depending on their threat model and comfort with increased inconvenience for enhanced security. The first and most highly-recommended is using a password manager, like 1Password. Further down the line, you may want to switch your mobile carrier to Google Fi and enable Google Advanced Protection for your Google accounts.

• Using a security key for two-factor auth prevents phishing. These tiny little devices are secure cryptoprocessors that utilize public-key cryptography to generate unique key pairs for every website. The website stores the public key while the private key remains isolated on the security key, inaccessible to even malware running on the machine.

  Security keys take the origin/domain of the website into account and will not allow successful authentication, even if the user is tricked into using it on a look-alike phishing site. This is something that authenticator/code generator apps cannot do. There are other benefits too.

• Security keys are just one part of the larger FIDO2 vision. Security keys live under an umbrella called FIDO U2F and a newer (and backwards compatible with FIDO) FIDO2 moniker. FIDO2 introduces a browser Web Authentication API along with a modern protocol for communicating with hardware called CTAP2. FIDO2 leads the way to a simpler and stronger online authentication with support for more devices, including biometrics already integrated into devices, as well as strong passwordless single-factor and multi-factor auth.

• Security key support is getting better—both websites that support it as well as browsers/devices—but it's not ubiquitous. It's not the best user experience today. You shouldn't have to carry around a separate device just to be safe online. WebAuthn aims to change that. But for now, security keys—combined with strong online security best practices—are a great way to fortify your regular online activities.

Footnotes

1 Of course, there are other ways to get your SMS two-factor codes—such as being phished via an official-looking text message to relay an SMS code.

2 And recently, much more with modern "passwordless" functionality that I'll dive into later.

3 Despite my entire pre-amble about SMS, it largely does help thwart mass attacks, as reported by Google. SMS as 2FA can still prove beneficial for automated bots trying to log into sites with your password from a data breach, but does not help much in the face of targeted attacks. This act of trying out stolen credentials on various sites is called credential stuffing.

4 This is a separate functionality that YubiKeys have in addition to typical U2F usage. It can function as a TOTP code generator once a security key is plugged into the device (they have desktop and mobile apps).

5And about authy: ​​Authy brings convenient multi-device support to the table. Accounts in Authy are encrypted with a passphrase and should be safe even if access is gained to your Authy account. Accessing the app can also be protected via PIN/fingerprint/FaceID. They have, however, had security incidents in the past that scared a lot of folks away.

6 Well.. when it comes to security, it's wise to never say never. DNS hijacking is the one attack vector that comes to mind. Token binding solves this but does not seem widely implemented. The same goes for security key counter checking..

7 FIDO U2F keys were part of the previous version of CTAP, so now they are labeled as CTAP1 under FIDO2. CTAP1 is backwards compatible with the latest FIDO2 CTAP2 protocol. Yea, there’s a lot of nuance in here..

8 I say authentication but this part is user verification, not authentication. The difference is the user is proving itself to the particular device instead of the website.

9 If you want to see an example passwordless auth flow, look at this slide deck from Yubico/Google (Start at slide 30).

10 Microsoft.com is the only one that comes to mind.

11 SoloKey, the first open source FIDO2 security key, supports up to 50 resident keys.

12 And if your computer doesn't have internal biometrics you can use for this purpose, you don't have many options. There aren't really any good CTAP2 devices on the market yet that include fingerprint readers. Update (Nov 2019): Yubico has announced that they are working on YubiKey Bio, the first biometric YubiKey that integrates a fingerprint reader for multi-factor auth purposes and does not require any batteries or custom drivers. This makes it ideal for enhancing user verification with biometrics (you can do old PIN-based too) when using passwordless auth. Unfortunately, it seems like this first device is only USB-A, not USB-C.

13 And for United States residents, you could be compelled to provide your biometrics to unlock a device and not invoke the Fifth Amendment, unlike a password.

14 They would still need your password but could try credential stuffing from any public data breach and hope to get lucky. Or if you had any malicious software running on your machine when you register a new authenticator, the provided secret key could be captured. I’m really getting into the weeds here, but in general having any shared secret can be seen as another potential attack vector.

15However, this gets complicated as FIDO2 brings new functionality called resident key credentials. This makes it possible to locally store the additional user data required to make passwordless authentication function, but also introduces the ability to list the stored credentials on the security key. Fortunately, there are ways to protect against this with additional user verification.

16 Unfortunately, Google's Titan keys do not support FIDO2 functionality at this time.

17 I have yet to come across another service that has an iOS app that allows it to utilize paired Bluetooth security keys like Google Smart Lock does.

18 Unless you are okay with using Brave browser along with the YubiKey 5Ci.

19 The Google Titan Bluetooth key is frustrating to use as there's no way to turn it off completely and it always turns itself on and blinks forever when in my bag or pocket, eventually draining itself so you need to have a Micro-USB cable handy.

20 Yubico also has FIPS versions of their keys that meet certain compliance requirements for special needs but they do not support FIDO2 (yet) so I would not recommend unless you know you need a FIPS 140-2 key.

21 Technically the Google Titan Bluetooth key also has NFC but it's not FIDO2.

22 I go into more detail about this "what happens if I lose my key" scenario in the FAQ below. This assumes you were able to log back into the website with your backup/spare key (or other form of second factor.. went through an account recovery flow) and want to prevent it from being used by an unauthorized person that finds it (this would be hard as they wouldn't know what account/username was registered to it.. but I go into detail about this in the FAQ too) or prevent you from getting locked out in the future.

23 A few caveats: it may not be the next time you log in if the service has you marked as using a trusted client. This depends on the service and how they categorize trusted clients. It could depend on a time period, different IP/location, new browser, et cetera.

24 Most websites that support security keys today tend to only support FIDO U2F and not FIDO2 WebAuthn. But that's fine for two-factor auth purposes. You're still accomplishing what we came here to do with this article: enhance your online security, prevent phishing.

25 Adding an enhanced, local user verification step like this to your passwordless single factor makes it passwordless MFA (multi-factor authentication).

26 There's also some, arguably paranoid, concern that you can be tracked across multiple accounts and websites by using Yubico OTP mode as part of the string used contains the device identifier of your key.