Was doing some work in a Rust project and realized I’d somehow ended up with both ed25519-compact and ed25519-dalek in the mix. Which.. didn’t feel ideal, and then Geoff sent me Henry de Valence’s It’s 255:19AM. Do you know what your validation criteria are?.

Umm. Woah.

I don’t really have a smart conclusion here beyond that. Just one of those posts where you get a few paragraphs in and your confidence in the shape of a thing starts evaporating. “Ed25519” was feeling to me like a much more stable and obvious bucket than maybe it deserves to be in practice.

Anyways, ed25519-zebra it is.

I released slugr tonight. It’s a small Rust CLI with almost no deps that renames files and directories into clean, URL-safe slugs. My Résumé (Final).pdf becomes my-resume-final.pdf. That’s basically it.

I built it because I kept running into the same annoyance. Downloads folder full of Screen Shot 2024-01-15 at 3.42.17 PM.png and Invoice (2) FINAL final.pdf and whatever other garbage macOS and the web conspire to produce. I sometimes want to work with these files in the shell and it’s a PITA to escape them, or if I wanted to cleanup a bunch with a sequence of shell one-liners it’s also a PITA since I can never quite remember the incantations and I’m terrified I’ll make a mistake or heaven forbid there’s a shell escape in a filename.. Seemed like a thing that should just exist as a tool.

The core of it is a library crate called fileslug that understands filenames. Most slug libraries are built for URLs and will happily turn archive.tar.gz into archive-tar-gz, which is obviously not what you want. fileslug knows about compound extensions, dotfiles, version numbers (app-1.2.3.dmg stays app-1.2.3.dmg), and all the weird edge cases that I could come up when you’re actually renaming files on disk. It does unicode transliteration via any_ascii so your CJK and accented filenames get sensible ASCII equivalents. Or pass --keep-unicode if you’d rather just normalize the separators.

Dry-run is the default, which feels important for a tool that renames your files. You see what it would do, and then pass -x when you’re happy. It won’t clobber existing files (appends -2, -3, etc. instead), handles case-only renames correctly on macOS’s case-insensitive filesystem, and does recursive directory renames bottom-up so paths don’t break mid-traversal. The kind of stuff that’s boring to describe but annoying to get wrong.

$ slugr "My Résumé (Final).pdf" "Photo 2024_01.JPG"
slugr: dry-run mode (use -x to execute)
My Résumé (Final).pdf -> my-resume-final.pdf
Photo 2024_01.JPG -> photo-2024-01.JPG

It supports kebab-case (default), snake_case, and camelCase. The whole thing is about 3,000 lines of Rust across both crates with 250 tests. Available via cargo install slugr, brew install vmunix/tap/slugr, or pre-built binaries for macOS and Linux.

This was another fun project built almost entirely with Claude Code. The whole thing from first commit to published crate took an evening. I still think it’s crazy to rely on these tools too much for “real” projects where you want to be able to reason about the architecture and so on, but for stuff like this I love it.

TL;DR: A coroutine function can return a value (like Detached{}) before its body has finished executing. If that function is an unnamed lambda, its captures — whether by reference or by value — live in the closure object, not the coroutine frame. If the closure is a temporary, it’s destroyed while the coroutine is still suspended, and all captures dangle. [&](this auto) -> Coro { ... }() fixes it. David Mazières’ The Most Vexing Capture explains the mechanics. This is a field report of getting bitten by it.

I spent a couple of days chasing a coroutine frame data race in a C++23 async RPC library. The fix ended up being a fairly small change to how we manage coroutine handle ownership. Finding it, however, was not small — it was one of those investigations where you end up reading compiler IR and staring at memory orderings until things start making sense. That kind of deep dive puts you in a particular headspace, and from that headspace we wrote a bunch of new stress tests to exercise the paths we’d been worried about. One of the tests that I wrote was a multi-threaded RPC write-buffer stress scenario.

Looked good locally to me, but on the very first CI run ASAN lit up on it:

ERROR: AddressSanitizer: stack-use-after-scope on address 0x7a6600201388
READ of size 8 thread T5
    #0 operator() rpcstress.cc:473

Stack-use-after-scope. The coroutine was reading from a stack frame that ASAN considered out of scope. Confusing, because the enclosing function was still running — blocked in a while loop right below the launch site. The stack frame was alive. So what was out of scope?

[&]() -> Detached {
  UniqueFd fd{socket(addr.ss_family, SOCK_STREAM, 0)};
  if (!fd)
    co_return;
  if (auto res = co_await cp.connect(fd, &addr); !res)
    co_return;
  auto c = rpc_stream(cp, fd.release())->client(rpc_v1{});
  // ... launch work on c ...
}();

That [&]() -> Detached { ... }() is an immediately-invoked lambda coroutine capturing by reference. And it’s a temporary. The closure is created, operator() is called, the coroutine suspends, and a Detached is returned to the caller — before the coroutine body has finished executing. Then the temporary is destroyed. All in one expression. The coroutine body, meanwhile, is suspended at co_await cp.connect(...) and will resume on a worker thread — at which point it reaches through a dangling this to access its captures.

This is exactly what the Most Vexing Capture describes. Lambda captures — whether by reference or by value — live in the closure object, not in the coroutine frame. If the closure is a temporary, it’s destroyed before the coroutine finishes, and all captures dangle. It compiles without a whisper. The lambda looks fine. The captures look fine. Everything about it looks fine, right up until the coroutine resumes on a different thread and the closure is gone.

The humbling part is I wrote this bug myself, in brand new test code, while actively investigating a different coroutine lifetime issue. I was already thinking hard about frame lifetimes and destruction ordering. Didn’t matter. The MVC is that invisible.

(this auto)

C++23 deducing this makes the fix a one-token change:

[&](this auto) -> Detached {
  // captures now survive suspension
  // ...
}();

this auto makes the closure an explicit object parameter — a coroutine parameter — so it gets copied into the coroutine frame. The temporary still dies at the semicolon, but the coroutine has its own copy of the closure and its captures.

One subtlety: this auto copies the entire closure into the coroutine frame, regardless of capture mode. Without it, both [&] and [=] captures dangle — value captures are just as dead as reference captures when the temporary is destroyed. With this auto, [=] captures are fully owned by the frame copy and safe. But [&] captures survive as copied references that still point at the original objects, so the enclosing scope must outlive the coroutine. If it might not, use [=](this auto) or explicit parameters. I think?

What sticks with me is how latent this class of bug is. Without ASAN in CI I’d never have caught it — the memory was still there, it would’ve kept working by accident. Undefined behavior the entire time. And any change to suspension behavior — tweaking initial_suspend, adding a co_await, refactoring a coroutine type — can reshuffle destruction ordering and expose MVCs that were previously hidden by luck. We’ve had this in the production code, mine just happened to only be in the test code designed to find other races!

Coroutines were only introduced in C++20 to make asynchronous code easier and safer to write. It’s my first time ever working with them, the only comparable I have really are Go’s goroutines which I’ve come to appreciate. Better than callback hell? Almost certainly. But they’re still brutally hard to reason about, in my experience so far. The abstraction is thinner than it looks. Maybe I’ll get better at it, we’ll see.

David’s post covers the language-level analysis and standardization path far better than I can. This is just a +1 from the trenches for (this auto) as the right default on any lambda coroutine with captures.

I’ve been building a live-coding glicol VST in Rust for shits and giggles and wanted a “native” EQ in the GUI because it’s convenient vs going back to the DAW and adding a seperate EQ effect, and I couldn’t just farm it out to the Glicol engine because that’s not what it’s for.

I found myself staring at a filter implementation that I first wrote by hand, and then had an LLM rewrite because mine clearly sucked and I hated it. I’m looking over the resulting LLM generated code, fairly impressed tbh, and noted Claude hadn’t used a “WebSearch” tool at all to create it, it just blasted it out “one shot”. Which had me wondering where it came from. Not in the existential sense — I know I asked an LLM to “make a 3-band parametric EQ that works withy my Mod abstraction, use best practices the way an experienced audio engineer would” — but in the archaeological sense. These coefficients. This structure. This specific hardcoded 0.9 buried in an alpha calculation. Where did this thing learn to do this? And is it any good?

Queue the rabbit hole that’s been the last 24 hours trying to figure out how LLMs synthesize “canonical” algorithms — and what that tells us about both the limits and the weirdly impressive capabilities of statistical pattern matching.

Turns out, the answer to “where did the LLM learn this” is:

Everywhere. And nowhere. It’s complicated.

The Starting Point: Naive Me

Let’s be honest about where I started. I knew I wanted a 3-band EQ — low shelf, mid peak, high shelf. I knew these were “biquad filters” from reading about audio DSP over the years. And I knew enough to be dangerous, which meant my first attempt looked like this:

pub fn process_sample(
    input: f32,
    freq: f32,
    gain_db: f32,
    sample_rate: f32,
    x1: &mut f32, x2: &mut f32,
    y1: &mut f32, y2: &mut f32,
) -> f32 {
    // Computing trig functions PER SAMPLE (44100 times per second!)
    let a = 10.0_f32.powf(gain_db / 40.0);
    let w0 = 2.0 * PI * freq / sample_rate;
    let cos_w0 = w0.cos();
    let sin_w0 = w0.sin();

    // Giant wall of coefficient math adapted from code I found on the internet...
    let alpha = sin_w0 / 2.0 * ((a + 1.0/a) * (1.0/0.9 - 1.0) + 2.0).sqrt();
    // ... dozens more lines ...

    let output = b0 * input + b1 * *x1 + b2 * *x2 - a1 * *y1 - a2 * *y2;
    output
}

It worked! In the sense that audio came out and it sounded vaguely filtered. But I knew it was bad. I just didn’t know how bad, or what “good” would even look like but I assumed examples on the internet I looked at probably weren’t it. So I asked Claude to improve it. And what came back was… different. Structured. Professional-looking. A separation between coefficients and state. A dirty flag for lazy recomputation. Proper stereo handling. All 300 lines of it.

But here’s the thing that nagged at me: I recognized patterns in that code. Not because I wrote them, but because they felt familiar in the way that all biquad implementations feel familiar if you’ve looked at a few. Which made me wonder — did the LLM actually understand what it was doing, or did it just really convincingly remix the collected wisdom of the internet?

Robert Bristow-Johnson Posted a Thing to Usenet in 1998

To understand what the LLM produced, you have to understand the source material. And for biquad filters, there is essentially one source: Robert Bristow-Johnson’s Audio EQ Cookbook.

Nobody remembers the original usenet post, but everybody uses those formulas. They’re in the W3C Web Audio spec now. They’re in every Rust audio crate I looked at. For example: (biquad-rs, fundsp). They’re in Python scipy discussions. Every tutorial on EarLevel Engineering. Every forum thread on KVR. The same damned formulas, copy-pasted across every programming language humans have invented. And when you ask an LLM for a biquad filter, you get… those formulas. Because that’s what “biquad filter” means at this point. The training data isn’t biased toward RBJ — it is RBJ, wearing different syntactic costumes.

Compare the cookbook’s lowShelf formula:

b0 =    A*[ (A+1) - (A-1)*cos(w0) + 2*sqrt(A)*alpha ]
b1 =  2*A*[ (A-1) - (A+1)*cos(w0)                   ]
a0 =        (A+1) + (A-1)*cos(w0) + 2*sqrt(A)*alpha

To what the LLM produced in my eq.rs:

let a_plus_1 = a + 1.0;
let a_minus_1 = a - 1.0;
let two_sqrt_a_alpha = 2.0 * a.sqrt() * alpha;

BiquadCoeffs {
    b0: (a * (a_plus_1 - a_minus_1 * cos_w0 + two_sqrt_a_alpha)) / a0,
    // ...
}

It’s the same formula. Factored slightly differently, with more verbose variable names, but structurally identical. The LLM didn’t invent anything here. It transcribed.

Convergent Citation Creates Canonical Knowledge

Here’s where it gets interesting from an LLM-learning perspective. The RBJ cookbook doesn’t appear once in the training data — it appears everywhere, in every language, with every syntax. This creates what I’m calling convergent citation: a pattern so universally adopted that it becomes statistically inevitable in any generated output.

Think about what the LLM has seen:

• The W3C Web Audio specification (which cites RBJ verbatim)
• The biquad-rs Rust crate (which implements RBJ formulas)
• Python scipy discussions (RBJ formulas in numpy)
• CCRMA academic materials (RBJ with derivations)
• Hundreds of Stack Overflow answers (RBJ, badly formatted)
• Thousands of personal blog posts (RBJ, with varying degrees of understanding)

The formulas aren’t just common — they’re canonical. And the LLM, being a statistical creature, produces what is statistically dominant. This isn’t a bug. For well-established algorithms, this is exactly what you want. The cookbook is battle-tested across millions of implementations. Transcribing it faithfully is the correct choice. Innovation would introduce bugs.

The Fingerprints of Multi-Source Synthesis

But the LLM didn’t just transcribe the cookbook. It synthesized from multiple sources, and you can see the fingerprints if you look closely.

From RBJ Cookbook: The exact coefficient formulas. The A = 10^(dBgain/40) calculation (40, not 20, because we’re dealing with amplitude, not power). The hardcoded S = 0.9 shelf slope buried in that alpha calculation as 1.0 / 0.9 - 1.0.

From Rust audio crates: The separation of BiquadCoeffs (static coefficients) from BiquadState (per-sample state). The coeffs_dirty flag for lazy recomputation. The #[derive(Clone, Copy)] idiom.

From tutorials: The Direct Form 1 implementation with explicit x1, x2, y1, y2 state variables. The verbose naming (a_plus_1 rather than ap1).

From Rust best practices: The impl Default pattern. The StereoSample abstraction. The separation of concerns that makes the code testable.

What a direct C-to-Rust port might look like (and, frankly, where my brain went for my own first draft):

typedef struct { float b[3], a[3]; } Coeffs;
typedef struct { float x[2], y[2]; } State;

What the LLM produced:

struct BiquadCoeffs { b0: f32, b1: f32, b2: f32, a1: f32, a2: f32 }
struct BiquadState { x1_l: f32, x2_l: f32, y1_l: f32, y2_l: f32, ... }

The flattened struct with named fields (not arrays) is idiomatic Rust, I think, not a direct port from any single source. The LLM synthesized a “greatest hits” compilation: formulas from the cookbook, architecture from professional crates, idioms from Rust best practices, naming from tutorial culture. I’m already taking this technology for granted, but when I just look at one specific examples like this it’s hard for me to not be impressed. I certainly would struggle to do as well, as my shit implementation clearly demonstrates.

When Naive is Fine (and the LLM Doesn’t Know the Difference)

Here’s the thing about naive implementations: sometimes they’re fine. How much does it really matter if you’re computing sin() and cos() 44,100 times per second instead of caching the coefficients? For a guitar pedal where you maybe tweak the EQ once a song? Probably doesn’t matter at all.

But the LLM doesn’t know that. It’s seen enough “optimized” implementations that it knows the pattern: separate your coefficients from your state, add a dirty flag, recompute only when parameters change. It’s not thinking about your use case. It’s reproducing what people generally do. And that’s usually fine! But it’s worth knowing the difference between “best practice” and “necessary for my context.”

The current implementation sits at what I’d call Level 1 on an optimization spectrum:

Level 0 (Naive): Recompute everything per sample. 44,100 trig calls per second. Probably fine for a hobby project. raises hand

Level 1 (My eq.rs): Cached coefficients with dirty flag. Clean, readable, maintainable. Good for most plugin scenarios.

Level 2 (DF2T): Direct Form 2 Transposed. Uses 2 state variables instead of 4. Better for static filters but introduces artifacts on parameter changes. Tutorials teach DF1T but mention DF2T.

Level 3 (SIMD): Process 4-8 channels simultaneously with AVX. Overkill for a mono-in/stereo-out guitar pedal. SIMD logic notoriously hard for humans to write bug free.

Level 4+ (Advanced): IIRNet neural filter design, nonlinear biquads with waveshaping, fixed-point with noise shaping for embedded / no FP hardware.

Level 5 (Custom): Tailored to specific use cases, such as guitar pedals that mimic classic analog circuits. Requires deep understanding of the hardware and software environment.

Someone who’s an expert could certainly list 10 more levels, I’d wager. I came up with these after a 4hr research extravaganza last night. As someone without much direct knowledge in this particular domain, but 30 years of generalalized experience in “why is this running so slow?” was enough for me to intuit that SIMD approaches would of course by applicable. I’ve used paid plugins by companies that emulate circuit designs so I know a custom algorithm that mimics old (incredibly limited!) hardware, analog or digital, is a thing. DFT2 is talked about in tutorials that implement DFT1 (but is left as an exercise for the reader), and there’s bespoke, clever implementations often designed to run on low end hardware done by smart folks who get a thrill out of it. Like Airwindow’s SmoothEQ3. Which, as an aside, is beautiful both in its cleverness and simplicity, but also in how “natural” it sounds. Where natural simply means it’s what my ears are used to hearing and therefore expect. That it both sounds better, and is significantly faster, is really something.

So there’s a bunch of possible approaches the LLM could have suggested. But when I asked it to build me a better, optimized version it went for a very specific approach (Level 1) and when I questioned it about futher optimizations it literally said:

"this is a textbook example of a biquad filter implementation, it is well optimized for performance and accuracy."

No fixed point optimizations for you! So.. the LLM wants to do it this way, which is… correct? It’d be hard for me to argue that it’s not the “smart default” that works for most cases. But it didn’t explain why, or help me understand when I might want to go higher or lower on that spectrum.

Where This Breaks Down

Convergent citation is great when there’s a canonical answer. For biquad EQs, there is. But what about things that aren’t statistically dominant in the training data?

SIMD optimizations? Sure, there’s some example code out there. But it’s specialized, inconsistent, poorly documented, and varies wildly between platforms. The LLM is much more likely to produce something subtly wrong because there are fewer examples and they’re more diverse.

Same for fixed-point implementations with noise shaping (embedded DSP without FPU). Same for cache-aware optimizations. Same for anything that requires understanding your specific hardware or use case. My project is very clearly aimed at guitar effects in particular, but the LLM was essentially unwilling to move past “textbook RBJ”.

The cookbook wins because everybody uses it. The edge cases lose because almost nobody documents them.

Can we all just appreciate for a moment the impact of that 1998 RBJ usenet post that by now has been battle-tested across more implementations than any of us can count.

It’s discussed to death that an LLM is fundamentally limited by what’s already been written. Obvious, I know, but worth restating and this little exploration certainly reinforced this fact for me. It’s excellent at convergent synthesis — combining canonical patterns from multiple sources into idiomatic target code. It’s going to be much weaker at innovation, non-obvious trade-offs, and anything that requires understanding your specific context.

I got a solid, professional-looking implementation that I can now understand and maintain. The LLM gave me a better starting point than my naive attempt, and the forensic exercise of understanding where it came from taught me more than I expected. So I’m pretty happy.

Whether that’s enough depends on what you’re building. For most of us, most of the time, I suspect it is.

More to come. I want to see if I can work with it to bang out more “interesting” EQ designs. I suspect it will hinder more than help, but I’m constantly surprised by how much it can do. Regardless, I want to try baning out my own SmoothEQ implementation because that airwindows code is so cool it makes me want to get better at these DSP algos.

Sources:

• RBJ Audio EQ Cookbook (W3C)
• EarLevel Engineering - Biquads
• biquad-rs
• fundsp
• Julius Smith - Introduction to Digital Filters
• Wikipedia - Digital biquad filter

I read a piece by Joan Westenberg a couple weeks ago — Thin Desires are Eating Your Life — that resonated with me. In particular, this quote lodged in my brain and I couldnt get it out:

“Build something that will never scale, never be monetized, never attract users.”

With that in mind, I built GlicolVerb this week. It’s a VST3/CLAP plugin that lets you write Glicol code in a text editor, click “Update”, and hear your guitar (or voice, keyboard, whatever) processed through whatever DSP chain you just described. Live-coding for guitar pedals, basically. The whole thing was a learning exercise: first time writing Rust for audio, first time building a VST plugin, first time poking around the Rust audio ecosystem to see what’s actually out there.

I went in expecting the hard part to be the audio processing. Real-time constraints! Buffer management! Sample rates! DSP math! Surely getting audio to flow through a plugin without crackling, dropping, or exploding would be the thing that ate all my time.

Turns out I was completely wrong about where the pain would be.

NIH-plug is excellent. Like, genuinely impressive. Here’s the entire Glicol engine wrapper - the thing that does the actual audio processing:

pub struct GlicolWrapper {
    engine: Engine<128>,  // 128-sample blocks
    left_buffer: [f32; 128],
    right_buffer: [f32; 128],
}

impl GlicolWrapper {
    pub fn new(sample_rate: f32) -> Self {
        let mut engine = Engine::<128>::new();
        engine.set_sr(sample_rate as usize);
        engine.update_with_code("out: ~input >> plate 0.5");
        Self { engine, left_buffer: [0.0; 128], right_buffer: [0.0; 128] }
    }

    pub fn update_code(&mut self, code: &str) -> Result<(), String> {
        self.engine.update_with_code(code);
        Ok(())
    }
}

That’s it. Fifty lines for the whole file. Glicol’s update_with_code() hot-swaps your DSP graph without audio glitches. NIH-plug handles parameter smoothing, buffer management, DAW integration. Even writing a 3-band parametric EQ from scratch using biquad filters was less painful than expected.

So where did the time go? Looking back at the commit history, about a third of commits (9 out of 28) are UI-related. And not just small tweaks. Here’s the editor.rs changelog:

c801c13: src/editor.rs | 764 ++++++---   (509 insertions, 255 deletions)
         "Add dark hardware theme and two-column layout"

1fac077: src/editor.rs | 649 ++++++---   (369 insertions, 293 deletions)
         "Redesign UI with compact Effects Lab and fix state persistence"

dfb43b7: src/editor.rs | 324 +++++---   (281 insertions, 55 deletions)
         "Improve UI layout and add new effect recipes"

That’s over 1,700 lines of changes across just three commits. The UI file is 970 lines. The main plugin logic is 350. The entire DSP equalizer is 359 lines. The “simple” text editor became the central challenge. I made small tweaks myself to figure out what wasn’t working, and then had Claude Code rewrite entire sets of UI definition at once like when switching all the slider controls at once from one egui type to another. Huge time saver!

The culprit: getting text input and panel layout to work reliably inside a plugin window. The stack is egui (immediate-mode GUI) running on top of baseview (cross-platform windowing for plugin UIs). This combo is popular in the Rust audio world and mostly works. Except when it doesn’t. baseview has a known issue with keyboard handling in plugin hosts - the host intercepts key events in ways that mess with text input. Some DAWs work fine, others eat your keystrokes or send them twice. I ended up adding preset buttons as a workaround because you can’t always reliably type code. I spent an embarrising amount of time debugging before spotting the upstream issue..

Then there was a macOS crash. baseview had a bug that would crash the plugin on certain setups. There’s a fix in a PR that wasn’t merged yet, so I vendored a patched version. Had to figure out how to do that with Rust modules. Claude Code helped me with that. Had to fix submodule pointers when CI broke. Several commits just to keep the UI from crashing.

The irony isn’t lost on me. I wanted to learn about audio processing, and I did. But the lesson I didn’t expect was: the Rust audio ecosystem is surprisingly mature for the hard stuff, and surprisingly rough for the “easy” stuff. NIH-plug makes real-time audio accessible. Glicol makes DSP fun. But putting a text box on screen that works reliably in every DAW? That’s still an adventure. I suppose I shouldn’t be surprised, but I was. :)

Anyway, v0.1.2 is out. VST3 and CLAP builds for macOS, Windows, and Linux. It works. I think? You can write out: ~input >> lpf 1000.0 1.0 >> plate 0.5 and hear your guitar through a low-pass filter into a plate reverb. The text input is janky in some hosts but the presets get you most of the way there. It’s still hobby project class software, but it works and makes me smile, which I wasn’t sure I should expect when I started!

Final thoughts. The journey was the point. Building is fun, and I’m having a blast using LLM tech to get from 0—>1 on a project and then deal with some of the tedious chores so I can spend my time reading about the Robert Bristow-Johnson cookbook formulas for EQ filters. Now I’m curious what else is hiding in the Rust audio world. I’m also now curious to try building something similar in JUCE, which I gather is by far the most popular choice for audio plugin development. C++. Good times!

Have been trying out the Helix editor before teaching the kid about modal editors. It’s almost impossible for me to break my vim key binding muscle memory.. but I think for him, it might be a more intuitive “first contact” to modal editors. Anyhow, couldn’t find a cheatsheet to print out for him, but Nano Banana made one that is worth sharing.

Enjoy!

While the entire video is a little.. much.. I really like this quote from Jony Ive in his Emerson Collective conversation earlier this year:

There’s not a lot of humor in the products that are being designed and made, particularly in this area. I really sense very clearly there is a huge desire for us not to take ourselves quite so seriously, even though these are serious times.

Absolutely nothing new here, move along, this is well known, but I didn’t know it and it was semi-interesting to look into the details of how one small part of one of these Agentic Coding Computers (tm) work. So I wrote a few notes as I explored.

In particular, I was investigating how Anthropic’s WebSearch tool works when the tool calling magic decides to go out and query the web for info before proceeding. There are lots of details on the official Claude Docs site but the summary is that you end up with a search_result object.

{
  "type": "search_result",
  "source": "https://example.com/article",  // Required: Source URL or identifier
  "title": "Article Title",                  // Required: Title of the result
  "content": [                               // Required: Array of text blocks
    {
      "type": "text",
      "text": "The actual content of the search result..."
    }
  ],
  "citations": {                             // Optional: Citation configuration
    "enabled": true                          // Enable/disable citations for this result
  }
}

Ah cool, I can see what I’m burning up tokens on in the text field. Nice.

Hold on! I’m actually getting a web_search_tool_result back, not a search_result, and these objects in Claude Code contain almost the same stuff but not quite:

• title - page title
• url - the source URL
• encrypted_content - encrypted page content (not meant for you to read)
• page_age - when the page was last updated

Example:

 {
    "type": "web_search_tool_result",
    "tool_use_id": "srvtoolu_01WYG3ziw53XMcoyKL4XcZmE",
    "content": [
      {
        "type": "web_search_result",
        "url": "https://en.wikipedia.org/wiki/Claude_Shannon",
        "title": "Claude Shannon - Wikipedia",
        "encrypted_content": "EqgfCioIARgBIiQ3YTAwMjY1Mi1mZjM5LTQ1NGUtODgxNC1kNjNjNTk1ZWI3Y...",
        "page_age": "April 30, 2025"
      },
      {
        "type": "web_search_result",
        "url": "https://example.com/another-page",
        "title": "Another Result",
        "encrypted_content": "...",
        "page_age": "May 1, 2025"
      }
    ]
  }

It’s always an encrypted_content field. Never a text field. Which made me wonder what I’m supposed to do with it?

Answer: I don’t do anything with it. I (or this case Claude Code on my behalf) simply pass it back to Claude in subsequent turns of a multi-turn conversation. Claude uses this internally to reference the original search content, generate citations, and mostly to maintain context about what was found.

Ok, I get it. So where is the public key stored to validate it? Is there a key to decrypt it hiding somewhere? I couldn’t find either. Because it’s not in the client, dummy! Of course..

The encryption is entirely server-side:

• Anthropic’s servers fetch web content
• Anthropic encrypts it before sending to you
• You pass the opaque blob back in subsequent requests
• Anthropic decrypts it on their end

You never decrypt anything. There’s no public key exposed to you, no client-side crypto, nothing to validate. The encrypted_content field is a black box by design.

The Security Model

Upon reflection this makes perfect sense (see Why? below). But it’s useful to write out the consequences of what we’re dealing with:

• You’re trusting Anthropic’s infrastructure entirely
• The “encryption” is essentially a signed/encrypted token that only Anthropic can read
• You can’t verify the content wasn’t tampered with
• You can’t verify what’s inside (or compare it to the cited source)
• You can’t verify the crypto is sound
• You just pass blobs around and trust Anthropic

Of course the entire bloody LLM takes this shape as well, and you’re trusting that with far less insight into its inner workings. But for some reason not even being able to see the content of a web search struck me harder.

Alternative Methods

If you need to audit/verify what content is being used in your AI pipeline, you’d need to:

1. Fetch the URLs yourself - You can scrape/fetch those URLs independently to see what content likely came from them. But you can’t compare it to what the model injested.
2. Ask Claude to summarize what it found - In your prompt ask Claude to explicitly quote or describe the search results it’s using.
3. Use your own RAG instead - If you need full control over context, skip web_search and its tool variant and implement your own search + retrieval pipeline. Good times!

Obviously this is all doable if you’re building your own agentic coding magic machine to compete with Claude Code, but as simple end users of CC it’s just how it works we either don’t use the tool or live with it. I haven’t checked any other products but I assume they all work the same way.

Why Encrypted

As anyone who’s used this stuff would already know, the encryption used here is a business/legal decision, not a technical one. The reason it works like this, I would assume, is:

• Licensing/Copyright - Anthropic uses Brave Search as the provider. The encryption prevents you from using Claude’s API as a free web scraping service to extract content from websites.
• Content provider agreements - Publishers likely only allow their content to be used for AI context, not redistributed in raw form.

So yes, you’re paying for tokens you can’t inspect but I can’t see how they can work around this without opening up a world of scraping abuse (as if that’s not already a rampant problem..).

My lesson learned? Learning new things is fun! Be curious about how things work! I now know just a little bit more about how these new agentic coding tools works, and there’s a ton more info in the WebSearch documentation about things like user flows that were helpful to broaden my knowledge. I feel like this quick sidequest might not have been a total waste of time. Heh.

Welcome to the new VMUNIX Blues

It’s been about a year since I revived the old blog, and while Ghost has been just fine and I like supporting them, I decided I really don’t need a CMS I just need a simple static site. I tried a few different tools and frameworks by generating whole sites with Claude Code and settled on SvelteKit in the end. I almost just went for handcrafted HTML and maybe a future version will do that but for now it’s nice to not have to deal with CSS directly and instead let Svelte do the heavy lifting.

The site does need the browser to download about 20KB of JS regardless of it’s going to be used or not, mostly for faster page navigaton and responsive views, but it should gracefully fall back to full page loads of the pre-rendered files if you don’t have JS enabled.

Posts are written in Markdown with full support for code blocks and syntax highlighting.

Code Examples

Here’s a simple shell script:

#!/bin/bash
# Check system uptime
uptime -p

# Display disk usage
df -h | grep -v tmpfs

And here’s some C code:

#include <stdio.h>

int main(void) {
    printf("Hello from VMUNIX!
");
    return 0;
}

Configuration Files

The blog also handles configuration blocks nicely. Here’s a sample nginx configuration:

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Features

So in the end after much trial and error the blog is being built with:

• SvelteKit - Fast, modern framework
• MDsveX - Markdown processing
• Shiki - Beautiful syntax highlighting
• Static generation - Deploy anywhere

The entire site is pre-rendered at build time, making it extremely fast to load with zero runtime JavaScript required for content display.

Writing Posts

To create a new post, I simply add a .md file to the src/posts directory with frontmatter containing:

• title - The post title
• date - Publication date (YYYY-MM-DD)
• excerpt - Optional short description
• slug - optional slug URL

That’s it!

Essential UNIX Configuration Tips

This was a test post I made with Claude as I was debugging the Svelte shit. Decided screw it, I’ll keep it. LOL

Shell Aliases

Add these to your .bashrc or .zshrc:

# Better defaults
alias ll='ls -lah'
alias grep='grep --color=auto'
alias df='df -h'

# Quick navigation
alias ..='cd ..'
alias ...='cd ../..'
alias ....='cd ../../..'

SSH Configuration

Create ~/.ssh/config to simplify SSH connections:

Host myserver
    HostName 192.168.1.100
    User admin
    Port 22
    IdentityFile ~/.ssh/id_rsa
    ServerAliveInterval 60

Host *.internal
    ProxyJump bastion.example.com
    User deploy

Now you can simply run ssh myserver instead of typing the full connection string.

tmux Configuration

A minimal ~/.tmux.conf that improves the default experience:

# Use Ctrl-A as prefix (more ergonomic than Ctrl-B)
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Start windows and panes at 1, not 0
set -g base-index 1
setw -g pane-base-index 1

# Enable mouse support
set -g mouse on

# Increase scrollback buffer size
set -g history-limit 10000

# Vi mode for copy mode
setw -g mode-keys vi

Git Configuration

Some useful Git aliases in ~/.gitconfig:

[alias]
    st = status
    co = checkout
    br = branch
    ci = commit
    unstage = reset HEAD --
    last = log -1 HEAD
    visual = log --graph --oneline --all --decorate

[core]
    editor = vim
    autocrlf = input

[pull]
    rebase = false

Wrapping Up

The beauty of UNIX is that you can customize everything to match your workflow. Start small, add configurations as you discover what slows you down, and before long you’ll have a finely-tuned environment.

I upgraded to MacOS 26 this week, and first thing I’ve wanted to try is the new native container support. I’ve been content with OrbStack but a lot of the time it’s overkill when I just want to test something on the MacBook. Docker and Podman even more so. From an initial hour playing around, it’s quick and easy and works fine if you don’t need docker compose in your testing workflow.

❯ brew install --cask container

❯ container system start
Verifying apiserver is running...
No default kernel configured.
Install the recommended default kernel from [https://github.com/kata-containers/kata-containers/releases/download/3.17.0/kata-static-3.17.0-arm64.tar.xz]? [Y/n]:
Installing kernel...

~ took 32s

❯ container run --rm docker.io/library/alpine:latest sh -c 'echo hello world'
hello world

~ took 10s

That’s it for the install and getting the service running.

All these tools use the standardized OCI image spec, which means I can just grab one from Docker Hub or another registry, and run it. This example runs a command and then the --rm deletes the image when it’s done.

❯ container run --detach --name web docker.io/library/nginx:alpine
web

~ took 3s

❯ container ls -a
ID   IMAGE                           OS     ARCH   STATE    ADDR          CPUS  MEMORY
web  docker.io/library/nginx:alpine  linux  arm64  running  192.168.64.3  4     1024 MB

❯ container exec web ps
PID   USER     TIME  COMMAND
1 root      0:00 nginx: master process nginx -g daemon off;
25 nginx     0:00 nginx: worker process
26 nginx     0:00 nginx: worker process
27 nginx     0:00 nginx: worker process
28 nginx     0:00 nginx: worker process
29 root      0:00 ps

I like that you get virtual IPs, and there’s even a DNS system which simplifies my type of testing where I routinely want to build and test a few hosts that need to talk to each other.

And when I’m done?

❯ container system status
apiserver is running
application data root: /Users/mmayo/Library/Application Support/com.apple.container/
application install root: /usr/local/
container-apiserver version: container-apiserver version 0.5.0 (build: release, commit: 48230f3)
container-apiserver commit: 48230f380499efecd663fdc6749a2cbaf2f8ed76

~
❯ container system stop

❯ container system status
apiserver is not running and not registered with launchd

The whole thing is just gone. YASSSS.

There’s lots of great examples and documentation on the container GitHub page.

It’s not a polished end product, but for me I like the simplicity, the firewalled networking and DNS, effective containment, and ease of firing the whole thing up or down when I need it without bloating my whole Mac. Pretty sweet.

Lots of talk on the socials re: Mozilla and Firefox/Gecko triggered by the recent ToS changes. Thought I’d write up some thoughts on the bigger picture “what to do about gecko” stuff. Additions, corrections, giant gaping holes that need to be addressed.. all welcome feedback. :)

The goal and awesomeness of having an implementation of the web is to be able to nudge the whole damned web towards or away from a behaviour you care about. Make a little dent in the world, as it were. Firefox and Gecko have been able to do that, repeatedly, in some big ways and in many many many small ways, affecting the experience of every single user of the web, not just Firefox users. That’s the allure, and incredible impact, and the reason why you’d even bother with the incredibly hard, expensive, mostly thankless job of making Gecko, SpiderMonkey, and Firefox and the vast array of supporting infrastructure needed to do it. Direct mission impact. It’s important to note that Firefox has done this over multiple decades while never having “winning” marketshare. Even in its glory days it was a ~20% player. That was enough, even into the more recent single digit marketshare era, to sometimes shift the implementations of the world’s largest web platforms. Pretty rad.

With that uplifting note, I have so many thoughts on Mozilla and Firefox going forward that it’s hard to know where to even begin. I do think the only productive thing to spend any of my own mental energy on is to ignore past/current/future decisions from the org (can’t change them, and no insight into their context!) and focus only on “what do we do between now and when Firefox is over?”. Because it sure feels like the end is inevitable, it’s perhaps not too far off, and that’s gonna be a weird dangerous moment for the web. I’ve thought about this going back 10+ years when I started to worry about Mozilla’s long term financial ability to maintain a full stack implementation of the web against the backdrop of slipping market share. Turns out Google kept paying anyways and the budget pressure never came. But for different reasons both Mozilla and Google appear far more focused on what will gain them relevance and influence in the AI wars to come, and far less on the browser wars of the past. Fair! We’re probably gonna need Mozilla.ai to be a force of nature! But I still don’t have a satisfying answer to what happens if Mozilla can no longer make Firefox/Gecko for whatever reason. Seems bad? Question one, I think, is do we actually care if it’s gone? If so, what do we really care about in particular? Different folks will have different “most important things”, but there’s a lot of good browsers out there so here’s what’s rattling around in my head.

Some context to get out of the way first. There’s a couple open source engines we all know deployed at massive scale fighting the good fight of ensuring the web’s implementation is “open”. But, like Gecko, are so expensive to build and maintain that the fact that the code is open is nearly irrelevant. There’s a couple more under development (servo, ladybird) that are exciting and I’m cheering for, but it’s a very long road. Regardless, the primary reason Gecko was compelling as a platform choice in the last decade wasn’t the code, IMO, it was the nature and intent of its owner. A theoretical antidote of sorts that felt good to have exist and go to battle with anyone and everyone if necessary. Mozilla Corporation, as it slowly learns to be a real company, not a movement, is a less and less obvious counter bet to the culture and behaviours of the market winners. Which feels like a betrayal of sorts to us old farts who grew up with both the early web itself, and Mozilla’s rescue of it from the clutches of evil. Back then both had a tangible rebel alliance “fuck you I’ll do what I want to” vibe. They don’t now. The reality is it’s just an inevitable progression of an org and a web so well funded to pursue an ancient and incredibly broad mission for so long. Mozilla behaviour and interests sort of mirrors the web broadly, I guess I’d conclude. Not good, not bad, just natural evolution and shifting of priorities. Still… SHIT. The web is under attack! Where are its defenders?! The emotional part of this isn’t losing Gecko, it’s that the web’s rebel alliance disbanded and drifted away long ago. There was no top down conspiracy. It stopped being the most important fight for too many folks, I think. Tough pill to swallow.

The market dynamics around the tech itself is also worth talking about. People have been saying for years that Gecko is “a dead engine walking” and they’ve sort of been right. They’ve been saying that for a decade at least, of course, so at a minimum it’s a remarkably resilient dead engine. The thing to note, IMO, is that Gecko’s fate is exclusively tied to Firefox’s. I would argue Apple’s WebKit isn’t quite as extreme, but is similar - very little deployment scale outside Apple products. You could make the argument that without Google Blink/Chromium/v8 are totally dead, and I think that’s largely true, but unlike Gecko or WebKit there are a LOT of downstream consumers of that stack with products deployed to many tens if not hundreds of millions of users. Several big browsers, yes, but also things like Electron, Node.js, a long list of notable projects, products, and companies that are dependent on Google’s implementation. Folks with a lot to lose. For this reason, I’ve long wondered if the web’s implementations would ultimately follow the path of the OS wars of the 90s. In the end all the Unixes died off, to be replaced by a single implementation: Linux. And a gaggle of Linux distros competing on forks of every magnitude imaginable! It’s messy, still expensive, and sort of resembles cold war mutually assured destruction dynamics at times.. but on the whole seemed to work better than the alternative. Of note, the BSDs didn’t die, and appear healthy, but they had a deeply distributed contributor base from day one and ultimately are very niche in terms of developer mindshare and deployment vs. Linux today. Still, I love my FreeBSD. Is Gecko on track to be a dead Unix, or is it a BSD? If we consider the parallels to the Unix wars, it’s entirely supported by a single vendor, and the conclusion gets pretty clear. We want Gecko to be a BSD, but I fear it’s soon to be a dead Unix..

So there’s both challenge and opportunity if we think of things this way, in my view. We desperately need organizations that deeply and primarily care about browsers and the web, who are going to do more than just skin Chromium (Linux). We need rebel alliances, and we need them to take on forks “of significance” because they are trying to influence how the web itself works for everyone, just like Mozilla did. Natural forces (fork cost) suggest these efforts are incentivized to merge over time and the web could continue to evolve and reflect multiple points of view on top of a single dominant code base this way. Microsoft Edge is the closet example of this already working, with the caveat that they continue to be heavy on bad taste and light on rebel alliance. Heh. But there are going to be those types of contributors, and they’re extremely valuable. Just like they were/are in Linux. There just can’t ONLY be those types for this to feel like it’s working and we didn’t lose the web entirely. Of import to Mozilla, this sort of outcome, if successful, doesn’t need a fully independent implementation of the web in any one of these organizations. Probably good news in terms of long term budget friendliness, but tbh I doubt the development costs to Mozilla would be wildly different than today regardless. The costs there are largely defined by ambition, not technology. Personally, though, I think I’d be ok to see an empowered Mozilla browser team operating with a clear mission throwing its weight around inside the Chromium code base. Cool improvements for users could much more quickly adopted and shipped by other Chromium browsers, in aggregate perhaps providing the proof/pressure to drive change in Chrome/Edge. Might get interesting!

Two asterisks worth calling out. First, we need to acknowledge that the distribution power of the established parties make the whole idea that smaller shops/browsers can still impact the web’s APIs incredibly difficult to realize. Fork costs are high. Distribution costs are insanely higher. It probably requires regulatory interventions beyond anything discussed today for any of this to end well. I don’t have a reason to believe otherwise, whether there’s one or ten browser engines. There’s zero incentive for Google to take a patch from Mozilla or Microsoft or an IC that advances the web for users but hurts their bottom line. You need momentum and heft in market to change that kind of behaviour by driving their user bases to demand it from them. Right now, and for quite some time I’d wager, Google alone decides what is de facto on the web by what they ship in Chrome, regardless of what plays out in open source code repos. Second, someone has to fund next generation engines, in my opinion. They’re long shots, but they’re invaluable in so many ways to show us what’s possible when we don’t have the weight of every single website ever made on our shoulders. I have no idea how to fund them except all the players should just shake hands and put 1% of their fuzzily defined browser budgets into a small pool that hands out grants to crazy people.

So, impossibly difficult challenges on all fronts! Odds of success near zero! Will most certainly never play out like this! Really, perfect conditions for a Mozilla and their war chest to do the impossible yet again. They just have to want it to happen so badly they’re willing for it to all go wrong. Regardless, for those of us with the passion for building the web in some sort of way, we can’t wait for Mozilla to do anything. We’ve got to roll up our sleeves and get to work.

More to come.

It’s been a while since I’ve picked up a new laptop. I opted for an M3 Max with 36GB of RAM and a 2TB SSD which feels like a bit of a future proof sweet spot once you’re already crossed the rubicon into “omg that’s a lot of money for a laptop” territory..

Homebrew

Over the years I’ve increasingly leaned on Homebrew to make my life easier, to the point where it’s one of the tools I miss the most on my Linux desktop which is a crazy thing to say but I just did?! I’m going a step beyond this time and using it to install/manage everything I can including most of the non-opensource Mac .apps I use as casks.

# Assume Homebrew already install from link above

# utlities
brew install --cask shottr
brew install --cask rectangle
brew install --cask tailscale
brew install --cask appcleaner
brew install --cask font-hack-nerd-font
brew install --cask font-monaspace
brew install --cask itsycal

# 3rd party apps
brew install --cask slack
brew install --cask whatsapp
brew install --cask google-chrome

# dev stuff
brew install --cask visual-studio-code
#brew install --cask docker
brew install --cask utm
brew install --cask restfox

# shell tools
brew install git
brew install btop
brew install node
brew install go
brew install gcc

# AI junk
brew install ollama
brew install pytorch
brew install pyenv

# shell upgrades
brew install wezterm
brew install zsh
brew install starship
brew install neovim
brew install tree-sitter

for me.. a giant copy-n-paste and I’m almost up and running just with brew!

Shell Rustification

I briefly flirted with the notion of changing my custom zsh setup and “throwing in the towel” by moving to oh-my-zsh or zim but I’ve also thought about switching back to bash as that’s what on Linux servers. I tried out oh-my-bash but in the end I’ve retreated back to an up-to-date zsh from homebrew and starship.rs. Out of the box I can live with it, and it is cross-shell which is kinda rad. Best of both worlds? Maybe. Time will tell.

Terminal Rustification

I’m running zsh and all my command-line tools in Wez Furlong’s WezTerm these days. It’s fast, reliable (for me so far at least), and once you have a nerd font installed, it “just works” with all the modern fancy fonts and glyphs and shit and did I mention it’s crazy fast? Nearly bone stock config:

-- Pull in the wezterm API
local wezterm = require 'wezterm'

-- This table will hold the configuration.
local config = {}

-- In newer versions of wezterm, use the config_builder which will
-- help provide clearer error messages
if wezterm.config_builder then
  config = wezterm.config_builder()
end

-- This is where you actually apply your config choices

-- For example, changing the color scheme:
config.color_scheme = 'AdventureTime'
config.font_size = 14.0

-- and finally, return the configuration to wezterm
return config

Editor

Fancy terminal, fancy shell, fancy fonts.. you can see where this is going. NeoVim. I have clearly lost my mind and parked my Vim configuration of 20 years and ended the Visual Studio Code experiment, and am trying something new. It’s vim, but with all the knobs turned up to 11. I’m either in love, or.. about to have mental breakdown?

Virtual Machines

I try to not have to run VMs locally because it ends up just being slow and terrible on the Mac.. but sometimes it’s the only way.. You’ll see in the Homebrew script above I commented out both docker and colima. I really hate Docker. colima makes running the occasional VM less awful than the full blown Docker Experience (tm), but lately I admit I’ve been using OrbStack and it’s nice GUI there’s just far less cursing and frustration involve. Has been reliable, too.

Conclusion

My new zen laptop approach is quite simple:

1. Manage as much as I can in Homebrew.
2. Embrace good tools with sensible default configs that don’t need hours of tweaking.
3. Know that when docker and its irk ruin the party a complete re-glass of the computer is just a few easy steps away!

TL;DR: I’ve gone from skeptic to fan of Mastodon and the fediverse. To that end, I’ve been part of a small team that’s releasing a new iOS app today:Mammoth, a beautiful Mastodon app for the rest of us. It’s free, it’s high quality, we’re doing some novel things to make the whole experience more friendly and fun for new users, and it’s also a deeply customizable app we think anyone will love. I hope you like it. 🙂

We’ve already had a lot of amazing supporters who believe in the potential of the Fediverse and have been helping us start on our journey. A special mention goes to Mozilla who not only contributed financially but also with expertise and guidance. 🙏🙏

The story so far.

It was back in October, on a rainy weekend, and my daughter and I ended up watching Kris Nova’s Twitch stream as she and her band of merry ops peeps were hacking on the backend infrastructure for a Mastodon site called hachyderm.io. Curious name, we thought! More importantly, we were inspired by watching cool people working on something they loved, building something that mattered to them. A node on new kind of decentralized, community-at-the-core, network-of-social-networks. We created accounts and started exploring.

I’d last looked at Mastodon in 2017 as part of a project at Mozilla to investigate feasibility of new p2p messaging platforms. Frankly, I hastily concluded it could never work: incredibly tricky usability challenges are the hallmark of federated consumer products, a lesson I’d learned trying to bring Persona to market for Mozilla years earlier with Ben Adida, Mike Hanson, and many other talented folks. Yet the more I signed up on different servers, followed more folks, followed more hashtags, I was drawn in as I saw a whole community of people who wanted a place to call their own and just didn’t fucking care federation was never going to work. They needed this thing to exist, so they were building it anyway.

I’ve seen this kind of dynamic first hand a few times now, as I approach 30 years of working with and on open source software. The first time for me was living through the rhetoric about how there was no way Linux on cheap PCs could ever replace the entrenched operating systems and expensive servers from Sun, HP, Digital, SCO. They owned the market! But we needed cheap servers and free operating systems to build the internet, so we worked on Linux and BSD regardless. 2nd time it was: “obviously nothing can beat Internet Explorer. Microsoft won.” Brendan and Ben and whole slew of people didn’t care — they built Firefox anyways because the web needed it. 3rd time it was a belief that there was no way anything could replace PHP as the de facto web development stack! Ryan Dahl didn’t care, and soon neither did a whole team of developers who wound up building Node.JS. Eric Allman (sendmail), myself, Kirk McKusick (BSD). Late 90s? Kirk loved a good margarita. :) Sometimes, it just needs to be built. And that’s where we are today with “social networks”, I think. Reasons why decentralization won’t work far outweigh the reasons it might work, but I think the Fediverse gets it right by putting the power where it belongs: with passionate communities and developers building stuff because it’s cool, because it makes their community stronger, more connected.

We’re at a point where there’s now enough people who believe decentralization **is** what’s next for the Internet and are willing to put their money where their mouth is, so to speak. The inertia of the current systems will indeed be overcome. **My bet is that “the Fediverse” is our best shot at how to do a decentralized internet, here and now**.

Today, along with the whole team, I’m excited to introduce the first release of Mammoth, a beautiful Mastodon app for the rest of us. If you’ve already gone down the Mastodon rabbit hole, we think Mammoth is the only mobile app you’ll need — it’s fast, fun, and fully-featured and you can customize it to be just right for you. If you’re new to Mastodon, we take the headaches out of getting started with Mastodon: **we’reone offirst appsto offer simple, in-app account creation and a quick way to find your first set of hashtags and conversations to follow**.

Mastodon is already wildly successful, and quickly becoming the place where many of the best conversations, especially around technology, start.

We want to preserve what makes Mastodon special. The team is all in on the Fediverse, open source, and supporting the tens of thousands of instances and micro-communities. But we think we can help make Mastodon easier to approach for the next 100 million users so they too can enjoy the thrill of finding their place. By combining great client engineering with a backend team that operates our own instance & can build our own backend services (as well as send patches upstream to the core dev team), we think we can help craft a better end-to-end experience.

A big part of how we want to work is by being as completely open and considerate as we possibly can. We’ll be open sourcing our code, of course, but more importantly we want to be part of the conversation around what behaviours are good to reinforce, what the performance implications of a neat feature might be on the network as a whole, what approaches might lead to good or bad outcomes across the system. Let’s get this right.

Hack on,

-Mark (https://hachyderm.io/@mmayo)

* 2025 note: none of this exists anymore but it’s left here to look back at and point and smirk

• CSV downloads of a document’s signers
• Document Locking (prevent further signing)
• Document Lotteries (pick a winner from list of signers)

Why? Well, you folks keep abusing this simple Ethereum-native document signing tool to run contests for airdrops and pre-sales, so we thought we’d make your lives a bit easier! :) We launched KryptoSign in May this year as tool for Kai, Bart, and I to do the lightest possible “contract signing” using our MetaMask wallets. Write down a simple scope of work with someone, both parties sign with their wallet to signal they agree. When the job is complete, their Ethereum address is right there to copy-n-paste into a wallet to send payment. Quick, easy, delightful. :)

But as often happens, users started showing up and using it for other things. Like guestbooks. And then guestbooks became a way to sign up users for NFT drops as part of contests and pre-sales, and so on. The organizer has everyone sign a KS doc, maybe link their Discord or Twitter, and then picks a winner and sends a NFT/token/etc. to their address in the signature block. Cool.

As these NFT drops started getting really hot the feature you all wanted was pretty obvious: have folks sign a KS document as part of a pre-sales window, and have KS pick the winner automatically. Because the stakes on things like hot NFT pre-sales are high, we decided to implement the random winner using Chainlink’s VRF — verifiable random functions — which means everyone involved in a KryptoSign lottery can independently confirm how the random winner was picked. Transparency is nice!

The UI for doing this is quite simple, as you’d hope and expect from KryptoSign. There’s an action icon on the document now: When you’re ready to pick a winner, it’s pretty easy. Lock the document, and hit the button: Of note, to pick a winner we’re collecting to 0.05 ETH from you to cover the cost of the 2 LINK required to invoke the VRF on mainnet. You don’t need your own LINK and all the gas-incurring swapping that would imply. Phew! The user approves a single transaction with their wallet (including gas to interact with the smart contract) and they’re done.

Our initial users really wanted the on-chain trust of a VRF, and are willing to pay for it so their communities can trust the draw, but for other use cases you have in mind, maybe it’s overkill? Let us know! We’ll continue to build upon KryptoSign as long as people find useful things to do with it.

Finally, big props to our team who worked through some rough patches with calling the Chainlink VRF contract. Blockchain is weird, yo! This release saw engineering contributions from Neo Cho, Ryan Ouyang, and Josh Peters. Thanks!

— Mark

So what happened was that the 6th most rare Meebit was fractionalized into 1M pieces, and 30,000 (3%) of those fragments were graciously donated to MeebitsDAO by Divergence.VC. Kai proposed that a fun way to re-distribute those fractions would be to do a giveaway contest. Earn tickets for a raffle, have a shot at a chunk of a famous Meebit. Cool! There’s 3 different kinds of tickets, but for the 1st lottery Kai wanted to airdrop a raffle ticket in the form of an NFT — aka the “Red Ticket” — to every current Meebit holder so they could have a chance to win. Hype up the MeebitsDAO and have some fun! The first question was “cool idea, but how do we not lose our shirts on gas fees minting 4700 NFTs!?”. There’s a bunch of low-gas alternative chains out there now, which, fortunately, we’d played around with quite a bit when we started doing community “Achievement” NFTs (see some here on OpenSea) for MeebitsDAO. Polygon, for the moment at least, had some really compelling advantages for this kind of “badge” NFT where there’s no/limited monetary value in the token:

• Polygon is 100% ethereum compatible — same solidity smart contracts, same metamask, even the same explorer (the etherscan team built polygonscan). Easy!
• For end users Polygon addresses are the same as their Ethereum addresses. 1:1. Nice!
• OpenSea natively/automatically displays NFTs from a user’s matching polygon address in their collection! This was huge, because we knew 99% of wallets we wanted to drop a ticket on wouldn’t otherwise notice activity on a side-chain.
• Polygon assets can be moved back to Ethereum mainnet by folks if they so desire, which has a nice feeling.

Getting up and running on Polygon is covered elsewhere, and is pretty simple:

• Add a “custom RPC” network to metamask.
• Get some fake test MATIC (the native token on the polygon chain) on the “Mumbai” testnet from a faucet and play around.
• Get some “real” MATIC on mainnet. Fees are super low on Polygon, so you don’t need much for minting, 5 MATIC ($5!) is plenty to mint thousands of NFTs. I swapped Eth for MATIC on 1inch, and then bridged that MATIC to Polygon. There are many other ways of doing it.

For MeebitsDAO, we create our own ERC721 smart contracts and mint from them instead of using a minting service. It gives us more control, and over time we’re building up a repo of code and scripts that gets better and better and is purpose-built to the needs of the MeebitsDAO community. This maybe sounds like a lot of work vs using a site like Cargo, but if you have some Node.js experience tools like Hardhat make deploying contracts and minting from them approachable.

If you’re new to Ethereum and NFTs, the first thing you need to do know is that you 1st deploy your smart contract to the blockchain, at which point it will get an address, and then you call that smart contract on that address to mint NFT tokens. As you mint the tokens you need to supply a URI that contains the metadata for that particular token (almost everything we think of as “the NFT” — the description, image, etc. — actually lives in the metadata file off-chain). We generate a JSON file for each ticket and upload it to IPFS via a Pinata gateway, and then pin the file with the Pinata SDK. (pinning is the mechanism where you entice IPFS nodes to not discard your files.. ah, IPFS..)

Like many projects, we lean on the heavily tested de facto ERC721 contracts published by the OpenZeppelin team:

The contract maybe looks a little daunting but really all it says is:

• Be an ERC721 that has metadata in an external URI, and be burnable by an approved address on an access list.
• The Counters stuff lets the token be capped — i.e. a fixed supply, supplied at contract creation.
• safeMint/burn/tokenURI/supportedInterface are just boilerplate to allow above.
• totalSupply() lets block explorers like etherscan/polygonscan/etc. know what the cap on the token is so they can display it in their UIs.

Once the contract is published, we have a helper script in the hardhat repo that simply reads a CSV files of addresses we want to airdop the ticket to and calls safeMint() on the contract. Here’s the core loop:

Because blockchain calls don’t always finish quickly, or at all, we use a try{} block to wait for the transactions to succeed before moving onto the next ticket, logging success/failure. When we minted the 4689 NFTs it just happened to be on a morning when Polygon was quite busy, so it took a few hours to complete. We had logs of 2 mints that failed, so we just re-ran those to complete the drop.

You can check out the full repo on GitHub, but hopefully this gives you a quick view at the two “bespoke” pieces: the contract and the minting logic.

Our goal is to share as much as we can about what goes on behind the scenes at block::block as we help the MeebitsDAO team launch fun ideas! Let us know if it’s helpful, what’s missing, what’s cool, and what else we could write about that help shine a light on “DAO Ops”. :)

Our original 3-month goal was to investigate what a browser designed in 2016 would look like.

(Of note, this is different than exploring what an implementation of the web’s platform should look like — seeProject QuantumandServofor that.)

In those three months, we experimented with lots of different parts of the browser: from the way you navigate, to the way you save things from the web, to the very way in which the front-end for a web browser is built.

Now that the initial project is over (in fact,was over a few months ago…), it is time to look at if and how we move forward. The Engineering Update for Tofino post by Joe Walker is live, and posts from the product and UX teams will follow, but at the high level this is what we learned:

• User testing our concepts ahead of even completing a prototype was extremely valuable.
• Boy howdy do normal users have hard time with non-conventional browser interfaces!
• A User Agent Service is a good idea. We want one in Firefox, like, yesterday.
• Writing a new browser UI in React is flexible and easier to develop in than XUL. Mixing XUL and HTML in a single product/interface was harder than we thought.
• Electron is great for prototyping, but some work is needed if you want to build a full browser.
• Getting out of our Firefox developer bubble and engaging with new open source teams and projects was great. So much awesome feedback and energy!

So what is next?

The ideas behind the user-agent service and a React UI sound good on paper, but do they work in practice, and are they useful to Mozilla? The User Agent Service is designed to store a broader set of data than Firefox Sync can currently handle, but we’re not sure if can it scale up with large volumes of data or if it’s as flexible as we need.

There could be lessons from our React based UI that we can take into mainline Firefox. To that end Dave Townsend is going to be starting with TabBrowser and seeing if there are things that Firefox can learn and we’re going to continue to evolve what we’ve got to be more workable.

We’re going to continue using an environment that makes it easy to prototype fast. We’re not wedded to Electron (far from it) but the fast prototyping aspects of that have been really nice.

It’s also becoming clear that the name Tofino doesn’t really work with what we’re doing now; What we’re working on now is less of a product or user experience exploration, and more of a set of technologies that need testing out, so we’re renaming the group to the Browser Futures Group.

We’re working on a roadmap.

Tofino is dead — Long live the Browser Futures Group.

A brief aside: We briefly called this team the Browser Research Group, and asked for help picking a new name. The internet provided! Background: Naming things is always hard.. so a brief clarification is required because I agonized over using the word Research. The timescale of our ‘research’ is short (months rather than years) and what we’re doing is closely aligned to the goals of the Firefox product organization — i.e. building and shipping a popular browser. The team does not do the kinds of research Mozilla Research in our Emerging Technologies group does, things looking years ahead likeRustandServoandWebAssembly. Calling the team the “Browser Innovation Group” felt even more awkward. Got a better name suggestion? Comment below!

** update 08/04: I should have been clearer that Project Tofino is wholly focused on UX explorations and not the technology platform. We are working with the Platform team on technology platform futures too, and we’re excited about the Gecko and Servo-based futures being discussed! Also, don’t forget to check out the companion post from Philipp: Designing a Browser that isn’t a Browser. Finally, go straight to the GitHub repo for actual project details. Thx!

Last time I posted, I talked about Content Blockers. We ended up making one, and the world didn’t end. Yay! Blogging helped me sort it out in my own head, and that helped identify a path forward at work. So I’m going to do some more blogging, because I’m kicking off a new project which triggered a bunch of soul searching about products, innovator’s dilemma in particular, and what taking risk feels like. Maybe talking about it will help me sort some of this out. So, here we go.

Let’s jump right in and say yes, the rumors are true, we’re working on browser prototypes that look and feel almost nothing like the current Firefox. The premise for these experiments couldn’t be simpler: what we need a browser to do for us —both on PCs and mobile devices — has changed a lot since Firefox 1.0, and we’re long overdue for some fresh approaches. It’s worth noting that we have a ton of work underway on our flagship product, Firefox, that’s all about evolving the browser experience. Not to mention the huge bet we’re making this year that we can get the biggest changes to Gecko we’ve ever attempted (e10s) to land so that Firefox is on a healthy, competitive footing for years to come. But it’s not enough, when someone has a totally different idea they want to explore.

We’ll blog on the Project Tofino Medium channel about the project itself, but what this and subsequent posts are mostly about is thoughts on what the business of doing “innovation” at an organization that has a lot to lose feels like. It feels hard. Up to this point in my 20 year career (20 years? right?!), I’ve never experienced anything quite so “textbook innovator’s dilemma” as my last year at Mozilla. Let me explain. What’s probably not surprising is that the team that builds our browser has a lot of great insights and ideas about how people actually use browsers and the kinds of problems people have that aren’t currently solved by anybody’s browser product. Also likely not surprising is that said team would be stoked to build an entirely different kind of browser focused on solving those problems. Focus. Freedom. Yes! What’s not intuitive to anybody that hasn’t experienced the backside of a very successful product run is that creating something new and different is incredibly difficult. Every little decision can bring crushing stop energy. At an academic level, this is fascinating. Everyone’s read about this in books. When you live it, it’s very personal. The reason new things at old shops is difficult, mostly, I think, isn’t because people are bad, or stupid, or actively sabotage new projects or any nonsense like that. It’s largely because doing anything that might conceivably impact the current product creates unavoidable tension. Nobody likes tension, so you replace it with that self-created stop energy. Innovator’s dilemma is a real thing.

For example, the prototype we’re feeling good about right now is built with Electron and React, not Gecko and XUL (our go-to technologies for building browsers). For a small team starting out pursuing a new product concept it’s a great choice — Electron is a wonderful tool for us to do prototyping with — but a simple decision like picking the right tool for the job becomes an epic FUD generator when it could be perceived as threatening to the existing product. Immediately, you worry. Does it signal we don’t believe in Gecko? What will the platform team think? Will they believe us that the project has nothing to do with technology selection, that’s what browser.html is for? What if web developers think we’re abandoning Firefox, and Gecko? We’ll lose on web compat, and nothing will work in Firefox! Consumers will abandon Firefox in droves! We’ll lose our influence at the W3C! OMG the web is dead! I’m not making fun of that. I’ve had all of those thoughts. And spent countless hours thinking about how to deal with the others that will inevitably have them too. Before you know it everybody involved is spending countless hours worrying about about outcomes that we aren’t in control of anyway. Not having an awesome Firefox will kill Firefox. End of story.

There’s a great deal we don’t know about creativity and innovation. But the research does suggest some patterns are more common than others. You can expect tension. No amount of “messaging” can work your way out of that. The tension will be there, you have to accept it, or you never move. There will be risk. Again, accept it or you never move. You should trust in small, cohesive teams. You should support them, and encourage risk taking. That’s often referred to as “creating space”. My personal experience has been that all these things are true, but I’ve also seen that if you make the innovation process “easy” whatever is being built ends up sucking. Especially at the front end of the process. Maybe it’s because ideas are free to create and valueless on their own. I don’t know.

In that spirit, today I’m placing a bet on a small, cohesive team that for the last 6 weeks spent hours I know for a fact they didn’t have, hacking on an idea they simply refused to let die. God knows the last month of stop energy should have killed it. Years of fear of hurting Firefox, by rights, should have never even let the idea germinate. But somehow they held on and fought for it.

We’re setting up the project a little differently too. The team is not open for internal transfer. The team no longer has access to their own calendars. They’re being unsubscribed from all email lists. They’re not going to attend even a single Mozilla meeting. We’re kicking off in person, everyone in a room, in Tofino on Vancouver Island where the idea for this UX direction originated last summer, and from there we’re going to co-locate the core team in Vancouver for 3 months. That’s how much time I’m giving the team to prove there’s something here that we could turn into a product. If not, we kill it. We’re not going to expect help from anyone at Mozilla and we’re not going to distract the other 95% of our team that’s doing hero work on Firefox.

Origin stories have always fascinated me, and when I look back, a great deal of Firefox’s origin story is not well known. Whether a successful product or feature set comes from this project or not, I can’t say, but I’ll at least document the story of how we’re building new browser experiences inside one of the world’s most experienced browser teams. I’m looking forward to being their story teller!

Disclaimer: I’m SVP of Firefox at Mozilla, I’m clearly biased, but I’m writing here just as me. IT’S ALL ABOUT ME, DAMNIT.

Boy there’s been a lot of attention on content blocking in the last week! Apple entered the debate with the blunt instrument that is Safari / SafariViewController for iOS9, and all of a sudden everyone noticed. As they should. Tim Bray’s Money and Ads on the Web links to a bunch of writing worth reading, and I’d recommend Zeldman’s piece on Ad Blocking and the Future of the Web as a must read. But for all the reasonable, intelligent articles that try to wrestle with the fact that content blocking is a complex issue, it pretty much boils down to this:

Then: Users: Please DoNotTrack me ; AdTech+Publishers: Screw you Now: AdTech+Publishers: Please DoNotAdBlock me ; Users: Screw you

I’ve spent a lot of time in the last year thinking about how to evolve the web’s relationship with ads responsibly, and you see that work shipping in Firefox’s Tracking Protection for Private Browsing mode, which is moving to Firefox Beta tomorrow, and also in how we designed Tiles for the new tab page to respect user choice and privacy. I’m really proud of the work we did, and I’ll talk more about it soon.

Right now, though, in the middle of all this attention around content blocking, what I’m struck by is that the web’s model allows us to have a debate about content blockers at all. The web is still fairly unique in that its fundamental architecture is built around a “user agent” that sits between the publisher and consumer and that agent mediates the experience. Also of note, the web browser is the only agent the user chooses separately from content(thx for reminding me, @osunick). It’s a pretty powerful model that has benefitted all parties involved over the last 15 years, and without that design tradeoff we wouldn’t be having this debate at all. The web’s kinda old, yeah, but it’s still got some fascinating properties that differentiate it from everything else!

The other big thing I’ve been thinking about over the last week is whether I should have had my team build a Safari content blocker. We considered it, debated it, decided against it, and in retrospect, I suspect I held too tightly to an opinion that Apple was being irresponsible in their pursuit to harm Google by implementing content blocking with little to no user interaction capability. “We’d never ship something this crude!”, I argued. An opinion rooted in the fact we’ve had the technical ability in Firefox to do what Safari is effectively doing for over a year, but we decided that we didn’t have good enough answers to “well, what should the system work like, then? how and why do sites get on/off these lists?” and until we did we wouldn’t ship for general browsing. This is where Apple differs from a pure web browser vendor like Mozilla, I suppose; Apple has an answer for publishers to the often shitty experience of web advertising: don’t use the web, use apps with iAds, use Apple News, use Apple Music, use Apple… Apple’s answer isn’t a better web, really, it’s Apple’s iOS ecosystem.

It’s not too late, of course. We know how to build for iOS, have the policies/tech/lists we developed for Tracking Protection in Firefox, have no need to ever charge money (and therefore, arguably, no potential conflict of interest) for a content blocking app or list curation service, can credibly say we could operate in the open with transparency, and of course we have a running theory that users might want Mozilla to have a part in how this plays out on iOS.

Whereas Marco just didn’t feel good about the success of his #1 app, I think for many folks at Mozillait just doesn’t feel good for us NOT to be there for our users, skin in the game, working to make the web better, despite the severe limitations that Apple’s placed on developers implementing content blocking.

A final thought on Apple and the web. John Gruber argues that the outcomes, whatever they may be, should not be framed as “Because of Apple”, but as “because of us”, and that’s true but I think he is underestimating Apple’s influence and role in this somewhat. First with Flash, and now with content blocking, Apple is shaping the web as we know it. It’s almost ironic, then, that while the health of the web isn’t top of Apple’s mind (hurting Google and advancing their own ecosystem clearly is), they have an uncanny ability to create these watershed moments that force the web to adapt and get better.