Roastidio.us Tagged with web

URL parser tester

Sun, 07 Jun 2026 01:51:09 +0000

Go net/url

Go net/http

This is Go's built-in net/url package. The parser is based on RFC 3986, with some compatibility fixes. We compiled it to WebAssembly using Go's built-in compiler support. net/url itself does not support IDNA, but the built-in net/http package does through the golang.org/x/net/idna package. We added a "Go net/http" entry to emulate how net/http handles a URL.

The part mappings are as follows. Go's url.URL object has multiple accessors for the path, query, and fragment components, each with a different level of encoded-ness; we choose the same fields/methods as the URL.String() serialization method.

Property	url.URL field/method
href	String()
protocol	Scheme
username	User.Username()
password	User.Password()
hostname	Hostname()
port	Port()
pathname	Opaque \|\| EscapedPath()
search	RawQuery
hash	EscapedFragment()

Node.js legacy

This is the Node.js's legacy URL parser, written in JavaScript based on RFC 3986. Developers have been encouraged to switch to the modern parser based on the WHATWG URL Standard since version 8 (released in 2017). We copied the parser as well as some required internal Node.js source files and bundled them using esbuild for use here.

Compared to the official Node.js binaries, the version presented here could have some slight differences when handling IDNA. This is since Node.js generally uses ICU4C's IDNA support (which is difficult to compile to WebAssembly), while here we have replaced it with a pure JavaScript implementation tr46.

The part mappings are as follows:

Property	Legacy urlObject property
href	href
protocol	protocol
username	auth.split(:)[0]
password	auth.split(:)[1…].join(:)
hostname	hostname
port	port
pathname	pathname
search	search
hash	hash

Python urlparse

This combines Python's built-in urllib.parse module with Python library Requests' requote_uri() function. Python's urllib uses various RFCs (primarily 1738 and 1808) as the basis for its parser. To run Python in the browser, we use Pyodide, which compiles Python to WebAssembly.

Since the parser does no normalization by default, we use the popular Requests library's requote_uri() for parity with other parsers listed here. The part mappings are as follows:

Property	ParseResult properties
href	geturl()
protocol	scheme
username	username
password	password
hostname	hostname
port	port
pathname	path
search	query
hash	fragment

Note: We ignore the params part, which exists in RFC 1738 but has no equivalent in other parsers and was removed in RFC 3986.

Python requests

This captures how Python library Requests' deals with request URLs. Requests uses urllib3, which is based on RFC 3986, to parse incoming URLs. However, it does some additional normalization on top of urllib3, such as applying the requote_uri() function. IDNA support in both Requests and urllib3 is provided through the idna package. The part mappings are as follows:

Property	urllib3.util.Url properties
href	url
protocol	scheme
username	auth.split(:)[0]
password	auth.split(:)[1…].join(:)
hostname	host
port	port
pathname	path
search	query
hash	fragment

libcurl

This is libcurl's URL API. curl uses RFC 3986 as the basis for its parser, with some features of the WHATWG URL Standard mixed in, as detailed on its URL Syntax documentation page. We created a simple C application "frontend" for the API and compiled it to WebAssembly using Emscripten. While curl does support IDNA using the libidn2 library, the functionality is not exposed through the URL API.

When parsing the URL, we use CURLU_NON_SUPPORT_SCHEME and CURLU_URLENCODE flags. When getting individual parts of the URL, we pass 0 as flags. The part mappings are as follows:

Property	CURLUPart
href	CURLUPART_URL
protocol	CURLUPART_SCHEME
username	CURLUPART_USER
password	CURLUPART_PASSWORD
hostname	CURLUPART_HOST
port	CURLUPART_PORT
pathname	CURLUPART_PATH
search	CURLUPART_QUERY
hash	CURLUPART_FRAGMENT

Note: We ignore CURLUPART_OPTIONS, used for IMAP/POP3/SMTP "login options." We also do not list CURLUPART_ZONEID separately as it is included in CURLUPART_HOST.

spec-url

spec-url absolute

This is the JavaScript spec-url library, a reference implementation of Alwin Blok's URL Specification. Blok's specification is designed to be a rephrasing of the WHATWG URL Standard in more mathematical terms. We used esbuild to generate a bundle for the library.

The actual parsing steps done by this tool is similar to the proposed parse-resolve-and-normalise algorithm in Blok's specification. If no base URL is specified, "web-mode" is used, and the "force resolve" step in the algorithm is not done.

The absolute variant optimizes for use of the input string as an "absolute URL," at the risk of losing some information. Concretely, the absolute variant always forces the parser output. The absolute variant is closer to how the WHATWG URL Standard operates, while the normal variant is closer to how Go's net/url and Node.js' legacy parser operate.

The part mappings are derived from Blok's specification:

Property	Field/function
href	print()
protocol	scheme
username	user
password	pass
hostname	host
port	port
pathname	root + (dirs && (dirs.join(/) + /)) + file
search	query
hash	hash

Rust url

This is Rust's url crate, created by the Servo Project. It should be highly compatible with the WHATWG URL Standard, with complete IDNA support. We compiled it to WebAssembly using wasm-pack and wasm-bindgen.

The part mappings are as follows:

Property	url::Url method
href	as_str()
protocol	scheme()
username	username()
password	password()
hostname	host_str()
port	port()
pathname	path()
search	query()
hash	fragment()

whatwg-url

This is the JavaScript whatwg-url library, designed from scratch to be a reference implementation of the WHATWG URL Standard. We load the latest (nightly) bundle of the JavaScript whatwg-url library, which is also used for its own URL Viewer program. This utility is, to a large extent, inspired by URL Viewer. URL part mapping is trivial, as whatwg-url exposes the same properties as a browser URL object.

your browser

For comparison, we also parse every URL with your own browser's URL class.

Is there a power law of category use?

Fri, 05 Jun 2026 11:12:54 +0000

I have been thinking a lot about categories over the last week or so. It started by Thomas sharing the work he has been doing to build a category index page, whose design I love. I started to realise that I like to put a lot of my blog posts in one of few categories: moments of joy go in one category, slices of life go in another, posts about coffee go in another.

As a result of all of this thinking about categories, I fixed my category index page, which has been broken for a few months. I added a count of how many posts are in each category so I could see how I use categories. I noticed what I had felt from how I use categories on a day-to-day basis was true in the data: there is a heavy concentration of posts in a few categories, and then a long tail of other categories.

I created a chart in Google Sheets to visualise the trend, charting all 63 categories I use at the time of writing this post:

ALT

A chart showing a power law trend in the use of categories on my website. Almost all of my blog posts are categorised in one of the top 10 categories.

Thomas confirmed the trend applies to his website, too, which has me interested in whether others, too, have long tails of categories.

I think there are a few possible reasons for why my category use is in this way.

First, I intentionally like to keep the number of categories I use to a minimum. I feel that expressiveness is an attribute of a category which can vary. A category can list posts that are part of a series, like my IndieWeb Carnival category, or be an umbrella for a whole genre of writing I do, like my Stories category (which include some of my poetic prose). Indeed, I think categories serve both an organisational and an editorial use on a page: they help me find my posts, and also add a label of where I think the post fits into the rest of the website.

Second, I don’t remember a lot of the categories I have created. It’s easier to remember fewer than many things.

Third, my category use is perhaps influenced by the fact that the tool I use to publish blog posts, Ghost, only has a limited history of the categories I have used.

While I try to minimise the number of categories I use, I do create new ones when I feel like having a page that lists posts in the category I want to create would be useful. For example, I recently created a category called Bear Blog Carnival so I can aggregate all my contributions to that event; I have a category called Artemis that groups all my blog posts in that project; I have a category called “New Things” that followed a challenge I did to try and do a new thing every day for a week.

An interesting side effect of having categories is that they remind me of different projects I have done, like my guest writing for a Scottish coffee roaster, and my two separate one-off attempts to try week notes. It was also interesting to see that I have published almost an equal number of posts in the IndieWeb and Life categories. This matches what I think about my writing: I love writing about technology, but I love writing about the world around me too.

If you do any analysis on how you use categories, I’d love to read what you write! You can send me an email with any ideas or thoughts you have.

category index page You can send me an email guest writing for a Scottish coffee roaster separate one-off attempts to try week notes Thomas sharing the work he has been doing to build a category index page

Hiding a list with no items in CSS

Fri, 05 Jun 2026 11:12:54 +0000

The Artemis reading interface consists of a section tag for each day for which there are blog posts to show. Each section contains a h2 denoting the date the posts were published, and a ul that lists each post published on that date.

Here is what the interface looks like:

ALT

The Artemis interface showing three posts, one published on May 26th and two published on May 25th.

There are some niche scenarios where a list may end up with no items but still retain the heading (and, as I later discovered, some practical scenarios too).

This got me thinking: could I write a CSS rule that would hide an entire section if the list in the section had no child li elements? I first looked at the :empty CSS psuedo-class (MDN docs for :empty), but :empty is sensitive to white-space. If a ul had no child elements but a single space between its opening and closing tags, :empty would not apply.

With that said, with the :has selector I can achieve the effect I want!

I ended up with the following rule:

section:not(:has(.list-entries>li)){    display:none;}

This rule says that a section should be hidden if it does not have an element with the class .list-entries (which is a ul) that contains at least one li. NB: If you use a similar rule, you may want to make this only apply in a particular context, i.e. your main tag.

One nice effect of this rule is that, because it is CSS, the rule will be applied as the page changes. For example, Artemis has a feature to hide posts. When you press the hide button, an element appears saying a post is hidden and shows an undo button that hides after a few seconds. This message shows using JavaScript. With the CSS rule, if you hide all posts, when the last undo message goes away, the whole section can disappear without having to use JavaScript to find the parent section and delete it. Indeed, the less JavaScript I have to write, the better.

Here is how the effect looks:

When the last post in the ul in a section is hidden, the whole section, including the heading, disappears. When the page is refreshed, the section will also be hidden because the back-end will have been notified that the user wants to hide the post.

I thought I'd document this in case it is helpful for anyone else!

Artemis MDN docs for :empty

JUnited 2026

Fri, 05 Jun 2026 11:12:54 +0000

In recent weeks, I have been talking with a lot of people about personal websites. In so many of my discussions, I mention that one of the reasons I love coming back to my personal website is the community around the indie web: people all over the world sharing what interests them: slices of life, hopes and dreams, tutorials on how to do something, and more. Websites aren’t islands. Websites are houses in a town.

That brings me to JUnited. I first participated in JUnited, a challenge that invites participants to share links to “blog posts or blogs you think deserve more love,” in 2024. I found out about the challenge via JCProbably. I missed last year – I think I forgot the challenge was going on! – but I was delighted this morning to wake up to a post by Kristof that mentioned the challenge. Inviting people to share links to blog posts they enjoy, JUnited so wonderfully embodies the essence of the indie web community.

With that in mind, I am excited to participate again in the challenge.

For each day in the month of June, I will update this post with a link to a blog post I really enjoyed reading. I invite you to peruse the links and see what interests you. And, if you have a website, I invite you to participate in the challenge, too.

A Love Letter To Creative Spaces by Britt
"there’s a sort of Gresham's Law of developers (vs users): developers are willing to use a forum with a lot of users in it, but users aren’t willing to use a forum with a lot of developer-speak. [...]" by Tantek
To have a moral stance on AI is to be an outcast, and it sucks. by Martyn
A note on note-taking by Bojidar

A note on note-taking A Love Letter To Creative Spaces I first participated in JUnited Kristof that mentioned the challenge To have a moral stance on AI is to be an outcast, and it sucks.JCProbably JUnited Tantek

Distinguishing user and system content

Fri, 05 Jun 2026 11:12:54 +0000

When I was designing the inline message to indicate a link in a user’s Artemis reader has been flagged as malicious, I intentionally designed the system message and state to be distinguished from the user-set author name.

Here is what the final design looked like:

ALT

The Artemis feed showing three entries. The first entry has been flagged as suspicious, and shows a clear, distinguished label indicating this, as well as being indented with a coloured border. This creates contrast between the two posts below that have not been flagged which appear without the indent or suspicious link label.

The message “This link has been flagged as suspicious. Learn why.” appears above the article title. This post that has been flagged as suspicious is visually indented compared to other posts. Both of these indicators are set by the system.

Because Artemis is designed to be text-heavy, I could have instead designed the feature to add a tag next to an author’s name, like this:

Because the link already goes to a wall that indicates to the user the link is malicious, this technically could have sufficed, but it wouldn't be a good implementation. This implementation with the “flagged as malicious” label right next to the author name would set a bad precedent for including system messages immediately next to author names, which are customisable by the user.

When I designed the “via” feature, for example, I put the “(via)” label in italics. Because users cannot add italics to author names, because the “via” feature only indicates a link points to another website, and because users set their own author names, I thought this would be a sufficient distinction. But for something related to security and integrity – a link being flagged as malicious – a clear visual distinction that cannot be confused with anything else was absolutely essential.

More broadly, having a system message in the same place as a user-controlled field is confusing at best, and potentially malicious at worst.

I thought I’d write this down since it isn’t necessarily obvious, but something that I think about when I am designing features. There are also other real-world examples of this pattern. Signal, for example, adds a little blue checkmark next to the “Note to Self” chat that is specifically for messaging yourself. This indicates that the user is an official chat.

ALT

The Signal chat for the official "Note to Self" feature shows a blue checkmark next to the name "Note to Self".

The official Signal chat also has the same checkmark.

In both the “Note to Self” and official Signal chat, the author name at the top of the chat has an “Official chat” label that is set by the system. This creates a clear distinction between chats between users and chats between system users (the Note to Self feature, the official Signal account):

ALT

The Signal "Note to Self" chat window with the words "Official chat" under the words "Note to Self" both in the persistent author indicator in the top left and in the big box that appears at the top of the chat logs.

“via” feature,inline message to indicate a link in a user’s Artemis reader has been flagged as malicious

L’inventeur du Web s’inquiète de l’essor de l’IA et appelle à protéger l’esprit ouvert des débuts d’Internet

Fri, 05 Jun 2026 08:35:55 +0000

N’oublions pas que le personnage a du poids. Tim Berners-Lee n’est pas un commentateur de plateau. Il a créé le Web. En 1989, alors physicien au CERN près de Genève, il imaginait un système de partage d’informations entre scientifiques. Deux ans plus tard, il écrivait le premier navigateur internet et posait les fondations de ce […]

IPv6 zones in URLs are a mistake - Xe Iaso

Fri, 05 Jun 2026 00:44:43 +0000

IPv6 zones in URLs are a mistake

Published on 2026-06-05, 696 words, 3 minutes to read

Run away while you still can, it's not too late for you to avoid the curse of knowledge.

IPv6 is weird. One of the more strange parts of the standard is that every interface's link local addresses are in fe80::whatever. If you have a machine with two network interfaces, both of them will be in fe80::, so if you have a packet destined to fe80::4, how do you disambiguate it?

The answer is you use IPv6 scopes/zones. The exact format of what goes into a zone is OS dependent, but on Linux it's the interface name and on Windows it's the interface ID. This lets the kernel's routing table know how to handle an address range conflict.

On my tower, this would be represented like this:

fe80::4%eth0

Where eth0 is the name of my tower's ethernet device.

When you create a host:port bindhost, you normally separate the hostname and port with a colon. IPv6 uses colons to separate hex groups. In order to disambiguate what's the host and what's the port, you typically format the IPv6 address in square brackets, so fe80::4 on port 80 would look like this:

[fe80::4]:80

And with the right scope it looks like this:

[fe80::4%eth0]:80

Now let's get URL encoding into the mix. From high orbit, you can imagine a URL's format as being something like this:

<scheme>:[//][<username>[:<password>]@][<hostname>][:<port>][/<path>][?<query>][#<fragment>]

An IPv6 zone would then be part of the hostname, just like with that fe80::4 port 80 example from earlier. So you'd think the URL would be something like this:

http://[fe80::4%eth0]:80

But if you try to parse this as a URL in Go, you get an error:

Yields:

panic: parse "http://[fe80::4%eth0]:80": invalid URL escape "%et"

This happens because URLs can't represent all Unicode values, so any values that don't fit into the grammar of a URL become percent-encoded. This is why sometimes you'll see a %20 in URLs in the wild; that's encoding the ascii space key, which is invalid in URLs.

In order to work around this, you need to percent-encode the percent sign in the IPv6 zone:

Yields:

fe80::4%eth0

In theory, there is guidance for how to properly handle IPv6 zones in user interfaces in RFC 9844~~, but there's no such guidance for URLs~~. Go also does not seem to follow this RFC in net/url.

Cadey

EDIT: It seems that this behaviour is compliant with RFC 6874 and that this is in fact how it is meant to be done.

IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"

      ZoneID = 1*( unreserved / pct-encoded )

      IPv6addrz = IPv6address "%25" ZoneID

Our industry confounds me.

So in the meantime in order for Anubis to point to IPv6 zoned addresses, you need to encode the % with percent encoding. This is horrible, but it seems that this is an edge case that applies to other frameworks, programming languages, and libraries:

https://trac.nginx.org/nginx/ticket/623
https://github.com/psf/requests/issues/6808
https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-link-local-uri-bcp-03 -- Browsers don't currently support IPv6 zones because it breaks the concept of an "origin" which is used for many subtle things, this RFC draft attempts to define an zone origin in IPv6 so that browsers have a leg to stand on

Maybe some day in the future there will be a better option here. In the meantime my policy of not forking the Go standard library means that this somewhat terrible UX for an edge case is acceptable. I hate it, but what can you do?

TL;DR: computers were a mistake.

Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.

Tags:

Crashing cars and improving hover detection | Motion Magazine

Fri, 05 Jun 2026 00:44:42 +0000

I'm going to show you an effect that you'll recognise immediately, perhaps without ever having paid it much attention.

Take any collection of elements that react to hover: a list of menu items, swatches in a colour picker, squares in a grid. Now quickly swipe your cursor across them:

In real life, your hand moves across your desk, or your finger across the screen, in a continuous, unbroken motion. But this isn't reflected in the example above. Here, lights in the path of motion are switched on seemingly at random. Move slower, and you'll see that every element lights up, and the faster you swipe, the more elements are skipped.

Now run your mouse over this version. Swipe it as fast as you like: every cell you cross lights up, with nothing skipped.

Honestly when I created this second example I couldn't stop playing with it. It is weird how responsive it feels, why doesn't it always work like this? By the end of this post you'll know why, and how to build this improved hover yourself.

Surprisingly, this is the exact same problem that video game engines encounter when deciding whether a car has crashed, or any other type of collision has taken place. As such, a solution to our skipped elements was invented decades ago.

Discrete vs continuous motion

CSS selectors like :hover, Motion events like onHoverStart, and JS events like pointerenter are all afflicted by this skipped element problem.

The reason being, pointer position is sampled discretely, rather than continuously. Streamed as a series of points, via events, to the browser and then by the browser to our code.

To illustrate, lets imagine a row of elements, with a pointer moving slowly across them. The pointer events always come in at the same rate, so with slower motion these events are closer together. Meaning that it's more likely at least one pointer event lands on each element, triggering its hover state:

Faster movement means the gaps between these events increases. Which means any elements lying in these gaps are completely skipped.

If you've ever written a physics engine, this'll feel familiar, because it's a textbook collision detection problem with a specific name: tunnelling.

Physics engines run a loop. Every iteration, they calculate the next position of objects based on their position and velocity. Then, they check which objects hit which. It's similar to pointer events in sense that you're checking discrete snapshots of positions rather than continuous motion (the latter essentially requiring infinite computation).

Picture a car driving towards a thin wall. During Animation Frame A it's just short of the wall, and then as it drives a little further, in Frame B it's overlapping the wall. The engine spots the overlap and registers a hit.

In a game, it will probably do something like move the car back outside the wall and trigger a crashing animation, so they appear to impact.

But now, imagine a car that's moving even faster. It's moving so fast that, in Frame B, it's already out the other side of the wall. In no single frame does the car overlap the wall, so the collision check, which only ever looks once per frame, sees nothing. The car sails straight through.

This is tunnelling, and it's the exact same problem as our pointer sampling. The pointer is the fast object, each hover target a thin wall.

The fix

Games fix tunnelling by, instead of asking "where is the object this frame, and does that overlap anything?", you ask "what path did the object take since last frame, and did that path cross anything?".

Rather than test a point, you test a line.

For pointers, that line is easy to calculate. You can measure the pointer's position this frame, and look back at where it was in the previous frame. Draw a line between the two and you've got the route the cursor took. So instead of checking which element contains the current point, you check which elements the line intersects.

Building it with Motion

To actually implement this, we need to:

Get the pointer's previous and current position.
Measure the elements we wish to check against.
Perform a cheap geometric test.

Reading the pointer

In this post, we're going to be using Motion APIs and concepts, but the basic procedure is of course replicable in plain JavaScript.

Motion+ ships a usePointerPosition hook that gives you pointer positions as motion values, in viewport-relative coordinates.

const pointer = usePointerPosition()

The reason I default to usePointerPosition is that it's extremely composable. No matter how many components call it, it only ever registers a single pointer listener and a single pair of motion values. Likewise, motion values are easy to pass straight through our compositional hooks like useTransform, useSpring and useVelocity.

However, for this use case, the nice thing about motion values is they remember their final set value in the previous animation frame. pointer.x.get() returns the current position and pointer.x.getPrevious() is where it was left the frame before. There's our line: previous position to current position.

Measuring the element

We want to test every element's bounding box against the line each frame. Element.getBoundingClientRect() is the browser's built-in API for measuring the bounding box (and like usePointerPosition, this method also returns coordinates relative to the viewport).

We can schedule this measurement using Motion's frame loop's read step, which is like requestAnimationFrame but removes layout and style thrashing by grouping all the reads before any writes within each animation frame.

frame.read(measureElement, true)

Testing the geometry

For each element, we want to answer one question: does the pointer's path cross it? We have a cheap solution in the form of the slab method.

The idea behind the slab method is to stop thinking of the rectangle as a shape and start thinking of it as the overlap between two infinite bands, called slabs.

Slab X fills the gap between the left and right edges, and Slab Y fills the gap between the top and bottom. Self-evidently, a point is inside the rectangle only when it's inside both slabs at once.

To figure this out, we can measure whether the line is inside each slab independently. So for the x-axis alone we ask: at what fraction (running from 0 at the start of the line and 1 at the end) of the way does the path enter the vertical slab, and at what fraction does it leave?

For instance, in the following diagram enterX would be something like 0.33 and exitX something like 0.66.

We can tell if a line is fully outside a slab, and therefore outside the box, if enterX (or Y) is more than 1, which means the line is fully to the left of the slab. Likewise, if exitX is less than 0 then the line is fully to the right of the slab.

If the line does intersect Slab X then we can do exactly the same for Slab Y.

Finally, we know the line isn't inside the element unless it is inside both slabs at the same time.

We know it doesn't enter the bounding box until we've crossed both enterX and enterY. Or, enter = max(enterX, enterY).

Likewise, the path will exit the bounding box when it leaves either exitX or exitY. Or, exit = min(exitX, exitY).

Finally, with final enter and exit values in hand, we can quickly calculate whether the line was within both slabs at the same time by checking whether enter < exit.

A path can pass through both slabs and still miss the element, as long as it isn't inside both at the same time. Here the line crosses Slab X below the element, leaves it, and only then crosses Slab Y to its right. The two crossings never overlap, so the highest enter is larger than the smallest exit.

See it run

Here's the same grid again, this time wired up with our collision detection instead of onPointerEnter. Every cell the pointer crosses lights up, so even a fast flick leaves an unbroken trail with nothing missed.

Next steps

There are (probably?) good reasons browsers hit-test a single point rather than running this algorithm on every element, on every site. Clearly this feels better than the native implementation but it's certainly more expensive. Although there are plenty of avenues for optimisation (caching measurements, algorithmic improvements), what we have is good enough for most things.

However, we're not about "good enough", we're looking for something more. So for isolated showcase UIs this is a technique you can keep in mind.

You can take it further, too. In this post we've concentrated specifically on producing a "is hover" boolean check. But, the slab method gives us some valuable extra information, including where along the path the hit happened.

There are some fun additional effects you could produce with this information that I'll leave to the imagination. But, one idea is triggering an animation with a negative delay based on this progress value. This ensures elements colliding with the cursor don't all animate as a batch but with a subtle offset that reflects when they were "really" hovered.

Our new Bobble Hover example does exactly this, with each tile rippling in the order the cursor hit them, each launched with the speed it was struck at - all built on the same slab method we've just explored.

Would you like to see this kind of collision detection API in Motion? You know where to let us know.

Designing a better podcast editor — Adam Solove

Thu, 04 Jun 2026 14:56:23 +0000

For the past few years, my partner has recorded and edited a niche podcast while I’ve helped a bit with selecting music and EQ setting. Our workflow was painful: one shared iCloud file, emails of notes coded to timestamps, carefully checking that our changes didn’t conflict.

Editing audio was like traveling back in time twenty years: no track changes, no comments, and no multiplayer editing.

The friction wasn’t just in the file-oriented workflow. The normal interaction model of Digital Audio Workstations (or DAWs) is not particularly well-suited for the task of editing spoken word audio.

So I decided to build the podcast editor we wanted: Ducking. It has a UI purpose-built for laying out spoken word audio, plus multiplayer editing, collaboration tools, and history management. In this post, I’ll talk about the improvements it makes to editing tools. Future posts will discuss the engineering challenges of multiplayer audio editing and the pleasure of building software for just a few users with design sketching techniques and LLM assistance.

Fig. 1.#

Screenshot of Ducking in use, with the comments and effects panels open.

How does Ducking major editing podcasts easier? It focuses on providing better tools for the two most-common recurring tasks:

Audio layout: specifying how bits of audio should stick together as things around them change.
Navigation: finding the right bit of audio. This happens at a lot of levels of precision, from “roughly where does act 2 start?” down to “exactly which millisecond is the beginning of that background noise?”

Ducking itself was built specifically for our podcast workflow, serves its purpose doing that, and won’t be public anytime soon. But I hope that some of these ideas will spread into other tools and be more broadly useful.

Throughout this post, I’ll show simplified animations of the features in action to avoid distracting with other parts of the editing UI.

Audio layout

Like laying out a newspaper or a webpage, one of the main challenges with audio editing is to start by roughly trying out how different parts fit together, then to carefully specify more precisely, without messing up the existing choices.

Ducking provides an audio layout concept model that is much faster to work with, by borrowing ideas from other DAWs, text editors, and even further afield.

From absolute to magnetic time

In a traditional DAW, every clip has an absolute start time. When one clip is moved or edited for length, everything after drifts out of alignment.

Fig. 2.#

Absolute layout — trimming any clip leaves a silent gap or overlaps the next clip.

Absolute layout is the right model for writing songs, where material in one measure should stay there. But it’s the wrong model for editing spoken word material, where the default is to reflow later material as earlier bits change.

The right layout model is a magnetic timeline, where clips are ordered, not positioned. Each clip’s place in time is computed from the lengths of the items before it. So when one clip is added, removed, or edited, everything after just re-flows automatically.

Gap clips allow adding explicitly-timed silence when that is needed.

Fig. 3.#

Magnetic layout — clips and gaps reflow when you trim.

This is the model used by many video editing tools as well as audio tools that focus on spoken word, like Hindenburg. So the idea itself isn’t new. But it provides the first step and suggests that further playing with the idea of an automated layout model might be useful.

From splits to skip regions

The vast majority of podcast editing is repeatedly removing tiny bits of unwanted material like filler words, long pauses, or a flubbed sentence. In most audio editors, that means splitting each recording clip into lots of tiny parts and adjusting their alignment. After doing that dozens of times, the timeline view becomes a huge set of disconnected clips that are hard to scan or reorganize.

Fig. 4.#

Without skip regions, every filler removal splits a clip in two. One more cut and you're up to ten detached fragments — none of them carrying any indication that they belong to the same original take.

Ducking uses “skip regions” as a better solution. The editor can leave a clip as a single unit while editing away part of it as not to be used. This keeps a single mostly-intact recording as a unit, so it’s easier to understand and rearrange, while still indicating where material has been removed.

Fig. 5.#

Skip regions — fold a portion of a clip without splitting it in two.

The skip region acts like code folding in a text editor. It leaves a visible indication and can be unfolded to interact with the skipped audio or change the region’s start and end.

Pin-based alignment

So far the editor has only been working with a single track of audio. The problem gets harder as we add more parallel tracks.

Perhaps the trickiest case is transition music. The editor will usually want it to play gently underneath the end of one section, swell to be the main focus, and then duck back beneath the beginning of the next section.

Most audio tools allow laying out the second track either in absolute time or by connecting the start of a clip in one track to a specific place in another, which allows the second track to float along with the rest of the magnetic timeline.

Fig. 6.#

Single connector — music clip tied to the end of a specific speech clip.

With the connector model, the editor can construct any particular transition, but they have to struggle a bit to translate between the creative vision they have and the set of tools that enables them to reach it.

Analyzing the creative decisions that they are trying to make, editors really care about:

How the fade-in portion of the music corresponds to the outgoing speaking part: making sure it becomes noticable right as the section is reaching a dramatic or summarizing closing beat.
How the swell of the music lets the last section gently fade out and how the music corresponds to the emotional or intellectual changes between the two sections.
How the fade-out portion of the music ducks back down to fit beneath the next section’s spoken content, lingers for a bit, and then fades out smoothly.

So I built a set of layout tools that exactly correspond to those set of creative decisions. Using the pin-based layout system, the editor gets to pick which part of the music should play at the same time as which part of the preceding and following spoken word clips. Then they can independently control the volume or other effects on each track so that they layer properly.

Fig. 7.#

Pins and constraints — two-tie constraint layout with fade points and automation.

Combining all of these elements — magnetic timeline, skip regions, and constraints between tracks — removes the layout busywork from audio editing and lets the editor focus directly on the emotional experience they’re trying to achieve.

Navigating audio

Before any edit action can happen, first the editor has to understand and choose what to edit. Navigating audio happens in a few ways:

Actually listening to the audio, possibly scrubbing or jumping around the timeline. The playhead provides a visible correspondence between what’s playing now and where it is in the timeline. A common task is to just listen and try to pause at the right time to leave the playhead at a certain spot.
Looking at the timeline and waveforms can sometimes help, both at very zoomed-out levels, where seeing the patterns of clips and tracks gives the high-level structure of the project, and at a very zoomed-in level, where the waveform shows exactly where a piece of speech or sound begins.
Reviewing the transcript is helpful at intermediate levels, when looking for a specific bit of speech.

Ducking’s UI makes it easy to navigate in any of these manners by establishing correspondences between each of them. Rotating the timeline editing tools 90º lets the overview, waveform, and transcript view all move in the same alignment and scroll together.

Below is a low-fidelity interactive mockup that shows the core ideas.

Fig. 8.#

Scrolling through a project. The timeline, transcript, and overview thumb stay in lockstep — the golden playhead marks the current position in all three.

With this high-level UI layout:

The scrollbar shows a simplified and zoomed-out overview view of the entire project, so the scroll tab’s size and position shows us exactly where in the project we are and how far zoomed in we are. In this project, the purple music clips clearly establish the section breaks, allowing us to quickly see we’re looking at the transition from the intro into the first main section.
The timeline view shows a traditional waveform with editing tools for each track and clip. But its rotated ninety degrees so that it scrolls vertically. This allows us to do detailed DAW edit operations to the waveform, while benefiting from the natural alignment of the timeline to the transcript.
The transcript view is neither an afterthought (like in most DAWs where it just hangs out and has no correspondence to the rest of the editing), nor is it the primary editing surface (like in Descript). It scrolls and zooms together with the timeline so that you can always clearly see the text of the audio being edited. Clicking on words moves the playhead there

The UI layout establishes a clear correspondence between the overview, the waveforms, the transcript, and any currently-playing audio:

The playhead appears as a golden line in all three views to orient what we’re currently listening to.
The current contents of the timeline view are indicated in the overview by its scroll tab and in the transcript view by the matching gray outline section.
Scroll and zoom actions obviously take effect in all three places at once.

This same correspondence also ratchets up the power of other tools. When searching for text or looking at the history of edits to the project, those annotations can be overlayed onto all three views.

As an example, because the overview always shows the entire project, it’s a great way to see the overall structure and then orient where search results or tracked changes have happend in the document.

Fig. 9.#

The same scrollbar, three jobs. The overview's whole-project context lets other tools — search, history compare — speak in the same affordance.

Conclusion and what’s next

Taken together, the more powerful audio layout model and the new UI navigation make it much faster for us to produce podcast episodes from raw recordings. The software is definitely tailored just for our needs, but these ideas may be more broadly applicable, which is why I am sharing them here.

Where this post focused on the UI, I plan to publish two future posts on other parts of the project:

The experience of building a local-first, multiplayer experience on top of Automerge, especially focusing on ideas around collaboration and change management with non-textual data.
The texture of working with AI coding assistants outside of a business environment, using the leverage not to intensify work but to enjoy more sketching and hammock time to decide what’s next. Plus the pleasure of building narrowcast software that only has to please two people.

About me

I’m Adam Solove, a product engineer who loves to build great products in complicated domains. I’m just wrapping up a six month sabbatical that focused on my local community and some building deeply personal tech experiments like the one above.

I’m starting to look for projects or my next role. If you’re building something interesting, please get in touch.

Face à la contestation interne, Meta revoit son logiciel de surveillance des salariés

Thu, 04 Jun 2026 04:58:32 +0000

Critiqué par ses employés, Meta modifie son dispositif de collecte de données sur les ordinateurs professionnels destiné à entraîner ses modèles d’intelligence artificielle. Le groupe autorise désormais des pauses dans la collecte et ouvre la voie à des demandes d’exemption.

Sarbacane devient Positive User : la plateforme d’emailing change de nom et d’ambition