FIFO mkfifo

Egress envelopes of ingress envelope 1

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7004-a2c5-95ad75b75afd@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(cat fonts/$file)

Show the body Show the header

Egress envelopes of ingress envelope 2

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-700b-87c7-2e5ca33a0e04@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(cat fonts/OFL.txt)

Show the body Show the header

Egress envelopes of ingress envelope 3

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7012-8512-b717d452d8d6@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

Notes from building mkfifo.com, one subject in each post: what I planned, what I found, what I changed, and what I fixed. When a choice was wrong, the post tells how I found it. The code is private, so this is the public record of the project. Follow it with the [Atom feed](/blog/feed.xml). The blog is a FIFO: each post is an envelope of the FIFO `mkfifo`, and `lsjson` makes this list. $(lsjson -R --files-only -M blog | jq -r '[.[] | select(.MimeType == "text/markdown")] | sort_by(.ModTime) | reverse | .[] | ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"] as $months | (.Metadata.date // .ModTime) as $date | "## [\(.Metadata.subject)](/blog/\(.Path))\n\n\($date[8:10] | tonumber) \($months[($date[5:7] | tonumber) - 1]) \($date[0:4])\(if $date[0:10] == .ModTime[0:10] then "" else " · Updated \(.ModTime[8:10] | tonumber) \($months[(.ModTime[5:7] | tonumber) - 1]) \(.ModTime[0:4])" end) · \(.Metadata.keywords)\n\n\(.Metadata.description)\n"' | markdown)

Show the body Show the header

Egress envelopes of ingress envelope 4

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7019-9201-7a1aad8ffa9f@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(lsjson -R --files-only -M blog | jq '{title: "The blog of mkfifo.com", description: "Notes from building mkfifo.com, one subject in each post.", home_page_url: "https://mkfifo.com/blog", feed_url: "https://mkfifo.com/blog/feed.xml", authors: [{name: "mkfifo.com"}], items: ([.[] | select(.MimeType == "text/markdown")] | sort_by(.ModTime) | reverse | map({id: "https://mkfifo.com/blog/\(.Path)", url: "https://mkfifo.com/blog/\(.Path)", title: .Metadata.subject, summary: .Metadata.description, date_published: (.Metadata.date // .ModTime), date_modified: .ModTime, tags: (.Metadata.keywords // "" | split(", "))}))}' | atom)

Show the body Show the header

Egress envelopes of ingress envelope 5

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7020-93b2-11ae88738992@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(printf '\0\0\1\0\1\0\40\40\0\0\1\0\40\0\337\2\0\0\26\0\0\0')$(resvg -w 32 - -c < favicon.svg)

Show the body Show the header

Egress envelopes of ingress envelope 6

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7029-a006-ee60b83ea71d@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

The first two days of mkfifo.com: the idea of a named pipe for the web, the envelopes that are its rules, the editor of the envelopes, and the loops that a graph of FIFOs can have. ## A named pipe for the web On Unix, `mkfifo` makes a named pipe. I want the same thing on the web: a name that takes HTTP requests and emails in, and sends webhooks, emails and answers out. ### The idea The FIFO `NAME` is at `https://mkfifo.com/NAME`, and its inbox is `NAME@mkfifo.com`. A Request goes in. It comes out as a webhook, an email, an answer to the client, or a Request to a different FIFO. ### Envelopes Each rule is one message in the format of RFC 5322, the same as an email. I did not want a custom format or JSON: people and programs already know how an email looks. - An **ingress envelope** is a test. Each header line and each body line is a pattern, and `(?<name>...)` keeps a part of the Request. - An **egress envelope** replies to it with `In-Reply-To`, and tells what to send and where. `{{name}}` puts a capture there. ### The stack Phoenix and LiveView in Elixir, on BEAM.com: the Erlang VM in WebAssembly, in one Durable Object of Cloudflare Workers. SQLite keeps the envelopes. It is one of the first real apps on BEAM.com, so I expect rough edges (see [Running on BEAM.com](/blog/2026-10-05-running-on-beam-com)). ### A word that was not true The home page said "No code". But you write regular expressions in a FIFO, and for many people that is code. Now it says "Works with curl". ## Loops of FIFOs An egress envelope can send to a different FIFO. So the FIFOs make a graph, and a graph can have a loop. TLC showed me that my first lock was wrong. ### The first design A save of an egress envelope adds an edge to the graph. My plan: lock the FIFO of the save, look for a loop, then save. I wrote the model first (`specs/Loops.tla`), and TLC found the loop `a -> b -> a` in four steps. Two saves looked at the graph at the same time. Each one saw no loop, and each one saved its edge. ### The fix One lock for all the saves of edges. A save that makes a loop gets `422`. The hop limit stays too (8 `Received` lines), for a long chain with no loop. ### Later: more than one edge Mirrors (see [Mirrors](/blog/2026-10-04-holds-mirrors-privacy-and-limits)) add saves with more than one edge. The model got them too. TLC finds a loop when the save of a mirror does not look at the graph, and the code does not skip it. ## Envelopes you can edit Each FIFO has an editor at `GET /NAME`. An ingress envelope looks like brown paper, an egress envelope looks like airmail, and a pipe goes between them. - It works with no JavaScript. Each form sends `POST /NAME` with `_method` and a CSRF token. With JavaScript, LiveView does the same thing with no reload. - I removed daisyUI and wrote a small theme for the envelopes. - The name field of a header line suggests the usual header names. ### On a phone - The stamp of an envelope pushed the `To` line to two lines. Container queries fixed it: the stamp now scales with the face of its envelope. - A long name on the home page made the page wider than the phone. Fixed. ### Notes, three designs in one night A note tells what a FIFO does. Its design changed three times before it stayed. 1. **Markdown with earmark_parser.** It kept `<script>` and `javascript:` links, and it was slow on some input. No. 2. **Blocks of HTML**, as in the editor of Gutenberg: a paragraph or a heading. I wrote my own HTML cleaner, with a TLA+ model of its stack. 3. **lazy_html.** A few hours later, lazy_html (lexbor, the HTML parser of the standard) ran in the Worker as a NIF in WebAssembly. I removed my tokenizer and its model. The cleaner now walks the tree of lazy_html. A note has blocks: a paragraph, or a heading of level 1 to 6 from a drop-down. It keeps only text with `<strong>`, `<em>`, `<mark>`, `<code>`, `<br>`, and `<a href>` to `https:`, `mailto:` or a path of mkfifo.com. ## The rules of an envelope Two rules of the envelopes changed after I used them: what a capture can do in the message that goes out, and what a missing header means. ### A capture cannot change the message A capture comes from whoever sent the Request. It must not change the structure of what goes out. Each place gets its own escapes. - In a header line: no line breaks. - In a URL: percent-encoding. - In a JSON body: the escapes of a JSON string. I missed the HTML body at first. A capture went into an HTML body as it was, so the sender of a Request could add tags, for example an image, to an email. Now a capture in an HTML or XML body gets the escapes of HTML. Later I added Markdown (see [One shape for stream parsers](/blog/2026-10-05-stream-parsers-and-selector-lines)). `{{note | markdown}}` in an HTML body gives the capture as Markdown, and my converter escapes each character, so it cannot add a tag. In an email of `Content-Type: text/markdown`, the Markdown is the text of the envelope, and a capture is only text in it: it cannot add a link or a heading. ### A missing header is an empty value Before, a header line needed the field in the Request. Now a missing field is an empty value, so `Website: ^\$` agrees when the field is empty or missing. That gave a honeypot for free. A form has the field `Website`, and hides it from people. A program that fills each field of a form fills it too, and its Request does not agree. The letter of a page hides such a field: it is out of the page, and it does not take the focus. ### The first spam On 11 October, the contact form got its first spam: one line in Catalan that asked for our prices. The forwarded email could not tell me how it came: through the form, as an email, or as a plain HTTP request. So I changed three things, and none of them changes what a person sees. - **The email tells how the message came.** Each forwarded message now has a line `Sent with:`: the form and its seconds, an email and its DMARC result, or an HTTP request. The ingress envelope captures `X-MkFIFO-DMARC` and the new `X-MkFIFO-Form-Seconds`, and a `jq` command in the egress envelope writes the line from the two captures. No new code, only the builtins. - **A form tells how long it took.** When mkfifo.com draws the form of a page, the form gets the time, with a signature. When the form is sent, the Request has `X-MkFIFO-Form-Seconds`: the seconds since the page loaded. Only a form has this field, as only an email has `X-MkFIFO-DMARC`: mkfifo.com removes it from an HTTP request, an email and a Request from a different FIFO. A program sends a form in a moment, and a person needs more time to write a message, so the contact envelope has `X-MkFIFO-Form-Seconds: ^(|[5-9]|[1-9][0-9]+)\$`. A form sent faster than that gets "Your message was not sent because it came too fast. Wait a few seconds, then send it again." Your own FIFO can use the same line. - **The honeypot looks like any other field.** It was the first field, at `left: -9999px`, with `aria-hidden` and `tabindex="-1"`: well-known signs that a program can look for. Now it is in its place between the other fields, with the same label and attributes, and it is `inert`: a person cannot focus it, a browser does not fill it in, and a screen reader skips it. The class that hides it has a plain name.

Show the body Show the header

Egress envelopes of ingress envelope 7

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7030-8545-d2ce00da5f34@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198 An email comes in as a stream. For two days, mkfifo.com also sent the email of each FIFO; then your own email service took that job. The sign-in of mkfifo.com became a FIFO, with one-time codes and signed cookies. Then each account got a home: a locked FIFO, with FIFOs in it. Before the next features, I checked the homes again, and closed the holes that I found. ## Email in, as a stream An email to `NAME@mkfifo.com` is a Request. I read it as a stream, so a large attachment uses almost no memory. ### The parse - MIME, the encoded words of RFC 2047, and the charsets UTF-8, US-ASCII, ISO-8859-1 and ISO-8859-15. ISO-8859-1 is Windows-1252, as in a browser. - The body of the Request is the first plain text part, else the first HTML part. - A multipart body goes through a streaming parser. Its model, `specs/Multipart.tla`, looks at all the bodies of up to 9 symbols and all their splits into chunks. - Forms use the same parser: each field of a form becomes one line `name: value` of the body. ### A backslash A property test found that a backslash in the name of a field of `multipart/form-data` lost the name. A browser does not escape a backslash there, so the parser must not read it as an escape. Fixed. ### Who sent it Anybody can write any `From`. Cloudflare Email Routing checks SPF, DKIM and DMARC, and the Worker puts the DMARC result in `X-MkFIFO-DMARC`. A pattern on `From` and `X-MkFIFO-DMARC: ^pass\$` together prove the sender. Only the Worker sets that field: mkfifo.com removes it from each other Request. ### No bounce for an empty name Any name can get envelopes, with no sign-up. So a name with no envelopes is not a missing FIFO: it is an empty one. Until now, an email to it went back to the sender, and an HTTP Request got 404. A shop, or the check that Gmail sends before it forwards, can mark an address as bad after one bounce, before you write the first envelope. Now an empty FIFO drops a Request, as a FIFO drops one that no envelope matches: 204, and no bounce. The cost is that an email to a mistyped address disappears quietly. A name that cannot be a FIFO still gets 404. On the way, I found that the editor said "No ingress envelope matches" for an envelope that matched but had nothing to send. It now says "Matched, with no egress envelope to send". ## Asking before sending email A FIFO can send email to an address that somebody typed. Without a check, that is a machine for spam. So mkfifo.com asks the holder of the address first. ### The model found the scanner I wrote `specs/Confirm.tla` before the code. Four rules prevent four faults, and TLC finds each fault when its rule is not there. Then I added a mail scanner to the model. Many mail services open each link of an email to check it. If the link itself confirms, the scanner confirms with no consent. So the link opens a page, and only the button of that page confirms. A link is valid for 7 days, and an address gets at most one link in one hour. ### The stop link Each email has a stop link with one click (RFC 8058). TLC found a fault before I wrote it: after a stop, the save of an old page of the editor started the emails again. Now a confirmed line stays confirmed only when the FIFO has that address confirmed now. ### How email goes out At first the VM sent through the API of Cloudflare Email Service with the secrets of my account. I changed that: each email goes to an email API with a token, as to any third party. The Worker has such an API for Cloudflare Email Service, and SendGrid, Mailgun, Postmark or Resend work too. ### Two days later I removed the confirmation and the stop link. mkfifo.com sends email only for the FIFOs of the site now, and your FIFO sends email with your own email service (see "Your email service sends your email" below). ## Your email service sends your email mkfifo.com does not send email for your FIFO now. Your own email service sends it. I removed the confirmation of an address, the stop link and the reply address. ### Why The confirmation made each email to a new address wait for a click. That stopped spam, but it also stopped good uses: a contact form that replies to the person who wrote, or a sign-in link to the address of a form. Each of these sends to an address that a stranger typed. With the email service of mkfifo.com, I must ask that stranger first. With your email service, that is between you and your service. So I turned it around. An email is an HTTP request to the API of your email service, with your key in a sealed field: ```envelope To: https://api.mail.example/send Authorization: <seal:Bearer KEY> Content-Type: application/json {"to": "{{email}}", "subject": "Thanks", "text": "We got your message."} ``` The variables get the escapes of JSON, so a capture cannot add a field. The editor shows only `<sealed:TOKEN>` in place of the key. ### What went away - The confirmation link, its page, and the limit of one link in one hour. The TLA+ model of these rules (`specs/Confirm.tla`) went too: there is no consent to keep now. - The stop link. Your email service has its own. - The reply address `reply+UUID@mkfifo.com`. With no email from mkfifo.com, there is nothing to reply to. A Request from one FIFO to the next has `Received: by mkfifo.com; DATE` now, and still no name of the FIFO before it. - The two kinds of seal. A seal was an address or a field. Now each seal is a field, and a sealed `To` opens as its destination. ### What stays The FIFOs of the site still send email from `noreply@mkfifo.com`, with the email service of mkfifo.com. The letters of `/contact` come to me in this way. A FIFO of the site can also send to the address of a capture, `To: {{email}}`: the base of a sign-in link later. The templates changed too. Each template that sent an email now sends JSON to an example API, with a note that tells what to change: the URL, the key and the body. ### Later An account that owns a FIFO could keep the data of its email service. Then `To` could be an email address again, and that service sends it. ## One-time codes and cookies I want a sign-in for mkfifo.com, but I want it as a FIFO, not as code beside the FIFOs. A FIFO can already take a form and send a link. It could not make a code, check a code, or remember a person. Now it can do all three. ### A pattern can use a capture A pattern can have a variable now: `{{email}}` is the capture of a different line of the same envelope. The lines with variables go last, after the captures of the other lines. The filter `totp` makes it useful. `{{email | totp}}` is a one-time code of the capture: 8 digits, as the codes of an authenticator app (RFC 6238). In an egress envelope it puts the code in a link. In a pattern it accepts that code: ```envelope Email: ^(?<email>[^@\s]+@[^@\s]+)\$ Code: ^{{email | totp}}\$ ``` The key of a code holds the secret of mkfifo.com, the FIFO and the value. A code is valid for at most 15 minutes, and a Request that agrees uses it. After 5 wrong codes for one address in 15 minutes, its codes stop. ### The code that came back My first version marked each used code. A test sent two links in one step of 7.5 minutes, and both had the same code: that is how TOTP works. So the second link had a code that was used already, and did not work. Now the key also has a generation of the value. A use moves the value to its next generation: the used code, and each older code of that address, stop, and the next link has a new code. Two Requests with one code at the same time could both read the generation before one of them moves it. So the use is one `insert_new` in a table in memory, and a TLA+ model (`specs/Codes.tla`) shows that only one of them agrees. Without `insert_new`, TLC finds two. But the table is in memory, and each deploy starts a new VM. After a start, each generation was 0 again, so a used code agreed one more time, until its 15 minutes ended. A person with an old link, from the history of a browser for example, could sign in with it. Now each start makes a random value, and the key of each code has it: after a start, each code from before it is wrong. A person who asked for a code just before a deploy asks for a new one. A test stops the process of the table, and checks that the used code does not agree again. The code also compares in constant time now. ### Signed cookies An answer of a FIFO of the site can set a cookie now: ```envelope Set-Cookie: auth={{email}}; Path=/; Max-Age=5184000 ``` mkfifo.com signs the name and the value. The browser keeps only the signature. When the browser sends the cookie back, the FIFO gets the plain value in `Cookie`, and a client cannot write a cookie that agrees. This changed the rule of cookies from this morning. A Request lost only the session of mkfifo.com then. Now it keeps only the cookies of its own FIFO, also a Request from a different FIFO: else a FIFO could send a false `Cookie` to a FIFO of the site. ### A letter with an answer LiveView sends a letter over its socket, so the browser never sees the answer of the Request: not its page, not its redirect, and not its cookies. Now the letter of a FIFO with an answer egress goes with a usual form of the browser, also with JavaScript. The page in its sandbox shows, and the cookies arrive. ## Sign in with a FIFO `/auth` is the sign-in of mkfifo.com, and it is a FIFO. Its editor is open to read, like `/contact`: the envelopes there are all of the sign-in. There is no table of persons. ### Three envelopes 1. A letter with an email address and no code. Its egress sends an email with a link and a code, `{{email | totp}}`, and its answer brings you back to the form with your address. 2. A letter with the address and the code: `Code: ^{{email | totp}}\$`. Its answer sets the signed cookie `auth` for 60 days, and goes to the home page. 3. `/logout` takes each `POST`, and its answer removes the cookie. The link in the email is `/auth?form&email=...&code=...`. I made `?form` put the values of the query in the fields of the letter, so the link opens the form already filled. You still push "Submit": many mail services open each link of an email to check it, and a link that signed in by itself would sign in the scanner too. The header of each page shows your address and "Sign out", or "Sign in". A plug reads the cookie on each page, and keeps a copy in the session, because a LiveView cannot read a cookie after it connects. ### A limit for the emails This FIFO sends an email to any address that somebody types. That is the old problem of spam, the reason for the confirmation that I removed this morning, with a smaller door: only a FIFO of the site can do it. So an address of a capture gets at most 3 emails in one hour now, from all the FIFOs. mkfifo.com counts them in memory, with a hash of the address. The letter also has a honeypot field. ### Email to each address Until 9 October, the emails of the site went only to the verified addresses of the Cloudflare account: Cloudflare sends to any address only from a domain that is onboarded in Email Sending, and only on the plan Workers Paid. Now mkfifo.com is onboarded. Cloudflare added the records of `cf-bounce.mkfifo.com` (MX, SPF and DKIM) and a DMARC record with `p=reject`, and it did not change the MX records of the incoming email. The code did not change: `sendmail.js` and the binding were ready. The first link of the sign-in opened the form with the code, and the field Code had the mark "does not agree". The letter took its marks from the envelope with the most lines that agree, and that was the first envelope: it takes a letter with no code. The second envelope agreed, but its line of the code has a variable, which a test before the send cannot use, so it had fewer lines in the test. Now the marks come first from an envelope that agrees. The link also showed too much: the full letter, with each field, its mark, and the result of each envelope. Now the link opens a short dialog with the address and one button, "Sign in". The button sends the same letter in hidden fields, so the server did not change, and a mail scanner that opens the link still does not sign in. "Sign in with a different address" opens the letter. ### Plus addresses In a query, `+` is a space. Thus a link with `ann+tag@example.com` as plain text would fill a different address. The email is Markdown, and Markdown puts each capture in the URL of a link with percent-encoding, so the HTML part has `ann%2Btag%40example.com`. The answer of the first letter goes back to the form with `Location`, which also encodes the capture. A test in Chromium signed in with a plus address, with and without JavaScript. ## Accounts, again The first accounts came before a plan, and went away the same day. They came back with a plan, and with less code: the sign-in above did not change. - When a browser starts a session with a valid cookie `auth`, mkfifo.com keeps the sign-in, and the first one makes the account. An account is an email address and two times: the first and the last sign-in. There is no password, and no table of sessions: the signed cookie is the session. - An account keeps lists of FIFOs. The editor of a FIFO has "Add to a list", and [your account](/account) shows the lists, with "Remove" and "Delete my account". Each form works with no JavaScript. - A list does not make a FIFO yours: the name is still the key. A lock for a subscriber comes later. - The tables were still in the live database, from the first version. The migration came back with the same version, and now makes each table only if it is not there, as the migration of the graph does. A new database gets the same tables. - The [privacy page](/privacy) tells what an account keeps. ## Homes The lists were there for a few hours. mkfifo.com keeps its data as a graph of nodes and edges, so new tables for the accounts and the lists were the wrong choice. Now the account and its home are in the graph too, and links take the place of the lists. - Your home is a FIFO. At the first sign-in, mkfifo.com makes a node for the account, with your address and the times of your sign-ins, and a FIFO whose real name is a new UUID of version 7. [`/~`](/~) opens it. - Each path in your home is a FIFO. There is no mkdir: open `/~/work/my-fifo`, and the FIFO `my-fifo` is there, in the FIFO `~/work`. Save an envelope in it, and it stays. There is no rmdir: mkfifo.com stores envelopes, not FIFOs, so a FIFO of a home with nothing in it goes away one day later. - The FIFOs of your home are locked to you, and they are never public. This is the first lock of mkfifo.com, and it costs nothing, because it locks no name: a real name is a UUID. For each other person, they are not there: the real name, a Request, a `PUT` and a `PROPFIND` all get `404`. - The FIFOs of your home send Requests to each other: `To: ~/inbox`, or `\$(\$body | ~/inbox)`. The save keeps the real name in the graph. A script of `sh` or `eval` in an envelope cannot send to them, because a Request can give the script. - A link is a mirror. Write `Bcc: my-shop` in an envelope of `~/shop`, and the envelope gets the Requests to the public FIFO `my-shop`, as a symbolic link. Only you see the link: the editor of `my-shop` does not show it. - A home holds no FIFO. A hold from a FIFO of a home would lock a name, and a lock of a name is for a subscriber. - In the terminal, `~` is your home: `printf hi > ~/work` sends a Request to your FIFO `~/work`. Only the terminal does this. A Request never expands `~`, because a different site can make your browser send a Request. - The lists did not move: a link is an envelope now, and the old tables went away. ## A check of the homes Homes and guests change who can do what, so I stopped the new features, and read the code again as a person who wants to break it. These are the holes that I found and closed. Each fix has a test. - **A link took the answer.** The answer egress of a link became the answer of the public FIFO: its status, its page, and also a redirect to a different site. A link also used the steps and the messages of the Request of the FIFO. Now a link examines a Request after the envelopes of the FIFO, with its own steps and messages, and gives no answer. The client gets only the results of the envelopes of the FIFO. - **The lock was in the pages, not in the store.** A copy could go into a FIFO of a home, and an editor that was open could save after "Delete my account". Now the store examines the owner in the lock of each save, note and delete. - **A delete that stops.** "Delete my account" could stop in the middle, and leave FIFOs with no owner. Now the account gets a mark first, then each envelope goes, and the next start of mkfifo.com goes on with a delete that stopped. The start also repairs the old `Cc` and `Bcc` edges, and the notes with no envelope. - **Real names in errors.** An error of a loop could show the real name of a FIFO of a different home. Now it shows "a FIFO of a home", and your own FIFOs as `~/PATH`. A name in the form of a UUID with no home gets the same answers as a FIFO of a home, so a real name tells nothing. - **A slow pattern.** `match_limit` of PCRE applies to each start position, so `[a-z]*[0-9]` on one long line took minutes, and the limit did not stop it. Now each search counts the reductions of the BEAM, which need no clock, and a search on a long text runs in a process that stops when the Request has no more steps. In WebAssembly, the worst search stops after about 6 seconds, as the slowest search of the NFA of `grep`. - **One-time codes.** The memory of `totp` has a limit now, `~` keeps no codes, and the uppercase and lowercase letters of an address give no more tries. - **Cookies from a different site.** A page of a different site could sign a person out. Now an answer to a request from a different site sets no cookie. - **The HTTP egress** sends nothing to this computer or to a private network. On Cloudflare, the network blocked them already, but a different host would not. - **Reads in a home.** An envelope of a home cannot read a FIFO whose name a variable gives: a Request through a link must not choose the FIFO. A sealed key comes only from the text of an envelope. - An empty FIFO of a home now goes away one day after its last open, not after it was made. Thus a FIFO that is open in an editor stays.

Show the body Show the header

Egress envelopes of ingress envelope 8

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7037-9d37-611651700b4f@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201 The name of a FIFO is its key. This post tells how a FIFO holds a different FIFO, how two FIFOs share one envelope, what mkfifo.com keeps private, and which limits came before the launch. ## Holding another FIFO A public form at `/hello` should not show its rules to each person who guesses the name. So a FIFO can hold a different, free FIFO, and the held FIFO can have a page. - The ingress envelopes have `To: hello`, but they live in the editor of a secret name, for example `hello-k7f2`. - `/hello` has no editor. `PUT` and `DELETE` get `409`, and `GET /hello` is a Request, or the page below. - The `To` of an ingress envelope does not change after the save. ### Locks, again The model (`specs/Hold.tla`) showed two wrong locks: 1. With the lock of the home only, two FIFOs held one name. 2. With the lock of the held name only, two FIFOs held the names of each other. Their envelopes had no editor at all. So: one lock for all the saves of ingress envelopes. A property test runs the actions of the model against the real code, with processes at the same time. ### A page for a held FIFO A held FIFO can have a page: its public envelopes, and a letter in the shape of each one, which each person can send. - An ingress envelope is public when it has a note. The others stay private, because a pattern can hold a secret. - mkfifo.com draws all of the page, so it cannot look like a different site. Each page has a banner that the holder cannot remove. - The page does not show the holder, the destinations, the sealed patterns, or the Requests of other people. - While you type, each field shows if its rule agrees. Nothing goes until you send. ### A GET stays a GET `GET /hello` is a Request with the method `GET`. But the method of a Request came first from the header field `X-HTTP-Method-Override` of the client, then from `?_method=`, and only then from HTTP. So `GET /hello?_method=POST` was a `POST` for the envelopes. A link, or an `<img>` on a different site, could send a letter to an envelope for `POST`, from the browser of a person who did not know it. Now a `GET` is always `GET`. Only a `POST` can change its method. ### A link with fields A `GET` had no fields, so a short link could go to one place only. Now the query of a `GET` is a form, as a `<form method="get">` sends it. `GET /go?to=docs` has the field `to`, and the envelope reads it with `Content-Type: form` and a field line: ```envelope To: go X-HTTP-Method-Override: ^GET\$ Content-Type: form to: ^(?<to>[a-z]+)\$ ``` This made an old problem larger. An envelope with no line for the method agreed with each Request, also with a `GET`. With fields in the query, a link on a different site could fill a public form, from the browser of a person who only opened a page. So a `GET` now agrees only with an envelope that has a line `X-HTTP-Method-Override`. An envelope asks for a `GET`; the others get only a `POST`. When a `GET` does not agree for this reason, the list "Requests" of the editor tells it. ## Privacy Two promises: mkfifo.com keeps no copy of the Requests that go through it, and a secret in an envelope stays sealed. ### No copy of a Request I wanted this as a promise that a test can check. - Not in the database, not in the process of a FIFO, and not in the log at the level `info` and higher. - A property test sends a random secret through a FIFO, then looks for it in the log, in the database and in the process. - The invocation logs of Cloudflare are off. - The editor that is open shows each Request live, with the result of each envelope. It keeps no copy after it shows it. The home page tells it, and the [privacy page](/privacy) has the details. ### The cookie of the session A Request has the header fields of the HTTP request, also `Cookie`. When a browser sent a form to a FIFO, or opened the link of a held FIFO, its `Cookie` had the session of mkfifo.com. The report hid it, but a capture on `Cookie` could send it on to a different place. The session held only the token against false forms, so the harm was small, but a session with more in it would go to the owner of a FIFO. Now each Request loses the cookies of mkfifo.com (their names start with `_mkfifo`), and keeps the other cookies. Later the same day the rule became stricter: a Request keeps only the signed cookies of its own FIFO (see [One-time codes and cookies](/blog/2026-10-04-email-and-the-sign-in)). ### Sealed fields The name of a FIFO is its key (see "The name is the key" below): each person who knows it can read and change its envelopes. A token or a URL with a secret needs more than that. - Write `<seal:VALUE>` as a value, or close the lock of the field in the editor. - mkfifo.com encrypts the value for this FIFO (AES-256-GCM, bound to its name), and shows only `<sealed:TOKEN>`. A copy in a different FIFO does not open. - The report of a Request hides a sealed field and its captures. mkfifo.com does not guess which fields have a secret. You select them. ## The name is the key Whoever knows the name of a FIFO can change it. So a name must be hard to guess, it must not leak, and some names belong to the site. ### Two leaks 1. Each egress email came from `NAME@mkfifo.com`. So each person who got an email learned the key. Now each email comes from the reply address of its envelope, `reply+UUID@mkfifo.com`. A reply to it comes back to the FIFO as a Request, with `X-MkFIFO-Reply`. One day later, the reply address went away: mkfifo.com sends no email for your FIFO now (see [Your email service sends your email](/blog/2026-10-04-email-and-the-sign-in)). 2. A Request from one FIFO to the next had the name of the first FIFO in `From` and in `Received`. So the next FIFO learned the key of the first. Now it has the reply address there too. Later, only `Received: by mkfifo.com; DATE`. ### Random names A new FIFO gets a random name of three words. Two words gave about 4,000 names. Too few. Three words give about 500,000. When they get used up, the names get a number. The home page showed the random name as the placeholder of the field: gray text that looks like an example, and goes away when you type. Now the name is the value of the field, and a button with two arrows gives a new one. The button sends a small form of its own, `GET /`. So it works with no JavaScript, and Enter in the field still makes the FIFO: Enter sends the first button of the form of the field, and the arrows are not in that form. ### `.` and `..` A browser cannot open `/.` or `/..`: it goes to `/`. These two are not valid names now. ### Names of the site When I added holds, I said "no reserved names". Then the site needed `/contact`, `/support` and `/docs`, and the usual mail addresses, such as `postmaster`. I was wrong. Now `priv/repo/seeds/names.txt` keeps the names of the site: nobody can save an envelope there, and no FIFO can hold one. `blog` joined the list later. ### Names of two words A short name is easy to find, and one person can take many short names. So a new FIFO now needs a name of two words or more, with a `-` between them, as the name of a custom element of HTML: `my-shop`, or a random name such as `brave-red-fox`. A new held FIFO, and a new FIFO with a mirror in it, need 6 characters or more too. `PUT /shop` gets `422`, with an example of a name that agrees, and the home page and the editor tell the rule before the save. - The rule is only for new names. A FIFO with envelopes keeps its name, also a name of one word, with its holds and its mirrors. A FIFO is set and forgotten, so a FIFO must not stop because a rule changed. - "New" took some thought. A FIFO is new when no ingress envelope and no note has its name as the home. For a held name or a mirror, no `To`, `Cc` or `Bcc` of an ingress envelope uses it either. An egress envelope that sends to a name does not count: else each `To` of an egress could keep a short name open for a new FIFO. - The first version examined the name before the rules of the mirrors. So `Cc: support` got the error of a short name, not "The FIFO support belongs to mkfifo.com". Now the name comes last. - The seeds of the site keep their names of one word, as `contact` and `blog`. A name of one word, with 4 characters or more, is for a later step: a subscriber who locks a FIFO. - A hold is not a lock: each person who knows the name of the holder can change the held FIFO. Give the holder a random name of 26 characters or more (130 bits). - Most of the tests used names of one word. A script changed them to `my-NAME`, only in the strings of the tests. It also changed some data that was not a name, as the subject `x`, the host of `https://hooks.example/` and the type `text/html`. So I read each change before the tests ran. ## Contact and support `/contact` changed three times before it stayed. 1. An HTML form in the seeds. 2. The page of a held FIFO. 3. The locked editor of the FIFO `contact`, with "Try". I wanted each visitor to see the rules of the form, and to try them. The locked editor does both, with no special template. ### Try "Try" first came on each ingress envelope. One letter for the whole FIFO is better: one form tests all the rules, and the marks come from the envelope that is nearest. `?form` opens it at once, so the links Contact and Support open the form. Its button said "Send the letter" first; now it says "Submit", the usual word of a form, for each letter of mkfifo.com. "Try" is a link with no JavaScript, and a button that opens a dialog with LiveView. With no JavaScript, and on each page before LiveView connects, the page showed two "Try". The button had the class `hidden`, and also `inline-flex` from the class of all the buttons. Both set `display`, and in the CSS `.inline-flex` comes after `.hidden`, so the button always showed. Now the link and the button each set only their own display, and a test examines their classes. ### No secret in the Worker The address that gets the messages went from two secrets of the Worker to a sealed value in the seed. The Worker needs no secret for the site now. ### Starting over The seed saves only in an empty FIFO, so a new seed needs a new database. Cloudflare cannot delete the storage of one Durable Object. A new name of the object gives the site a new database: the old object keeps its data, but nothing reads it. Later, `support` started to share the envelope of `contact` (see "Mirrors" below). ## Mirrors `contact` and `support` had two copies of one envelope. Now they share one, with `Cc` and `Bcc`, as in an email. It took me three tries to get there. ### The path - **A custom field.** My first idea was a "mirror" with a header field of my own. It looked wrong next to the other fields. - **Cc and Bcc.** An email already has them. An ingress envelope with `Cc: support` also gets the Requests to `support`, and the editor of `support` shows it as a mirror. A FIFO can have the mirrors of many envelopes. - **Which FIFO got it?** I thought of a variable `{{fifo.name}}`, then of `Referer`. But the client writes `Referer`: a form on a different site sends that site, and an email has none. So each Request now has `Delivered-To` (RFC 9228). mkfifo.com sets it and removes the value of the client. `Delivered-To: ^(?<fifo>[a-z0-9._-]+)@` keeps the name. - **A wrong idea.** For a while I thought that a variable can come from a header field. It cannot: a variable comes only from a capture. - **Storage.** I planned a new table. Not necessary: a mirror is one row of the table `messages`, with no text. ### Safety A mirror gets each Request to its FIFO. So nobody can put a mirror in a name of the site, or in a FIFO that a different FIFO holds, and the editor of a FIFO can remove each of its mirrors. A mirror does not show the name of its home, its `Bcc` lines, or its destinations: the name is the key. ### Found before the merge - The check "a different FIFO holds this FIFO" also counted the own envelopes of that FIFO. So nobody could put a mirror in a FIFO with envelopes. A test found it. - `specs/Hold.tla` got mirrors: without one lock for all the saves, TLC finds a mirror in a held FIFO. ### Why not Cc in an egress envelope An egress envelope keeps one destination. The stop link, the confirmation, the result, the privacy of the addresses, the seal and the loops each work for one destination. Two egress envelopes for one ingress envelope already send to two places, and the new button "Duplicate" makes the second one with one click. ## Limits before the launch Anybody can make a FIFO, send a letter and save an envelope, with no account. That is the point of mkfifo.com. It is also what a spammer wants. So before the launch, I added limits: on the names, and on the number of actions. ### Names that look alike Some names belong to the site: `contact`, `docs`, `noreply`. But `supp0rt`, `contact-us` and `mkfifo-billing` were free, and a page there could look like a page of mkfifo.com. Now a name of the site also keeps each name that looks like it. I took the idea from the skeletons of Unicode (UTS #39): two names with one skeleton look alike. My skeleton is in lowercase, drops `-`, `_` and `.`, and puts one letter for the characters that look alike: `0` is `o`, `1` and `i` are `l`, `rn` is `m`. A name with `mkfifo` in its skeleton is kept too. This costs some good names. `mall` looks like `mail` in some fonts, so nobody can take `mall`. I prefer a few lost names to one false page. ### Addresses for reports `abuse`, `postmaster` and `security` (RFC 2142) were kept names, but an email to them was rejected. That is bad for a site that asks for reports. Now they are mirrors of `contact`, and `/.well-known/security.txt` (RFC 9116) gives `security@mkfifo.com`. ### Rate limits Each client address now has limits in a window of time: | Action | Limit | |---|---| | Requests to one FIFO | 120 in 1 minute | | Requests and letters to the FIFOs of the site | 20 in 10 minutes | | Letters of a page or of "Try" | 60 in 10 minutes | | Saves and deletes | 60 in 10 minutes | | Copies of a template | 10 in 1 hour | Over a limit, the answer is `429` with `Retry-After`, and the editor tells how long to wait. Only Cloudflare knows the address of a client. The Worker gives it to the VM in a header field, and removes the value that a client puts in that field. The VM counts an HMAC of the address, not the address. An IPv6 address counts with its /64 network, because one client often has all of it. A form of the editor is also a `POST /NAME`. So a Request counts after the parse of its body, and a save counts as a save. An email does not count, because Cloudflare Email Routing limits the emails. Only the Worker can mark a request as an email, so a client cannot use the mark to skip the limit. In front of all this, the Worker has the rate limit of Cloudflare: 600 requests in one minute from one address. A flood stops there, before the Durable Object. ### A limit only on paper The specification said: at most 16 ingress envelopes in a FIFO, and 4 egress envelopes for one ingress envelope. The save did not examine it. I saw it when I tried the rate limit in Wrangler: 60 saves into one FIFO, and all 60 got `201`. Now the save refuses the seventeenth. The saves of a FIFO go through its process one at a time, so two saves cannot both take the last place. A test sends 20 saves at the same time, and exactly 16 succeed.

Show the body Show the header

Egress envelopes of ingress envelope 9

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-703e-ae9e-5b75d1cf5eed@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

mkfifo.com is one of the first real apps on BEAM.com. These are the rough edges that I found and reported, and the numbers of a stress test: speed, memory, and the limits of one Durable Object. ## Running on BEAM.com mkfifo.com runs on BEAM.com: Erlang/OTP and Elixir in one file, and the VM in WebAssembly in a Durable Object. It is one of the first real apps on it, so I find the rough edges first, and report them. ### What I found - **exqlite.** beam.com always uses its own NIF of exqlite, so the project must use the same version (0.41.0). - **Protocols.** beam.com could not consolidate a protocol of Elixir again after a change: the compile stopped with `:missing_chunk`. So an envelope has no `String.Chars`; `FIFO.Envelope.text/1` writes it. - **Tests.** At first, there was no coverage tool, and the NIF of lazy_html did not load for the tests of LiveView. For a few hours I ran the tests on a standard Erlang/OTP of the same version. 0.1.0-rc.1 had both, and I went back to beam.com only. - **Hosts behind Cloudflare.** With rc.1, the VM opened its connections with `connect()` of the Worker, which cannot reach the addresses of Cloudflare. A webhook to such a host, and the API of Cloudflare Email Service, failed on the live site but not in `wrangler dev`. - **The scheme.** The Cloudflare host of rc.1 did not give the app `x-forwarded-proto`, so `force_ssl` redirected each request. The Worker set the header itself. ### rc.2 BEAM.com 0.1.0-rc.2 fixed the last two. HTTP and HTTPS go through `fetch()` of the Worker, and the host sets `x-forwarded-proto` from the URL. So I removed the code that set the header. The tools of rc.2 also put an `escript` in `PATH` for rebar3, so the build script does not make one now. The tests, the build, `wrangler dev`, and a webhook to a host behind Cloudflare on the live site all work with rc.2. ### The snapshot of the build, a mistake rc.2 can write a snapshot of the VM at the build (`npx beam.com --snapshot`). The first VM of a deploy restores it in place of a boot. mkfifo.com keeps its data in SQLite in the Durable Object, so it can use only a snapshot at the boot point: the modules are loaded, and the app does not run yet. It made the first request after a deploy faster: 4.3 s to 3.4 s on the live site, and 2.5 s to 1.4 s in `wrangler dev`. I added it, and I removed it again the same day. First, the deploy did not go out. A Worker can be at most 64 MiB (not compressed), and the upload was 67 MiB: `app.com` is 40 MB and the snapshot 21 MB. But 25 MB of `app.com` is the native program (the same file runs on Linux, macOS and Windows), and the Worker never reads it. The runtime reads only `lib/`, `releases/` and `.wasm/` of the zip at the end of the file. So the build now writes `edge.com` (`scripts/edge-com.mjs`): a zip with only these entries, with the same bytes at new offsets, 14 MB. The Worker imports it in place of `app.com`. Then the site reset many times with "exceeded its memory limit" while I read the blog. An isolate has 128 MB for the VM, the modules of the Worker and the JavaScript. I measured the memory of the VM after the first requests: - a VM that boots: 42 MB; - a VM from the snapshot of the build: 72 MB. The tool that makes the snapshot does not get the variables of the Worker, so its VM ran without `-Mea min`, the flag that turns off the allocators of ERTS. The restored VM kept those allocators. And the 21 MB of the snapshot stay in the isolate as a module. Together it was more than 128 MB. `wrangler dev` does not apply the limit, so all my local tests passed. With the flag (`--env "BEAM_ERL_FLAGS=-Mea min"`), the snapshot is 15 MB, and the VM 42 MB again. But the snapshot helps only the first VM of a deploy. After a reset, the object restores the snapshot that it made itself, in 0.2 to 0.5 s. One second for each deploy is not worth 15 MB in each isolate. So there is no snapshot of the build now, and `edge.com` stays: the modules of the Worker are 26 MB smaller than with `app.com`. Now I measure the memory of the VM after the first requests for each change of the Worker. ### rc.3 to rc.5 I tested rc.3 and rc.4 on a branch, with all the checks and the stress test, and kept rc.2 on the live site: each had a problem with the bodies of requests, and BEAM.com fixed them. mkfifo.com runs on rc.5 now. - `beam.com --target wasm32` writes only the part of a release that the WebAssembly runtime reads. It replaces my own script and its tests, and the Worker still gets `edge.com`. - The body of a request goes to the VM in parts, not at one time. When the app answers before the end of a body, for example `413` for a body that is too large, the host reads the rest and drops it. The next request works. - A body with `Expect: 100-continue` (curl sends it above 1 MiB) gets its answer in `wrangler dev` too. - The log gives the memory of the VM: `beam: memory 40 MB (a new peak of this VM)` after the first pages. The checks: the 1,500 tests with 100% coverage, the TLA+ models, the 137,203 cases of the builtins against the tools of the shell, and 1,710 random bodies of up to 1 MB from 32 clients, each with the correct hash. Large bodies take more time than with rc.2, so the gate below stays for now. ### Email through a port Until now, the app sent each email the way it would call any email service: an HTTPS request with a token to `sendmail.mkfifo.com`, a small route of the same Worker that gives the email to Cloudflare Email Service. The email left the Durable Object and came back in, with TLS at both ends. The next release of BEAM.com adds ports to bindings: `Port.open({:spawn_executable, "/env/NAME"}, ...)` in Elixir calls a JavaScript object of the Worker, with the bytes of the port as a stream. So the mailer now writes the JSON of the email to the port `/env/SENDMAIL`. The Durable Object gives the VM a small object with a `port()` function, which reads the email and sends it with the Email binding. There is no token, no URL and no TLS, and only the VM can open the port. It is not a new binding in `wrangler.jsonc`, so it needs no migration. The port and the HTTPS route share one function, so they give the same results and errors. In `wrangler dev`, a sign-in email took 24 ms of CPU time through the port. Through the HTTPS route, it took 28 ms in the VM and 8 to 10 ms more in the route. Where the port does not exist (on an older runtime, or in the tests on my computer), `Port.open` fails at once, and the mailer uses the route. I checked both in `wrangler dev`. When the port works on the live site, the token and the route can go. ### Less CPU time for each request I profiled one small request in the VM, with the profiler of the isolate and with `tprof` of Erlang. Two things stood out. The first was the names of header fields. Each request compares about 90 of them, without regard to case, and `String.downcase/1` reads the Unicode tables for each character. Most names are ASCII, so the app now compares the bytes, and uses `String.downcase/1` only for a name with a byte above 127. A character such as the Kelvin sign `K` still matches `k`, as before. Property tests compare the two ways. The second was the log. Phoenix wrote two lines for each request, and each line costs CPU time in the VM: about 7% of a small request. Now the log has one line only for a request that fails, with a status of 400 or more, such as `POST /my-movies 404`, with no query. The other requests are in no log at all, because the request logs of Cloudflare Workers are off too. Together, a small answer went from 16.5 ms to 13.4 ms of CPU time in `wrangler dev`. ### Downloads that skip the VM A download through a FIFO used to pass each byte through the VM. This was `cat` of a file from S3, or any reply with `Reply-To: -`. The Worker read the reply, gave it to the VM in pieces, and the VM gave the pieces back to the Worker for the client. For 1 MiB, that took about 100 ms of CPU time. Now the VM only decides. It checks the envelope and builds the request, as before. Then it answers with a header that names the request, and no body. The Worker sends the request and gives the reply to the client as it is, so the bytes stay inside the runtime and never enter WebAssembly. In `wrangler dev`, the same download of 1 MiB took about 30 ms of CPU time, and the median time went from 144 ms to 88 ms. This is the idea of `X-Accel-Redirect` in nginx, and it needs only the Fetch API. It applies to a `GET` with no body, and to `cat` of one file with nothing piped after it. A pipe such as `cat FILE | secretbox -d` still goes through the VM, because the VM changes the bytes. An envelope with `Errors-To` also goes through the VM, because it needs the result. The Worker waits at most 10 seconds for the reply to start, and does not follow redirects. One thing changes: when such a reply is not a success, the editor shows it as an answer, because the VM no longer sees the reply. ### Emails with a length An email comes to the Worker from Cloudflare Email Routing as a stream, and the Worker gave it to the VM with no length. With no length, the bridge of BEAM.com reads a body in parts of 32 KiB. Email Routing gives the size of each email, so now the Worker passes it on as `Content-Length`, and the bridge reads the email in large parts. In `wrangler dev`, an email of 4.3 MB with a file took 291 ms of CPU time, down from 433 ms. ## A stress test of BEAM.com mkfifo.com is one of the first real apps on BEAM.com, so it is a good stress test for it. I wanted numbers before BEAM.com 0.1.0: how fast one Durable Object is, how much memory the VM takes, and where it stops. ### The test `scripts/stress.mjs` is a Node script with no packages. Each scenario sends requests from 1 to 64 clients at the same time, for some seconds, and gives the requests each second, the latency (p50, p90, p99, max), the status codes and the errors. The scenarios are a static file, the home page, a Request with an answer, the editor, a JSON body and an HTML body with selector lines, an email with an attachment, a save, Requests to 100 FIFOs, an HTTPS egress, and open editors on WebSockets. For the memory, `GET /_/stats` gives `erlang:memory/0` and the counts of the VM as JSON. It answers only when the variable `MKFIFO_STATS` is `1`, so only in `wrangler dev`. The live site does not set it. I ran it in three places with the same release: `wrangler dev`, the release on a computer with the native `beam.com` (JIT, 4 schedulers), and the live site, through a proxy about 70 ms from Cloudflare. ### Numbers With one client, in `wrangler dev`: - A static file takes 7 ms. The front of the Worker serves it, with no VM. - The home page takes 14 ms, a Request with an answer 11 ms, the editor 19 ms, a save 22 ms. - A JSON body of 256 KiB with three selector lines takes 86 ms. The same with an HTML body and a CSS selector (lazy_html, a NIF in WebAssembly) takes 25 ms. The native VM is 2 to 7 times faster for the same request. Erlang code that uses the CPU is the slowest in WebAssembly: my JSON tokenizer takes 79 ms against 15 ms. The NIF of lazy_html is near native (18 ms against 11 ms), so most of the cost is the interpreter of Erlang, not WebAssembly. `FIFO.JSON` can be faster, and that is on my list. On the live site, one object gave about 190 Requests each second with an answer, and 125 home pages each second, from 64 clients. The VM is one thread, so more clients give a longer queue, not much more work. The memory: the idle VM takes 32 MB, with 492 processes. A FIFO process takes about 60 KB, until it stops after 5 minutes with no Request. An open editor takes about 0.7 MB. 100 of the 492 processes are the acceptors of Thousand Island, and they wait on the one socket that the bridge of BEAM.com gives. ### The start The first request after a deploy takes 4.3 s: the first VM boots, and makes its snapshot at the boot point. After Cloudflare resets the object, the VM comes back from that snapshot in 0.2 to 0.5 s. A snapshot of the build made the first request 3.4 s, but it cost too much memory (see "Running on BEAM.com"). ### Fixed - When the object could not take a request, the Worker threw, and the client got the page 1101 of Cloudflare ("Worker threw exception"). Now `handler.js` catches it, and answers `503` with the cause and `Retry-After: 1`. - The snapshot of the build made the Worker larger than 64 MiB, and then it made the object go over its memory. I removed it, and the Worker now gets only the release part of `app.com` (see "Running on BEAM.com"). ### Two limits, fixed The live site has the real 128 MB of an isolate, so it found two limits that `wrangler dev` did not. **Open editors.** About 75 open editors made the object go over its memory. I expected the LiveViews, and planned to hibernate them and keep fewer assigns. The numbers said something else. LiveView already hibernates an idle process after 15 s, and the live data of one editor is 42 KB. Most of the memory was garbage on the heaps of the processes of each WebSocket: the handler of Bandit (about 330 KB) and the socket of BEAM.com (about 280 KB). A process that waits does not collect its garbage, and the WebAssembly memory of the VM does not get smaller. One garbage collection took 50 editors from 32 MB to 4 MB. So `MkFIFO.Collector` now collects, each 2 s, each process that is larger than 64 KiB and two times larger than after its last collection. 100 open editors: the VM memory went from 129 MB to 80 MB. 100 editors that open at one time still made too much garbage between two passes, so each LiveView that joins now asks for a pass 250 ms later: the peak went from 87 MB to 70 MB. I also cut the acceptors of Thousand Island from 100 to 4: the bridge has one listener, so 96 of them only waited. **Large bodies at one time.** In my first test, most of eight emails of 2.7 MiB at one time failed. I was wrong about the cause: later, curl sent sixteen at one time with no error, and the errors came from my Node.js client, through the proxy of my test computer. But the risk is real. The runtime reads a body into JavaScript, makes a copy with the head, and then gives all of it to the VM, so sixteen such emails are about 90 MB of JavaScript, and the memory of the VM does not show it. So the object has a gate (`gate.js`): a body larger than 64 KiB waits until the large bodies in the VM are at most 8 MiB, in the order of arrival, for at most 20 s. An email waits too, because a Worker cannot ask the sender to send it again later. A body larger than 8 MiB gets `413` for now: alone, it could take too much memory. Since rc.3, BEAM.com gives a body to the VM in pieces, but the gate and its limit stay until I measure them on Cloudflare. There is one more limit, and it is in my notes for BEAM.com 0.1.0. I will write about it here when it is fixed.

Show the body Show the header

Egress envelopes of ingress envelope 10

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7045-9fcd-a9861210d140@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

Each streaming parser of mkfifo.com has one shape. On that shape came a JSON tokenizer, then selector lines that read the values of a JSON or HTML body, later one read of the body for all the envelopes of a FIFO, and last the HTML part of an email. ## One shape for stream parsers I wanted a streaming Markdown parser, and saw that it looks like the multipart parser. Each streaming parser here keeps only the bytes that it cannot decide yet. So they got one shape. ### The shape The shape of `TransformStream` of the web: `init`, `transform` and `flush` (`FIFO.Transform`). The multipart parser, the header of a MIME part, and the decoders of base64 and quoted-printable are steps of this shape now. One shared property test checks each step: all splits of an input into chunks give the same output, and the step keeps few bytes. ### Bugs that the test found - My first stream decoder of quoted-printable removed the spaces before an `=` that it kept at the end of a chunk. - An `=`, a CR and a space before the LF is a soft line break too. After the fixes, a check of all the texts of up to 6 characters, with all their splits into three chunks, found no more difference. ### A changed limit The limit of a text part of an email (4 MiB) now counts the bytes after the decode of base64 or quoted-printable, because the decoders work on the stream. ### Markdown The Markdown converter of this blog was the first new step of this shape, and egress envelopes can use it now. - The converter keeps the last line and one block. On 200,000 random texts with random splits, it gave the same HTML as the converter before it. - `{{note | markdown}}` in an HTML body gives the capture as Markdown. A form can send a message with a list and links, and the HTML email shows them. - An email with `Content-Type: text/markdown` has a plain text part and an HTML part. The Markdown is the text of the envelope, and a capture is only text in it (see [The rules of an envelope](/blog/2026-10-03-a-named-pipe-for-the-web)). - The filter in any other place is an error at the save. ### Later: tables On 6 October I put a table in two posts, and the blog showed rows of pipes and dashes in one paragraph. My converter did not know tables. Now it reads the tables of GitHub, in the blog, in the FIFO `markdown` and in an email of `text/markdown`. A table is hard for a stream. Its header row looks like a line of a paragraph until the next line comes: a row of `---` cells. So the header waits in the paragraph, as each line of a paragraph does. When a row of `---` cells comes, with the same number of cells, the last line of the paragraph becomes the header. The converter still keeps only the last line and one block. The property test now puts `|`, `---` and `:` in its chunks, and each split still gives the same HTML. On a phone, a wide table scrolls in its place, and the page does not. ### Later: quotes and images I wanted quotes and images in the posts, and the converter knew neither. A line that starts with `>` is a line of a quote now, and a line with only `>` starts a new paragraph in it. The quote ends at an empty line, or at a line with no `>`. CommonMark continues a paragraph of the quote on such a line, but then the converter must keep more than one block. `![alt](url "title")` is an image. The URL must start with `https://`, or with `/` for a path of the site. A path that starts with `//` or `/\` goes to a different host in a browser, so it is not a path of the site. An image alone in a paragraph is a figure, and its title is the caption. The alt text and the title get the escapes of HTML, as each text does. A page of Markdown could show only the images of the site: its `Content-Security-Policy` had `img-src 'self' data:`. Now it also has `https:`, so a page can show an image of a different site. Then that site sees the network address of each person who opens the page, and the privacy page tells this. The `Referrer-Policy` of a page sends only `https://mkfifo.com/` to that site, not the path of the page. The live view of Markdown in the editor follows the same rules, so a quote and an image get their styles there. The property test of the splits now has `>` and parts of images in its chunks, and each split still gives the same HTML. ## A streaming JSON tokenizer To read values out of a JSON body while it streams, I wrote a tokenizer that gives each value with its path. ### Why my own Jaxon streams JSON, but its last release is from 2021. The JSON module of OTP can continue a decode with more bytes, but it gives no path while it reads, and it keeps each string whole. ### Model first `specs/JSONTokens.tla` tells which bytes the tokenizer keeps at the end of a chunk. TLC finds the two faults: a number that goes out at the end of a chunk (`11` in two chunks gives two numbers), and a backslash that goes out as a character. My first version of the model had a bug of its own: at the end of the text, it compared an open string with an error. TLC showed it at once. ### Tests against other code - Random JSON texts give the value of `JSON.decode/1`. - Random values through `JSON.encode!/1` come back the same. - All the texts of up to 4 symbols, with all their splits into three chunks, give the same events. Limits: 64 levels of objects and arrays, a key of 1 KiB, a number of 64 bytes. ### Later: the JSON module of OTP The stress test showed that a JSON body with selector lines was the slowest request in WebAssembly. But the body of a Request is in memory anyway (at most 1 MiB), so the stream saved nothing there. Now the selector lines decode the body with `:json.decode/3` of OTP and walk only the parts that a path can find. Natively that is 3.6 times faster for a body of 200 KB; in WebAssembly, the selector went from about 55 ms to 35 to 45 ms. The interpreter is the limit now. Two details: - The callbacks of `:json` keep the order of the keys and the limits of my tokenizer. But `:json` does not always give the text of a number: `-0` becomes `0`, and `1E2` becomes `1.0e2`. The value of a number is its text in the body, so for those two forms only, a scan of the body gives the text. - A property test compares the new code with the old code on my tokenizer, with random JSON, parts of JSON, and bytes in the wrong place. 20,000 runs found no difference. The tokenizer stays, for a body that streams. ## Selector lines An ingress envelope can now read the values of a JSON or HTML body: ```envelope \$.order.id: ^(?<order>\d+)\$ \$.items[*].sku: (?<skus>.+) \$("td.code"): ^(?<code>[A-Z0-9]+)\$ ``` ### Why A body line on JSON, such as `"full_name":\s*"(?<repo>[^"]+)"`, breaks on an escaped quotation mark, and it finds the key at any depth. A path does not. ### The syntax `\$` for both. A JSON path starts with `\$` (a part of RFC 9535), and `\$("...")` reads as in jQuery. The values work as a header field: more values are joined with a comma, and no value is an empty value. So `\$.coupon: ^\$` accepts only an order with no coupon. ### HTMLRewriter, later I like `HTMLRewriter` of Cloudflare: it finds elements with CSS selectors while the HTML streams. But the VM cannot call a function of the Worker yet. So the CSS part uses lazy_html for now, behind one function, and I wrote a proposal for BEAM.com: functions of the host that Elixir can call. ### Found on the way - A CSS selector can have spaces and colons: `\$("a:first-child > b")`. So the name of a selector line ends at the first colon that is not in quotation marks, brackets or parentheses. The round-trip test of the envelopes then made the name `\$[`, which has no end now. That test makes selector lines separately. - A random key of more than 1 KiB hit the limit of the tokenizer, so the selector had no value. The limit is correct. The test makes smaller keys now. - I ran it in the Worker, with the VM in WebAssembly: a JSON order and an HTML table both gave their values. ## One read of the body A FIFO can have many ingress envelopes, and mkfifo.com tests a Request with each of them. Until now, each envelope with selector lines (`\$.id`, `\$("h1")`) or with the fields of a JSON body read the body again. A FIFO with 16 such envelopes decoded a JSON body of 1 MiB 16 times, or made 16 HTML documents of it. Now the body is read one time for all the envelopes of the FIFO. Before the test, mkfifo.com collects the selectors and the JSON paths of all the envelopes. At the first line that needs a value, one decode of JSON gives the values of all the JSON paths, and one HTML document gives the values of all the CSS selectors. The test of each next envelope uses these values. Two envelopes with the same selector have one value: the text of a selector is its key, and the name of a field gives its JSON path. The read is still lazy. mkfifo.com examines the header lines first, so when `Content-Type` or `Subject` does not agree in any envelope, it does not read the body. And an envelope still stops at its first line that does not agree. On my computer, natively, 16 envelopes and a JSON body of 765 KB took 355 ms before and 22 ms now. With a body of 1 MB of HTML, 542 ms before and 29 ms now. "Try" in the editor uses the same read for its marks. A test counts the reads: it traces the calls of `FIFO.Selector.values/2` while 16 envelopes test one Request, and expects one call. A process that traced itself got no trace messages, so the test runs the work in a different process, and waits for `erlang:trace_delivered/1` before it counts the messages. ### Not the FIFOs before The list of ideas had one more item for the graph: the editor shows the next FIFOs of each egress envelope, and it could also show the FIFOs that send to this FIFO. It will not. Many FIFOs can send to one FIFO, for example to `/bin/sh`, and most of them are FIFOs of other persons. Their names are their keys, so the owner of the FIFO must not see them. ## The HTML part of an email The first use case of mkfifo.com was a movie ticket: the cinema sends an email, and a FIFO sends the code and the link on. I had never run a real ticket email through it. So I wrote five fake ones, in the shapes that cinemas send: text and HTML in quoted-printable, HTML only in base64, a forward by hand, an automatic forward, and the email that asks you to confirm a forward address. Two things failed. ### Text or HTML Most emails have a plain text part and an HTML part. The body of the Request was the plain text, so `\$("td.booking-code")` found nothing in them. Only an email with no plain text had HTML in its body. Now an envelope says which part it reads, with the line that already tells the type of a body: `Content-Type: text/html`. That envelope reads the HTML part, and sees `Content-Type: text/html; charset=utf-8`. The other envelopes read the plain text, as before, so no envelope changed. When a FIFO has both kinds, mkfifo.com reads the body one time for each kind, not one time for each envelope. An envelope is for `text/html` when each of its `Content-Type` patterns matches `text/html`, one or more do not match `text/plain`, and no pattern has a variable. `html` is enough. `text` is not, because it matches plain text too. ### Attributes The link to an e-ticket, or the link that confirms a forward address, is in the `href` of the link, not in its text. `\$("a.eticket").attr("href")` gives it now, with the syntax of jQuery. ### Found in the tests - A `<td>` outside a table is not an element: the HTML parser drops the tag and keeps the text. One of my small test emails had a lone `<td>`, and its selector found nothing. - An email with only HTML and a PDF has the type `multipart/mixed`, so `Content-Type: text/html` did not match it at first. Now the envelope for `text/html` gets the HTML part of each email that has one. - An egress envelope gets the captures, not the body. So nothing after the ingress envelope needs to know which part it read.

Show the body Show the header

Egress envelopes of ingress envelope 11

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-704c-abae-324ef7a42879@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

A person who comes to mkfifo.com has a job to do, not a wish to learn regular expressions. So the gallery of templates grew from 5 to 24 (it has more now), and it has a box that asks "What do you want to do?". ## The templates I listed what a FIFO can do: it takes a form, an email or a webhook, it finds values with patterns and selector lines, and it sends an email, an HTTP request, a Request to a different FIFO, or an answer to the client. Then I listed the jobs that fit: - Forms of a static site: a page of thanks after the message, a waitlist, feedback to a chat, answers to an invitation, requests for a quote. - Emails: to a chat, receipts to a spreadsheet, tracking numbers to two places, monitor alerts to an incident tool, an address that hides yours, commands that pass DMARC. - Webhooks: Stripe payments to a chat, Shopify orders and GitHub issues to an inbox, a different shape of JSON, a filter of event types. - Answers: a short link, a FIFO that shows each webhook while you build an integration, a fake API for tests. A copy has no seal and no destination of the original: they become examples. "Use as template" is also on each editor and page. Each template has a sample Request, and a test checks that the sample agrees and that each variable has a capture. It found a bug of mine at once: five form templates had only body lines, and I had not put the empty line before them, so mkfifo.com read the patterns as header fields. One job did not fit: one webhook to two services, with the same JSON. A capture in a JSON body always gets the escapes of a JSON string, so a FIFO cannot send JSON on as JSON. That is on my list. ## A question box with no LLM I wanted a person to write what they want, and get the right templates. An LLM would do it, but I do not want one here. A small search does it well enough: - Each template has a few words: where its Requests come from (a form, an email, a webhook, a link), where they go (an inbox, a chat, an API, a page), and words of its job. - The question becomes words, with no small words, and each word goes through a list of synonyms: Slack and Discord are a chat, Stripe and checkout are a payment, inbox and Gmail are an email. - Each word gives points to a template: 3 in its words, 2 more in its title, 1 more in its description. The best first. "each Stripe payment to Slack" finds the Stripe template first, "tell me when my website is down" finds the alerts, and "newsletter signup" finds the waitlist. Two filters (where it comes from, where it goes) are there for a person who prefers to click. It is a GET form, so it works with no JavaScript, and the home page asks the same question. When a question finds the wrong template, the fix is a word in the template or a synonym in the list, not a bigger model. ## Later: the first FIFO The gallery helps a person who knows the service. A person with a new idea saw an empty editor and two words, ingress and egress. So `/docs` starts with the smallest FIFO that works: 1. Open a FIFO from the home page. 2. Save an ingress envelope with one line: `Subject: (?<subject>.+)`. 3. Add an egress envelope with `To: -` and the body `You wrote: \$subject`. 4. Send `curl -H 'Subject: Hello' -d '' https://mkfifo.com/NAME`, or push "Try". The answer is `You wrote: Hello`. An empty editor links to these steps, and a test does them, so they stay true when the rules change. Five templates came on the same day: Paddle, Lemon Squeezy, Calendly, Typeform and Linear. Lemon Squeezy broke the question box. My list of synonyms had `shopify` as a synonym of `order`, and `stripe` of `payment`. With one template for each kind, that was fine. With two templates for orders, "new Shopify orders by email" gave the same points to both, and Lemon Squeezy came first in the alphabet. Now the name of a service with its own template is a word of its own. ## Four personas, with no help Then I tested the site with four personas: a candle shop owner on a phone, a designer who reads English as a second language, a developer of web services, and a student who loves Unix. Each one started at the home page with no help, and decided what to do. Each one found problems that I did not see, because I know the site too well. - The search of the templates gave all the templates for "contact form to my email". Most templates have the words "email" and "form", so each one got points. Now a word gives more points when fewer templates have it (the IDF of a search engine: times `ln((N + 1) / (n + 1))`), and the result has only the templates with at least half of the points of the best one. That question now gives two templates, the contact form first. - The sign-in sent the email, but the form came back with no word about it, and with the mark "Code: agrees" for an empty code. Now it says "We sent you an email", it shows no mark before you change a value, and the code brings you to your home. - "Sign out" was the first button of the header on a phone, next to the address, and one tap signed out. It is in the home now. - The names of the header fields were cut: "Content-Typ" and "Authorizati". The rows of an envelope now share one grid, and the column of the names is as wide as the longest name. - The "+" buttons of the notes covered the text. The gap between the blocks is now as high as a button. - The cards of the templates were wider than a phone: a long JSON path made the column of the grid wide. A column of `minmax(0, 1fr)` fixed it. - The blog showed "Sign in" to a person who signed in: a page of the blog is the same for each client, so the cache can keep it. It shows "Account" now, a link that opens the home or the sign-in. - A link with code in its text, `` [`/~`](/~) ``, stayed as text: the converter took the code spans first, and they cut the link. Now it takes the code spans and the links in one pass. - The editor of a FIFO of your home told you to keep its name secret, under the notice that only you can change it. Both were there because the two notices came from different parts. Now a FIFO of a home has only its own notice. The docs now tell where the ID of `<ID@mkfifo.com>` comes from, how to change an envelope with its `Message-ID`, and how to open the terminal.

Show the body Show the header

Egress envelopes of ingress envelope 12

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7053-bf5a-55bc63c0a3c8@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180 A pipeline needs a FIFO that sends a Request on, and a different FIFO that examines the reply. The fields of a form came first, then a graph of nodes and edges in the database, then Reply-To and Errors-To. ## Fields of a form Most Requests to a FIFO come from a form of HTML, or bring JSON. Their data is in the body, not in the header fields. But an ingress envelope could examine the body only with one pattern for the full body. So my templates had lines such as `(?m)^email: (?<email>.+)\$`. ### A body of fields Now `Content-Type` can tell how to read the body: ```envelope Content-Type: form name: (?<name>\S.*) email: ^(?<email>[^\s@]+@[^\s@]+)\$ website: ^\$ ``` `Content-Type` is still a pattern. mkfifo.com tries it on samples: `application/x-www-form-urlencoded` and `multipart/form-data` for a form, `application/json` for JSON. When it agrees with one, each body line is `NAME: PATTERN`. `form` agrees with both types of a form, and `^application/` agrees with a form and with JSON. For JSON, a name is a key of the top object, or a JSON path: `\$.order.id: ^\d+\$`. A missing field is an empty value, as a missing header field, so `website: ^\$` is still a honeypot. ### The text of a form is not the form A form already became text in the body: one line `name: value` for each field. I thought of reading the fields back from that text. Then a `<textarea>` with the line `email: x` would add a field `email`. So the Request now keeps the fields of the form, with their names and their values, and a field line reads them, not the text. ### Try sends a real form "Try" put the fields of its letter in header fields. So a letter could agree with an envelope that a real form of HTML never agreed with. Now the letter of an envelope with a body of fields sends a form, the same Request as the form on your site. ### A field called name In a check in Chromium, `?form&name=Ann` put the name of the FIFO in the field `name`. The editor read the query from the parameters of the page, and the path `/:name` has a parameter `name` too, which wins. Now the first render reads the query of the request, and the browser sends the query of the page when it connects. ### What did not change The FIFOs of the site, such as `/auth`, keep their header lines for now. The start of mkfifo.com puts a seed only in a FIFO of the site with no envelopes, and a letter of mkfifo.com still sends header fields to them. This is the first of three steps. The next step is `Reply-To`: a FIFO sends a Request on, and a different FIFO examines the reply. Then a pipeline goes across FIFOs. ## A graph of nodes and edges The next step is a pipeline across FIFOs: a FIFO sends a Request on, and a different FIFO examines the reply. Then one envelope links to more than one FIFO in more than one way. The table `messages` had a column for each link: `to`, `home`, `in_reply_to`, and one more row for each mirror. A pipeline needs more links, not more columns. ### Two tables Now the database is a graph: `nodes` and `edges`. The columns have the names of the property graphs of SQL (SQL/PGQ), which PostgreSQL 19 brings: `label`, `source`, `destination` and `properties`, as JSON. An envelope, a note and a FIFO are nodes. Each line of an envelope that names a FIFO or a different envelope is an edge. I first planned a label for each type of edge. But the node and the line already tell the purpose: a `To` edge of an ingress envelope is where its Requests come from, and a `To` edge of an egress envelope is where it sends. So each edge has the label `link`, and its property `field` is the line: `To`, `home`, `Cc`, `Bcc`, `call` or `In-Reply-To`. A FIFO is a node now. My first design said "A FIFO is not a record in the database". With a node, a FIFO can later have a description, decorations and its own "Try" form. ### The check of the loops reads no text Before, the check of the loops parsed the text of each envelope on the path, and opened each sealed `To` again. Now the save opens a sealed `To` one time, and writes its edge. The check reads only the `To` and `call` edges. ### Writes with no rollback **Each statement commits alone.** In a Durable Object, a rollback does not undo. So a save adds before it removes: the FIFO nodes, the new edges, the node, then the old edges. A delete removes the nodes first, then their edges. A stop between two statements leaves only edges that no read uses, and the start of mkfifo.com removes them. **A node of a FIFO can go too early.** A FIFO node goes away with its last edge. A save puts in the node of a FIFO, then adds its edge. A different save can remove that node between the two statements, because it has no edge yet. I wrote a TLA+ model of the writes with stops (`specs/Edges.tla`). Without one lock for all the writes, TLC finds an edge to no node. With the lock, it finds no error. Before, only the saves with an edge to a FIFO took the lock. Now each save and each delete takes it. **100 parameters.** A Durable Object accepts at most 100 bound parameters in one statement. The old load of the mirrors of a FIFO put the id of each mirrored envelope in one list. Now a long list is a subquery, or more than one statement. A test counts the parameters of each statement. **A sealed To uses a name.** Before, a name was free when no `To` had it as plain text. Now the edge of a sealed `To` also uses the FIFO. ### The data stays The migration moved each envelope of `messages` to the graph at the start, and opened each sealed `To` for its edge. I checked it in `wrangler dev`: I saved FIFOs with the old version, a mirror, a hold, a note and a sealed `To`, then started the new version on the same storage. The loops, the mirror and the hold worked as before. ## Pipes in the graph The first version of the graph had one label for all the edges: `link`. It told nothing. Web Streams has two words for the one thing that a pipeline needs to know, "does the answer come back?": `pipeTo` and `pipeThrough`. So the edges got these labels. ### Edges in the direction of the data - `pipe_to`: the data goes to the destination, and stops there. A Request to a FIFO goes to its ingress envelopes. The captures go to the egress envelope. The egress envelope sends to a different FIFO. - `pipe_through`: the data goes through the destination, and its answer comes back. `{{email | totp}}` is a `pipe_through` edge to `totp`. In the next step, `To: b` with `Reply-To: c` is `pipe_through` to `b`, then `pipe_to` to `c`, as `pipeThrough(b).pipeTo(c)`. - `has`: no data. A FIFO has the envelopes and the notes that you edit there. Before, an edge went from the line to the thing that the line names. Now it goes in the direction of the data. Then a pipeline is a path, and a loop of FIFOs is a cycle of pipe edges. The check of the loops reads all the pipe edges that the data of a FIFO can follow in one recursive statement. Before, it read the edges of each FIFO on the path in two statements. The recursion keeps each node one time, so it stops also on a cycle. ### JSONB SQLite has JSONB: JSON in a binary format, in a `BLOB`. The JSON functions read it with no parse, and `properties ->> '\$.name'` can have an index. The `:map` type of Ecto writes JSON text, so I wrote an Ecto type that writes and reads the bytes of JSONB itself. SQLite is the reference in its tests: a property test gives random JSON values to the type, and SQLite must read each one. A second property test gives the JSONB of SQLite to the type, and the type must read it. Before I wrote it, I checked JSONB in a Durable Object with `wrangler dev`. `jsonb()`, `->>`, the unique index on the name of a FIFO and `WITH RECURSIVE` work. `sqlite_version()` does not: the Durable Object does not permit that function. ### A new version removed the edges of others With the new directions, the edges of an ingress envelope also include edges of other envelopes: the `In-Reply-To` of its egress envelopes and of its notes. A new version that removes all the old edges of its node would remove these too, and the egress envelopes would go from the Requests. So a write changes only the edges of its own lines, and a test saves a new version of an ingress envelope and keeps the edges of its egress envelope and its note. ### A new database mkfifo.com is not live yet. So I removed the move of the old table. One migration makes the graph, and the Durable Object has a new name: it starts with an empty database, and the start puts the FIFOs of the site in it again. ## Reply-To A FIFO could match a Request and do something, but it could not examine what came back. An HTTP request gave its status as a result, and the response went nowhere. Now `Reply-To` tells where the reply goes. ### Through, then to ```envelope To: https://api.shop.example/orders Reply-To: orders ``` The data goes through the API, and its response goes to the FIFO `orders`, as `pipeThrough(api).pipeTo(orders)` in Web Streams. `orders` gets a Request with `Status`, `Content-Type` and the body of the response. Its ingress envelopes examine them with the fields of the body, so a FIFO can match on `\$.id` of a JSON response and do the next step. A pipeline goes across FIFOs, and each FIFO stays one ingress and its egress envelopes. A reply can be large, so the HTTP adapter reads a response as a stream, and stops after 1 MiB. `Reply-To: -` gives the reply to the client. With a FIFO in `To`, its answer comes back: the same thing as a call, but for the whole message. ### The first answer wins I let the FIFO of a reply answer the first client. A client gets one answer, so the first answer wins, and a later answer egress fails, as before. The state of the answer now goes with the Request of a reply: the client waits, has its answer already, or does not exist (an email, or a Request from a different FIFO). ### Programs `To: program:totp` gave the answer of the program to the client, as a special case. Now a program is a destination like the others, and its answer is a reply. So the seeds of `totp` and `markdown` have `Reply-To: -`, and a program with no `Reply-To` is an error at the save. ### In the graph With `Reply-To`, the `To` of a FIFO is a `pipe_through` edge, because its answer comes back, and the `Reply-To` is a `pipe_to` edge. The check of the loops reads them as the other pipe edges. ### Reply-To was taken `Reply-To` already had a meaning: the `contact` seed sends an email with `Reply-To: {{from}}`, the address for a reply to the email. So for an email, `Reply-To` keeps that meaning. A copy of `/contact` sends its email as an HTTP request to an example URL, and there `Reply-To: {{from}}` is not valid. The first test of a copy failed on it. Now a copy keeps only `Reply-To: -` of an HTTP request. ## Old seeds in a new build After the deploy of `Reply-To`, the new code was on mkfifo.com, but `/totp` and `/markdown` gave no answer. In `wrangler dev`, with the same commit, they answered. ### What was different The two FIFOs need `Reply-To: -` now, and the seeds have it. The editor of `/markdown` on mkfifo.com showed the egress envelope with no `Reply-To`. The Durable Object was new, so I first thought that it was an old database. But the `Message-ID` of a seeded envelope is a UUID of version 7, and its first 48 bits are a time: 15:15:12, after the deploy. So the new object saved an old seed, and the release had the old seeds. ### Why `FIFO.Site` reads the seeds at the compile, so the release needs no file of `priv/repo/`. Its `__mix_recompile__?/0` told Mix to compile it again only when a file of the seeds came or went. For a changed file, Mix compares times. A build that keeps old files of `_build` can give them newer times than the files of the commit, and then a changed seed does not compile the module again. The blog has the same code, and the new post was there: a new file comes, so the blog compiled again. ### The fix - `FIFO.Site`, `FIFO.Gallery` and `MkFIFO.Blog` now keep the SHA-256 of their files, and compare it in `__mix_recompile__?/0`. A file that comes, goes or changes compiles the module again. - The node of each FIFO of the site keeps the SHA-256 of its seed. At the start, a FIFO whose seed changed loses its envelopes and gets its new seed. Before, a new seed needed a new database: five times since the start of the project. Nobody can change a FIFO of the site, so nothing of a person goes away. ## Errors-To An egress can fail: the service answers 500, the next FIFO has no envelope, or the Request goes through too many FIFOs. The client gets `502`, and an open editor shows why. But a webhook has nobody at the other end, and the editor is usually closed. So nobody knew. ### A second output A process in a shell has two outputs. `Reply-To` was the standard output. `Errors-To` is the standard error, as `2>`: ```envelope In-Reply-To: <ID@mkfifo.com> To: https://api.shop.example/orders Errors-To: shop-alerts ``` When this egress fails, `shop-alerts` gets a new Request: ```envelope Error: The destination answered 500. Envelope: <0199a7c3-...@mkfifo.com> ``` `shop-alerts` is a usual FIFO. It can match `Error: (?<error>.+)` and send `\$error` to a chat. The name comes from email: `Errors-To` is an old header field for the address of the bounces. The error is one more hop of the Request, so an error of an error cannot go on forever. `Errors-To` is an edge of the graph, so the save refuses a loop. And the egress stays failed: the error does not change the result. ### No name in the error The Request of the error does not tell the name of the FIFO that failed. A name is the key to change a FIFO, and `shop-alerts` can belong to a different person. `Envelope` tells which egress failed, and a `Message-ID` alone opens nothing. ### Reply-To leaked a name That rule made me look at `Reply-To` again, and I found a leak. The HTTP adapter sent each header line that it did not know as a header field of the request, and `Reply-To` was not on its list to skip. So `Reply-To: orders` went to the service, and the service learned the name `orders`. A Request to the next FIFO had it too. Now no adapter sends `Reply-To` or `Errors-To`, and a test examines what an HTTP service and the next FIFO get.

Show the body Show the header

Egress envelopes of ingress envelope 13

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-705a-8de1-c3682bbbf352@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

The fonts of the site come from a FIFO, and the colors of the code come from a font. Neither needs a script in the page. ## The fonts come from a FIFO The fonts of this site were static files at `/fonts/NAME.woff2`. Now they come from the FIFO `/fonts`, with the same envelopes that each person can write. mkfifo.com is the first user of a `GET` with an answer. ### The site holds a name, as a person does `fonts` is a name of the site, and no FIFO can hold a name of the site. A seed of the site is the only exception: the FIFO `mkfifo` holds `fonts`. Its locked editor at [/mkfifo](/mkfifo) shows the two envelopes: ```envelope To: fonts X-HTTP-Method-Override: ^GET\$ Content-Type: form file: ^[A-Za-z0-9-]+\.(woff2|txt)\$ ``` ```envelope To: program:fonts Reply-To: - ``` The query of a `GET` is a form, so `file` is a field. The program `fonts` gives the file with that name, and `Reply-To: -` sends it to the browser. A different name gets `404`. The ingress envelope has no note, because a note would give `/fonts` a page with a letter. ### A URL for each version A browser keeps each font for one year (`Cache-Control: immutable`). Thus a changed font must have a new URL. The CSS loads `/fonts?file=NAME&v=VERSION`, and `VERSION` is the start of the SHA-256 of the file. When I build FIFO Code again and do not change the CSS, a test tells me the new value. ### A GET is not a letter Each Request to a FIFO of the site counted in a limit of 20 in 10 minutes for one address, because a letter to `/contact` sends an email. One page loads about 6 fonts, so the fourth page would show no fonts. Now a `GET` counts only in the limit of its FIFO: 120 in one minute. A `GET` cannot send a letter: only an envelope that asks for a `GET` gets it. ## Colors in a font The envelopes on this site were plain text: a header name, a pattern, a variable and a call all had one color. A syntax highlighter needs JavaScript in the page, or a parser on the server for each language. I did not want either. Now the colors come from the font. ### A font with rules Heikki Lotvonen made [a font with a syntax highlighter in it](https://blog.glyphdrawing.club/font-with-built-in-syntax-highlighting/). Each glyph has colored copies, and OpenType rules change a glyph to a copy from the glyphs around it. Its rules are for HTML, CSS and JavaScript, and its face is not the code font of this site. So I used the same method on IBM Plex Mono, with rules of my own for Elixir, Erlang and envelopes, and later also for HTML, CSS, JavaScript and a shell. IBM Plex reserves the name "Plex", so the result has a different name: FIFO Code. ```elixir def render(template, :markdown) do {:ok, "text"} |> Enum.map(&String.trim/1) # a comment end ``` ```envelope Subject: ^Order (?<id>\d+)\$ Code: ^\$email | totp\$ Authorization: <sealed:QX7z-k2> ``` ```js const answer = await fetch(`https://mkfifo.com/\${name}`, { method: "POST" }); ``` The parts: - Each ASCII glyph has one copy for each color. A copy is a composite of the glyph, so a browser with no color fonts shows the usual glyph. - A rule sees the copies that its own lookup made before it. So a lookup is a small state machine: after `"`, each glyph becomes a copy of the string color, up to the next `"` with no backslash before it. - The name of a function comes before its `(`. A reverse rule reads from right to left, so the name can have any length. - Each language is a stylistic set: Elixir, Erlang, an envelope, one value of an envelope, HTML, CSS, JavaScript and a shell. In the blog, the word after the three backticks of a code block selects it: `elixir`, `erlang`, `envelope`, `html`, `css`, `js`, `json`, `sh`, `shell`, `bash` or `console`. JSON uses the rules of JavaScript. - The font has two palettes. The code of the blog uses the dark one, with `font-palette: dark`. The editor uses the font too. A `<textarea>` is text, so the fields of an envelope show the colors while you type, with no script. ### A shell The site shows many commands with curl: on the home page, in `/docs`, and in the editor of an empty FIFO. They have colors now too: ```sh printf 'X-GitHub-Event: ^push\$\n' | curl -X PUT --data-binary @- https://mkfifo.com/deploys # save for f in *.eml; do curl -T "\$f" "https://mkfifo.com/\$NAME"; done ``` The command is the first word of a line, or the word after `|`, `&&`, `;` or `\$(`. A line that starts with spaces continues a pipe, so its first word is a command too. A URL keeps no color. With the usual edge of a word, `done` in `https://mkfifo.com/done` would be a keyword, and `to` in `?to=docs` would be a variable. So a keyword of a shell is not a keyword after `/`, `.`, `-` or `:`, and a name before `=` is a variable only at the start of a command. ### Three bugs The first build colored `do` and `end` in comments. The lookups of a feature run in the sequence of their definitions in the font, not in the sequence of the feature block, and my script put the keywords first. Now the list of keywords is a comment in the rule file, in its place. A test with HarfBuzz, the shaper of Chrome and Firefox, shapes sample lines of each language and compares the color of each glyph. The examples on `/docs` and on the home page stayed plain. Their `<pre>` also had the class `font-mono` of Tailwind. A utility comes after a component, so `font-mono` won over my class. The two classes of the font are now in no layer. The fonts are files in the repository, and the continuous integration builds them again from the rules, to make sure that nobody changed a rule and forgot the build. On the first run, the check failed: the runner has Python 3.12, and my computer has 3.11. The two wrote the same tables with their parts in a different sequence. The check now compares the tables, not the bytes. ### What a font cannot do A rule sees one line only. A heredoc, a comment on more lines, or a tag of HTML on more lines shows as text after its first line. One code block has one language, so a `<script>` in HTML has no colors of JavaScript. I tested the font in Chromium and with HarfBuzz. Safari uses a different shaper, and I will test it there.

Show the body Show the header

Egress envelopes of ingress envelope 14

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7061-bbb8-35017bc471b2@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174 A call of a FIFO in an envelope started as a filter, in the syntax of Liquid. In one day it became the syntax of a shell, with builtins that have the names and the options of the commands of a shell, and limits for their work. ## A filter is a FIFO In Unix, a FIFO is a named pipe between processes. A variable such as `{{email | totp}}` already has a pipe in it, but `totp` was code in the parser of the variables. Now it is a FIFO: a process that takes a Request and gives an answer. ### A call `{{email | totp}}` gives the capture to the FIFO `totp` as the body of a Request, and the body of its answer is the value of the variable. It is `\$(...)` of a shell. `{{a | f | g}}` is a pipe: the answer of `f` goes to `g`. Each FIFO with an answer egress can be a filter, also your FIFO. For example, a FIFO `countries` with one ingress envelope for each code and an answer with the name: ```envelope X-HTTP-Method-Override: ^POST\$ ^FR\$ ``` ```envelope To: - France ``` Then `{{country | countries}}` in a different envelope gives `France`. ### How do you make totp with envelopes? You cannot do all of it. A one-time code needs a secret key that nobody reads, a hash, and the memory of a used code. An envelope has none of them, and that is on purpose: mkfifo.com keeps no Request. Unix has the same split: a shell script reads its input, then runs a compiled program for the hard part. So `/totp` is a FIFO of the site with two envelopes. The ingress envelope is the input: a value in the body, and maybe a code to check. The egress envelope is `To: program:totp`: it gives the Request to a small program of mkfifo.com, and the answer of the program is the answer of the FIFO. `/markdown` is the same. Open them and push "Try". Only a FIFO of the site can have a program. ### The check is one step In a pattern, `Code: ^{{email | totp}}\$` cannot only ask for the code and compare it. The code must also be used, so that it agrees one time, and the key of the code changes at that use. A call to ask and a second call to use could let two Requests use one code. So a call from a pattern also sends the value under test, in the field `X-Test`. `totp` checks the code and uses it in one step, and answers it. A wrong code gets the status 422, and the line does not agree. The key of a code has the FIFO of the envelope that calls `totp`. mkfifo.com gives it to the program, not in a field of the Request: the name of a FIFO is the key to change it. A code that you get from `/totp` itself is valid only for `totp`. ### A call is an edge A call is an edge of the graph of FIFOs, as an egress envelope to a different FIFO is. A save that makes a loop of calls gets 422. The TLA+ model of the loops had one target for each save. A save with calls can add edges to more FIFOs at one time, so the model has that now, and TLC finds no loop. A sealed pattern could also have a call in it, and the check of the loops does not open a seal. A sealed value could not have a variable, but the save of an ingress envelope did not examine it. Now it does. ### No report from totp A Request to `totp` has a code in `X-Test`. The editor of a FIFO of the site did not show its Requests, but mkfifo.com still sent the report to it. Now a FIFO of the site gets no report. ## The syntax of a shell A FIFO is a process: a Request goes in, and an answer comes out. So a call of a FIFO should look like a call in a shell. The envelopes said `{{email | totp}}`, the syntax of Liquid. Now they say `\$(totp \$email)`, or `\$email | totp`. ### Four forms and a pipe - `\$name` puts a capture in the text. `\${size}px` needs the braces. - `\$(fifo word ...)` calls a FIFO, and puts its answer in the text. - `\$a | f | g` gives `\$a` to `f`, and the answer of `f` to `g`. It is `\$(g \$(f \$a))`. - `\\$` is a `\$`, and `\|` is a `|`. mkfifo.com does not run a shell. It reads only these forms: no `\${name:-default}`, and no `\$((1 + 2))`. ### I left the pipe out, and that was wrong My first version had no `|` at all. A call in a word already did the job, `\$(g \$(f \$a))`, and I wanted one way to write it. But the pipe is the first thing that a person who knows a shell looks for. It also reads from left to right, in the direction of the data. So the pipe is back, after a variable or a call. Inside the parentheses it stays an error. `\$(f \$a | g)` could mean two things, and the error tells you to write `\$(f \$a) | g`. ### The `\$` and the `|` of a pattern An ingress envelope has regular expressions, and they use `\$` for the end of a line and `|` for "or". So a `\$` is a variable only before a lowercase letter, `_`, `{` or `(`: `\$5` stays a price, and `^\$(totp \$email)\$` keeps its last `\$`. A pipe needs a space at each side and the name of a FIFO after it, so `^(\$a|\$b)\$` and `\$a | Paid` stay patterns. No pattern of the templates changed. ### Words are fields In a shell, the words of a command are its arguments. Here, the words of a call are the fields of a form: `1`, `2`, ... in their sequence, and `--name=word` is the field `name`. A pipe gives its value as the field `1`. ```envelope \$(markdown \$note) \$(greet \$name --lang=fr) ``` The Request of a call is a form. So the FIFO examines the words as it examines a form of HTML, and a FIFO of a person needs nothing new to get a call: ```envelope Content-Type: form 1: \S ``` ### Bugs on the way - The ingress envelope of `totp` was `\S` on the body: a value that is not empty. But the body of a call is a form now, and the form of a space, `1=+`, is not empty. So `totp` gave a code for a space. Now it examines the field: `1: \S`. - The check of a URL put a sample in place of each variable, with a regular expression of the old syntax. So `https://example.com/\$(totp \$x)` was not a valid URL. The check uses the parser for its sample now, so the two cannot disagree. - A cookie name can have `\$` (RFC 9110), so `\$name=1` was a cookie name with a variable in it. A cookie name cannot have `\$` now. - A call with no `)` took the rest of the envelope with it. A variable and a call stay on one line now, and an error stops at the line break. - A body of Markdown uses `\|` for a pipe in a cell of a table. If the template made it a `|` first, the pipe would cut the cell in two. So a body of Markdown keeps `\|`, and the converter of Markdown makes it a `|`. ## Builtins: the commands of a shell in an envelope An envelope could call a FIFO with `\$(fifo word ...)`, and the FIFOs of the site `/totp` and `/markdown` gave their Request to a program of mkfifo.com with `To: program:NAME`. It worked, but it was not a shell. `totp` was a FIFO with a program behind it, and each word of a call was a field `1`, `2`, ... of a form. Now an envelope has builtins, as a shell has commands, and a pipe gives data to a builtin or to a FIFO. ### Two kinds of commands `\$(name word ...)` runs a builtin. The words are its arguments, and its output goes in the text: ```envelope To: https://api.example/hooks X-Request-Id: \$(uuidgen) X-Date: \$(date -R) X-Signature: \$(\$body | hmac <seal:KEY>) \$body ``` After a pipe comes a builtin or a FIFO. A builtin gets the value as its input. A FIFO gets the value as the body of its Request, and its answer comes back: `\$(\$name | lower)` with your FIFO `lower`. A FIFO takes no words: its input is all its data. Only a builtin can start `\$( )`. `\$(lower \$name)` is an error, and the error says: "To send to a FIFO, write \$value | lower." Thus the first word in `\$( )` has one meaning, and each place where data goes to a FIFO has a `|`. ### The same names, the same options The builtins are `printf`, `tr`, `cut`, `head`, `tail`, `wc`, `base64`, `sha256sum`, `md5sum`, `hmac`, `random`, `uuidgen`, `date`, `cat` and `tee`, and also `markdown` and `totp`. Each one has the name and the options of the command of a shell. If you know `tr A-Z a-z`, you know the builtin. An option that a builtin does not have is an error, not a different behavior: `head -q` gives "head: the option -q is not supported." `tee` sends its input to FIFOs, as `tee` of a shell writes to files: a FIFO of mkfifo.com is a named pipe. A FIFO after a pipe, and a FIFO of `tee`, is an edge of the graph, so the save refuses a loop. A builtin is not an edge. The names of the builtins are names of the site. No FIFO can have one, so the name after a pipe has one meaning. ### totp is a command now The sign-in did not change: `Code: ^\$(totp \$email)\$`. In a pattern, a builtin with no input gets the value that the line examines. Thus `totp` gets the code of the field `Code`, checks it, and uses it in one step. The key of a code has the home of the envelope, as before. `/totp` and `/markdown` went away. The start of mkfifo.com now removes a FIFO of the site when its seed goes away: it deletes the envelopes and the notes, and the node forgets the seed. `/fonts` reads its files with `cat`: ```envelope To: - Content-Type: font/woff2 Cache-Control: public, max-age=31536000, immutable \$(cat fonts/\$file) ``` ### A key that only hmac opens A signature needs a key that nobody reads. A word `<seal:KEY>` in `\$( )` is sealed at the save, as a sealed field is. Only `hmac` opens it, in the FIFO that sealed it. The other builtins see `<sealed:TOKEN>`. ### Limits first A builtin runs in the Durable Object with all the other FIFOs. Thus a small envelope must not make a large work. - No builtin reaches the network or writes a file. `cat` reads only the public files of the site, and `tee` sends only to FIFOs. Only `totp` keeps data: hashes, in memory, for 15 minutes. - The input, the words and the output of a builtin are each at most 1 MiB. - A Request runs at most 1024 builtins, and their inputs, words and outputs are at most 16 MiB in all, also in the FIFOs after its pipes. My first versions of `printf` and `cat` made all their output, and then compared its size with 1 MiB. `printf` with a width of 65536 and 5000 words makes more than 300 MiB before that check. Now they stop at 1 MiB. `tr`, `cut`, `head`, `tail`, `wc` and `base64` made a list of each character or each line. In a test, such a list for 1 MiB of text used 56 MiB of memory. Now they read the input one time, with no list. A property test runs each builtin with random words and random bytes. It found three exceptions, and I fixed them: a `tr` range across the surrogates of UTF-16, an option with a byte that is not UTF-8, and `markdown` of bytes that are not UTF-8. The same review found a limit that each template needed, also before the builtins: `\$body` 2000 times in one envelope makes a message of almost 2 GiB. Now the values in one message are at most 2 MiB, with each use of a value. In a pattern, the values of one line are at most 64 KiB: PCRE cannot compile a larger pattern, and the escape and the compile take time before that error. ## The size of a word The words of a builtin are at most 1 MiB, and `printf` refused a larger word. But the check came too late: it came when the builtin started, after the words had their values. ### How a word grows A word joins its parts with no space: `\$first.\$last`, `--subject="Order \$id"`. A variable can come many times in one word. An envelope has at most 16 KiB, so one word can have about 8,000 copies of `\$body`, and a body has at most 1 MiB. A word of 8 GiB is much more memory than the VM has. I found it when I read the code of the words for the next branch, and a test showed it: 200 copies of a value of 1 MiB made a word of 200 MiB, and only then `printf` said that the words were too large. ### The fix Now the evaluation of the words counts their bytes, and stops at 1 MiB, before the builtin runs. The error is the same as before: `printf: the words are larger than 1 MiB.` The limit is for all the words of one command, and a command in a word stops at its own words. The values in a message (2 MiB) and in a line of a pattern (64 KiB) already had a check before the values went in. The words were the one place with no check before.

Show the body Show the header

Egress envelopes of ingress envelope 15

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7068-b585-381e5a794267@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177 Each builtin is a web API at `//bin/NAME`, and the editor of each FIFO has a terminal for the same shell. The terminal became the form of `/bin/sh`, and `gzip` and `gunzip` came as builtins. Then an assistant got the same shell, through the MCP endpoint `/mcp`. ## A terminal in the editor The editor of each FIFO has a terminal now. It is hidden: Ctrl and the backquote key open it, as in many code editors, and so does `?terminal` after the address of the editor. A phone has no Ctrl key, so three quick taps on the name of the FIFO open it there. ### Why a terminal The builtins have the names and the options of the commands of a shell, and I check them against the real tools. But to try `jq` on a body, I had to save an envelope, send a Request, and read its report. The terminal runs one line at once. It uses the parser of the envelopes, so a line that works there works in `\$( )` of an envelope. ```sh body='{"id": 7, "price": 1.50}' \$body | jq -c '{id, price}' printf '%s\n' b a c | sort ``` A variable is a capture: `name=WORD` gives it a value, and a variable with no value is an error, as in an envelope. A value in single quotes can have more lines, so a sample body goes in as it is: Enter in an open single quote adds a line, as the second prompt of a shell. The field and the lines have the colors of a shell, from the font FIFO Code. My first idea was the restricted `:shell` of Erlang. It reads Erlang, not this syntax, and each name that it reads becomes an atom. The VM never collects atoms, so a visitor could fill their table and stop the VM. The parser of the envelopes makes no atoms. ### What a shell has and a FIFO does not Redirections need files, and mkfifo.com has only FIFOs. A proposal is in the list of ideas (`2>&1`, and `> fifo` as a write into a named pipe), and for now the FIFO syntax has none. But a person who knows a shell writes `jq . < body.json` from habit, and in an envelope `<` is only a character. Thus the terminal reads `<`, `>`, `;`, `&` and backquotes out of quotes as errors, and the error tells the pipe as the way. A line does not do a different thing with no word about it. ### The home of the terminal A builtin gets the home of its envelope: `totp` puts it in the key of its codes, and `hmac` opens a sealed key only in its own FIFO. First I gave the terminal the FIFO of the editor as its home. Then I saw the problem: the terminal of the locked editor of `/auth` could make the sign-in code of each address, and `hmac` could sign with a sealed key that a person can change but cannot read. Now the home is `@terminal/` and the key of the client address. A FIFO cannot have `@` in its name, so the codes and the seals of a FIFO never open in the terminal. The terminal sends nothing to a FIFO, and `tee` is an error: "Try" sends Requests. Each line has the work of one Request (1024 builtins, 10,000,000 steps), and one address can run 60 lines in a minute. ### On a phone The dialog fills the screen. A phone keyboard hides `|`, `\$` and the quotes, so a row of keys has them, and the earlier lines. iOS does not make `100dvh` smaller when the keyboard opens, so the hook gives the dialog the height of `visualViewport`, and the field stays above the keyboard. Nothing is stored. The variables stay in the process of the page, the earlier lines in the memory of the page, and no line goes to the log. With no JavaScript, the form sends each line, and the variables come back in the form. ## The builtins on the web Each builtin of mkfifo.com is now a web API. `https://mkfifo.com//bin/jq` is `jq`: the body of the Request is its input, and the query gives its words, between `&`. ```sh curl --data-binary '{"items": [1, 2]}' 'https://mkfifo.com//bin/jq?-c&.items' printf 'b\na\n' | curl --data-binary @- https://mkfifo.com//bin/sort curl --data-binary 'echo hello | tr a-z A-Z' https://mkfifo.com//bin/sh ``` ### Two slashes The name of a FIFO has no `/`, so the names with a `/` were free for mkfifo.com. I took the names of a file system: `/bin/NAME` for each builtin, and `/dev/null`, which drops each Request. The address has two slashes: the domain, then the name. Plug drops the empty part between the two slashes, so the router reads the path in two parts. A browser reads the link `href="//bin/jq"` as the host `bin`, so a link of a page has the name only, `/bin/jq`. `GET` of each one is a page with a `curl` command, and the answer that the builtin gives now. An envelope can send to them too: `\$body | /bin/sort`, `tee /dev/null`, and `To: /bin/sh` in an egress envelope. With `Reply-To: -`, the output of the script goes to the client. ### sh and eval `sh` runs a script with the syntax of an envelope, and `eval` runs its words as a script. A line break, `;` and `&&` end a command, `name=WORD` gives a value to a variable, and `body=\$(cat)` keeps the input. `echo` is new too, as `echo` of GNU coreutils. ```sh #!/bin/sh set -eu body=\$(cat) id=\$(\$body | jq .id) echo "order \$id" | tr a-z A-Z ``` Each person can use `eval`, also on the text of a Request. A script has the limits of its Request: 1024 builtins, 64 messages and 8 hops. Its home is `@sh`, not the FIFO of the envelope. No FIFO has `@` in its name, so `totp` and `hmac` cannot use the codes and the sealed keys of the FIFO in a script. The FIFO syntax is not the syntax of a shell in all things. Where a script of a shell would do a different thing here, the shell gives an error: `\$1`, `\$HOME`, `||`, a redirection. A script stops at its first error, as `sh -e`, so `;` and `&&` do the same. The terminal of the editor runs its lines with this shell now. ### The line breaks Most builtins dropped the line break at the end of their output: `jq .id` gave `7`, but `jq` writes `7` and a line break. In an envelope, `\$( )` removes it, so this did not show. In a script, it showed: the lines `jq .id` and `jq -r .name` gave `7Ann Lee`. Now each builtin gives the bytes of its tool, and a value in an envelope still has no line break at its end. The check with the TLA+ models now compares these bytes too. It found one more difference: `sed q` writes a line break after a last line that has none. A test of the bytes found a second one: `wc -l` counted a last line with no line break, but `wc` of GNU counts the line breaks. I fixed both. ## The terminal is the form of /bin/sh The terminal of the editor and `//bin/sh` ran the same shell, but with two sets of rules. The terminal sent nothing to a FIFO, its home was a key of the client address, and it had its own rate limit. A script of `//bin/sh` from `curl` could send to a FIFO, its home was `~`, and it counted as a Request. Thus a line could work in one and fail in the other. Now the terminal is the form of `/bin/sh`, and each line is a Request to it. ### ?form On the page of a FIFO, `?form` opens its form: the letter of "Try". `/bin/sh` is a virtual FIFO, and its form is the terminal: ```sh https://mkfifo.com//bin/sh?form ``` The address shows the page of `/bin/sh` with the terminal open, and the page of `/bin/sh` has a link to it. `?terminal` on the editor goes away. In the editor of each FIFO, Ctrl and the backquote key, or three quick taps on the name of the FIFO, still open the same terminal. ### Each line is a Request A line has what a script of `//bin/sh` has: the home `~`, 1024 builtins, 64 messages and 8 hops. It counts in the rate limit of `/bin/sh`, as a `POST` from `curl`. Thus a pipe to a FIFO, `tee` and a redirection send real Requests now: ```sh order='{"id": 7}' \$order | orders # the answer of the FIFO orders \$order > audit # a Request to audit, with no output jq .id < status # the answer of a GET of the FIFO status ``` In the editor of `orders`, the line `\$order | orders` shows in the list "Requests", as a Request from `curl` does. Before, "Try" was the only way from the editor to send a Request. The terminal does not replace it: "Try" sends the letter of the ingress envelopes, with its fields. ### The variables A Request to `/bin/sh` keeps nothing, but the terminal has variables: `body='{...}'` in one line, and `\$body` in the next one. The form keeps them, and each line runs with them, as if the lines `name='VALUE'` of `set` came before it. With JavaScript, the process of the page keeps them. With no JavaScript, the form has a hidden field for each one, and sends `POST //bin/sh?form`. A `POST` with no valid CSRF token is not a line of the terminal: it is a Request to `/bin/sh` with the word `form`. ### The home The home of the terminal was `@terminal/` and a key of the client address, so that `totp` gave codes that only the terminal of that address accepted. Now it is `~`, the home of `/bin/sh`. A code of the terminal is a code of `//bin/totp` too. No FIFO has `~` in its name, so the codes and the sealed keys of a FIFO still never open in the terminal. ### How One function, `FIFO.env/1`, now makes the environment of a builtin: the home, the time, the sends of a pipe, of `tee` and of the redirections, the work, and one budget of messages. A builtin of an envelope, `//bin/sh` and the terminal use it. The page of the terminal and the editor run the lines with the same code (an `attach_hook` of LiveView), so the two terminals are one. ## gzip and gunzip on the web `gzip` and `gunzip` are builtins now, so they are web APIs too: ```sh printf 'hello\n' | curl --data-binary @- https://mkfifo.com//bin/gzip > hello.gz curl --data-binary @hello.gz https://mkfifo.com//bin/gunzip ``` In an envelope and in the terminal, they work as in a shell: `\$body | gzip | base64`, and `printf hello | gzip | gunzip`. ### The bytes of GNU gzip Erlang has zlib, and zlib comes from the same authors as GNU gzip. With the window bits of zlib for the gzip format, the header is the header that GNU gzip writes for the input of a shell: no name, the time 0, the level of compression, and the system Unix. For `hello` and for each input up to 8 KiB in the tests, the bytes are the bytes of GNU gzip 1.12. For 100 KB of random bytes they are different. GNU gzip reads the bytes of `gzip`, and `gunzip` reads the bytes of GNU gzip, and the tests check both when the computer has GNU gzip. The VM of the Worker, in WebAssembly, has zlib too: in `wrangler dev`, `//bin/gzip` gave the bytes of GNU gzip for `hello`, and the two programs read the 270 KB of each other. ### Where a member ends A gzip file can have more members, one after the other: `(gzip a; gzip b)` is a file, and `gunzip` gives `ab`. For each member, `gunzip` must know where its compressed data end, because the CRC and the length of the data come after them. zlib does not tell it to Erlang: `safeInflate`, which gives the output in small parts, drops the bytes after the end. Also, it says `:finished` when its input ends, not when the data end. Only `inflateEnd` tells if the data ended. So `gunzip` reads the header itself, decompresses the data, and computes the trailer that it expects: the CRC-32 and the length. Then it looks for these 8 bytes in the input. The end is the first place where zlib finds the end of the data, and does not find it one byte before. When no place agrees, a search by halves finds the end, and the bytes there tell the error: a wrong CRC, a wrong length, or an input that ends too soon. The messages are the messages of GNU gzip, for example `gzip: stdin: invalid compressed data--crc error`. ### A small input, a large output 1 MB of zeros becomes about 1 KB of gzip. Thus `gunzip` stops at 1 MiB of output, the limit of each builtin, and zlib gives its output in small parts, so the memory stays small. Each pass of zlib also counts in the steps of the Request, as the matches of `grep` do: a file of thousands of empty members, or data with many copies of their trailer, cannot make a long work. `gzip` counts a step for each byte of its input, so a Request cannot compress its 16 MiB of work at level 9. ### Bytes in a pipe The output of `gzip` is not text. When a pipe gives it to a FIFO, the Request now has `Content-Type: application/octet-stream`, and `//bin/gzip` answers with the same type. The page of `//bin/gzip` shows its answer in hexadecimal. A body line of an ingress envelope does not agree with bytes, as before: a capture of bytes would go to places that expect text, such as the escapes of JSON and the header fields of an email. That needs its own work. ## The shell for an assistant An assistant that speaks the Model Context Protocol (MCP) can use the same shell now. `https://mkfifo.com/mcp` is an MCP endpoint with one tool, `run`: it takes a script, runs it with `eval`, and gives the output. In Claude Code: ```sh claude mcp add --transport http mkfifo https://mkfifo.com/mcp ``` So an assistant can try a `jq` filter on real JSON, compute a `sha256sum`, or send a Request to a FIFO with a pipe and read the answer, with no account and no key. ### A FIFO, not a route The endpoint is not code in the router. It is a FIFO of the site, `mcp`, with seeded envelopes, like `/contact` and `/auth`. Each method of the protocol is one ingress envelope, and so is each error. Selector lines read the JSON-RPC message: `\$.method: ^tools/call\$` and `\$.params.name: ^run\$` pick the envelope, and `\$.params.arguments.script` captures the script. The answer egress writes the reply with `jq`, and the text of the result is `\$(eval \$script 2>&1)`. An error of the script starts with `eval:`, so `isError` is `startswith("eval: ")`. Thus the editor of `/mcp` is the whole server: 27 ingress envelopes and their answers. Anyone can read them, and nobody can change them. A test sends a request to each one, and checks that exactly one envelope agrees with each request. ### Two versions of the protocol The version 2026-07-28 of MCP has no session and no `initialize`. Each request tells its version and the capabilities of the client in `_meta`, and it repeats the method and the name of the tool in the header fields `Mcp-Method` and `Mcp-Name`, so that a proxy can route it without the body. That fits a FIFO well. An envelope examines a header field and a JSON value in the same way, and a capture of one can go in the pattern of the other: the envelope of a header field that does not match the body has lines like `Mcp-Method: ^(?<header_method>.*)\$` and `\$.method: ^(?!\$header_method\$).+\$`. Many clients still speak the older versions, which start with `initialize`. The endpoint takes them too: one envelope answers `initialize`, and `tools/list`, `tools/call` and `ping` have a second envelope with no rules for `_meta`. A request with no version header is of version 2025-03-26, as the protocol says. I checked the official TypeScript SDK in four ways: the client of version 2 pinned to 2026-07-28, the same client in its automatic mode, its default mode (the older versions), and the client of version 1. A browser sends `Origin` with a request from a page. The endpoint answers `403` to each origin that is not mkfifo.com, so a page of a different site cannot use the tool from the browser of its visitor. ### A GET that takes no HTML A client of the older versions can open a stream with a `GET` and `Accept: text/event-stream`. The endpoint has no stream, so the protocol asks for `405`. But `GET /mcp` is the editor of the FIFO, and the editor is HTML: Phoenix answered `406` before an envelope could see the request. Now a `GET` that takes no HTML is a Request when an envelope of the FIFO agrees with it, as the `GET` of a held FIFO. It still gets `406` when no envelope agrees. A browser takes HTML, so a link still opens the editor. And the rule gives an envelope no request that it could not get before: `POST /NAME?_method=GET` already agreed with each envelope for a `GET`. ### The limit of the site The FIFOs of the site have a low rate limit, 20 Requests in 10 minutes from one address, because they are letters to the team. An assistant sends a few requests for each step, so my first test with a real client hit that limit in a few minutes. A Request to `mcp` now counts only in the limit of its own name, as `/bin/sh` does: 120 in one minute.

Show the body Show the header

Egress envelopes of ingress envelope 16

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-706f-8327-ffd736fe800d@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

A builtin has the name and the options of a tool of the shell, so it must do what that tool does. TLA+ models write the cases, and the real tools give the answers. Then the pipes, the quotes and the redirections of an envelope learned to work as in a shell. ## grep, sed, sort, uniq, xargs and jq, checked against the shell Six more builtins: `grep`, `sed`, `sort`, `uniq`, `xargs` and `jq`. A builtin has the name and the options of a tool of the shell, so it must do what that tool does. "Almost the same" is a trap: you copy a command from a terminal into an envelope, and it gives a different line. Thus I did not write tests from my memory of these tools. TLC writes the cases, and the real tools give the answers. ### TLC writes the cases Each builtin has a TLA+ model, `specs/ShellNAME.tla`: what the tool does, from its source. For `sed`, the model follows `match_address_p` and `do_subst` of `execute.c`. For `grep -w`, it follows `EGexecute`. For `jq`, it follows the order in which jq 1.7 gives its outputs. A state of a model is one case: a command, an input and the output of the model. TLC checks the invariants and writes all the states to a file. Then `scripts/builtins.sh` gives each case to the tool of the shell and to the builtin. The three outputs must be the same. | Model | Cases | |---|---| | `ShellSort` | 26,316 | | `ShellUniq` | 11,466 | | `ShellGrep` | 26,558 | | `ShellSed` | 15,222 | | `ShellXargs` | 15,159 | | `ShellJQ` | 41,897 | The first version put the output in `Init`. TLC computes `Init` on one core, and the run took a long time. Now `Init` picks a case with an empty output, and `Next` computes it, so all the workers of TLC share the work. All six models take about 5 minutes. The CI runs them with the same versions of the tools: GNU coreutils 9.4, grep 3.11, sed 4.9, findutils 4.9.0 and jq 1.7. ### The longest match PCRE gives the first match in the order of the pattern. POSIX gives the longest one at the leftmost position. For `a|ab` and the text `ab`, PCRE gives `a`, and `grep -o` gives `ab`. For a pattern with no `|` and no repeat of a group, the first match of PCRE is also the longest one: a check of 25,344 patterns and 62 texts found no difference. For the other patterns, `FIFO.Builtin.Regex` has an NFA. My first NFA gave each step to `:re.run`, with the text and an offset. It was slow on a long line: `sed -E 's/(a|b)+/X/g'` on 300 KB took 17 seconds. `:re.run` checks the UTF-8 of all the text after the offset at each call, about 300 µs for 300 KB, so many matches on one line cost the square of its length. Now `:re.run` gets one character for an atom, and the characters before and after a position for `^` or `\b`. PCRE still finds the start of each match fast, and the NFA runs only from that start. When PCRE has read the text 4 times, the NFA searches alone. The same `sed` now takes about 0.6 seconds. The NFA also changed a limit. `(a+)+\$` on 40 `a` and a `c` was an error before: PCRE tries too many paths. The NFA walks each character one time, so `sed` now gives the correct output, and `grep` tries the NFA when PCRE gives up. ### A budget for the work Each character costs the NFA at most its number of states. My first budget was 1,000,000 steps for one line. Then I saw the problem: a pattern with many states, on many short lines, stays under the budget on each line, and the input has 1 MiB of lines. Now a run of `grep` or `sed` has 5,000,000 steps for all its lines, and the steps of `grep`, `sed` and `jq` also count in the work of the Request: 10,000,000 in all. A Request runs at most 1024 builtins, so a budget only for one run was not sufficient. The count also missed work at first: `(a?){300}b` on 5000 characters took 15 seconds before the error, because the steps did not count the closures of the states. Now the states of one character share one walk, each state that it reaches is a step, and the same pattern stops after about 2 seconds. ### What a random comparison found The models cover small inputs, so I also compared the builtins with GNU on random patterns: more than 20,000 cases of `grep -o`, `-ow` and `-ox`, and 30,000 cases of `sed s`. Each difference went into a model or into a test, and the models still agree with the tools. - **`grep -o -w` after the first match.** To try a shorter match, `EGexecute` gives `re_match` the length `match + len - ptr`. That is the length from the start of the line minus the start of the search. At the first search of a line the two are equal. After a match, a shorter match must end that many bytes earlier. Thus GNU gives `a` for `a.a.b` with `grep -ow 'a\.*'`, and my builtin gave `a` two times. The builtin now has the same loop, and the model too. - **The groups of `\{m,n\}`.** `s/$a*$\{0,2\}b/[\1]/` on `aab` gives `[]` in GNU, not `[aa]`. glibc builds `x{0,2}` as `(x? x)?`, so two repeats use the second copy last. Only the first optional copy is marked as optional, because `create_token_tree` clears that mark in each copy. And `update_regs` puts back the groups of the last part that was not empty only for an optional copy. I compiled the regex code of gnulib with traces to see this. The NFA now has the shape of the tree of glibc and walks it as `set_regs` does, and `ShellSed` has the same rule for intervals. - **`^^` in a BRE** is the anchor and the character `^`. - **`xargs echo -e`**: the options of GNU xargs end at the command, so `-e` goes to `echo`. Mine read it as an option of `xargs`. I did not copy two things of glibc. `grep -o 'a*$a\|b $\>'` finds `b ` in `a b `, but `\>` cannot match after a space, and the same pattern with no `a*` does not find it. And with `\b` between two parts that can take the same characters, glibc gives the characters to the second part. The match is the same; only the groups change. To copy this, I would need the DFA of glibc. ### jq 1.7, not the jq that I remembered Ubuntu 24.04 has jq 1.7.1. The CI installs the release binary of jq 1.7, and my first runs used 1.7.1, so I compared with the binary of the CI too. Most differences were not between these two versions: my error messages came from a newer jq. `[] | .a` gives `Cannot index array with string "a"` in jq 1.7, and `1 % 0` says "divided (remainder)". A filter can catch such a message with `try ... catch .`, so it must be the same text. The functions that jq 1.7 writes in jq (`src/builtin.jq`, for example `join`, `sub` and `reverse`) now have the same text in the builtin, so they give the same outputs and errors: `"abc" | reverse` is an error in jq 1.7. Numbers were the largest surprise. jq 1.7 keeps the text of a number of the input while no operation changes it, in the form of decNumber: `{"price": 1.50} | .price` gives `1.50`, `1.0` stays `1.0`, `3e2` becomes `3E+2`, and `100000000000000000001` keeps all its digits. Mine gave `1.5`, `1` and `300`. The JSON module of OTP already gives the text of each number to its callbacks, so the builtin keeps it there, and arithmetic uses the float. Two such numbers compare as decimals: `1.000000000000000000001 == 1` is false. The grammar also had two traps. `as \$x` belongs to a term, so `.a + 1 as \$x | \$x` is `.a + (1 as \$x | \$x)`; my parser refused it. And `-.` or `-1` is a filter, not an option: jq takes a word as an option only when a letter or a `-` comes after its `-`. The value of an object pair is smaller than a filter in jq 1.7, so `{a: 1 + 1}` is an error there, and now here too. `ShellJQ` now has numbers with their text, and it found no difference after these changes. ### Smaller fixes - The coverage of the tests found that `grep -F` dropped the bytes that are not UTF-8 from its pattern. - `sed 's/a/\xff/'` puts a byte that is not UTF-8 into a line. The next command still matched by characters, and the match raised an exception. Now each line selects its matcher. - The output of each builtin, but `cat`, now has no line breaks at its end, as `\$( )` of a shell. Before, only `head`, `tail` and `cut` removed the last one. `xargs` keeps them between its runs, as a pipe of a shell does. ## Pipes, as in a shell In a shell, `printf 'a\n' | wc -l` gives `1`. In an envelope of mkfifo.com, it gave `0`. Each value between two commands lost the line breaks at its end, so `wc -l` did not see the line break of `printf`. A script of `sh` gave `1`, because the shell keeps the bytes of each command. Thus the same command gave two different numbers, in two places of the same site. Now an envelope does what a shell does. A pipe gives the bytes of a command to the next command, with the line breaks at their end. Only the value has no line breaks at its end: the value of `\$( )`, and the text that a pipe puts in the envelope, as `\$( )` of a shell gives it. ```sh # The body: {"items": [1, 2, 3]} \$body | jq '.items[]' | wc -l ``` Before, this gave `2`: `jq` writes `1`, `2` and `3` on three lines, but the pipe removed the last line break, and `wc` counts the line breaks. Now it gives `3`, as in a terminal. ### How The function that runs a command gets one more argument: does its output go to a pipe? `FIFO.Template` gives "yes" to each command before a `|`, and "no" to the last one. A builtin then gives the bytes of its tool, or its value with no line breaks at its end. The answer of a FIFO in a pipe is the same: the next command gets its body as it is. The shell asks for "yes" for the last command too, because a script writes its output as it is. Thus the shell and the envelopes now use the same code for a pipe. The shell had its own code for it before, and that was why the two did not agree. `cat` gives its input with no change in all places, because it gives the bytes of a file, as the fonts of this site. ### The home is ~ A script of `sh` and `eval`, and each builtin of `/bin`, runs with a home that is not a FIFO, so that `totp` gives no code of a FIFO there, and `hmac` opens no sealed key of a FIFO. That home was `@sh`. Now it is `~`, the home of a shell. The name of a FIFO has only `a` to `z`, `0` to `9`, `-`, `_` and `.`, so no FIFO has `~` in its name, and the home stays a home of no FIFO. ## Backslashes in double quotes In a shell, a backslash in double quotes keeps the next character only before `\$`, `` ` ``, `"` and a second backslash. Before a different character, the backslash stays. Thus `"a\\b"` is `a\b`, and `"a\b"` is `a\b` too. The words of the FIFO syntax had only two of these escapes: `\"` and `\\$`. So `"a\\b"` stayed `a\\b`. That looks small, but it changed commands that you copy from a terminal: ```sh \$body | sed "s/\\./,/g" ``` In a shell, sed gets `s/\./,/g` and changes each dot. Here, sed got `s/\\./,/g`: a backslash, then any character. Now the words of an envelope, of `sh` and of the terminal have the four escapes of a shell, and this command does the same thing in all of them. The shell of mkfifo.com finds the end of each command before it reads the words. Its splitter has the same rule now, so both agree on where a text in double quotes ends: in `"a\\" b`, the quote ends after `a\`. `set` also writes `\` and `` ` `` with a backslash in double quotes, so that each line that it shows gives the same value when you run it again. ## Redirections: a FIFO is a named pipe On Unix, `mkfifo my_pipe` makes a named pipe, and a command writes into it with `>`, as into a file. mkfifo.com has its name from that pipe, but its syntax had no `<` and no `>`. The shell and the terminal gave an error for each redirection, so that a command from a terminal did not do a different thing here with no word about it. Now they work, in the envelopes, in `sh` and in the terminal: ```sh \$(wc -l < prices) # the answer of a GET of the FIFO prices \$(printf '%s\n' \$id > audit) # a Request to audit, with no output \$(\$body | jq -r .id 2>/dev/null) # empty when jq fails \$(jq .id 2>&1) # the error as the value ``` ### What each one does - `> fifo` sends the output to the FIFO as the body of a Request, as `tee` does, and the command gives no output. A FIFO keeps nothing that a second write could replace, so `>>` does the same as `>`. - `< fifo` gives the command the answer of a `GET` of the FIFO. Only an envelope with a line `X-HTTP-Method-Override` agrees with a `GET`, so a FIFO tells which envelopes a reader can read. - `2> fifo` sends the error to the FIFO, as `Errors-To` does for an egress envelope. `2>&1` makes the error the output. - `/dev/null` takes the output and the error, and gives an empty input. It sends no Request. They act from the left to the right, as in a shell. In `> log 2>&1`, the error goes to `log`. In `2>&1 > log`, the error goes where the output was at that time: into the value. ### An error that moves does not stop the line In an envelope, a command that fails stops the egress. There is no `||` to go on after it. Now `2>/dev/null` is the way: an error that a redirection moves to a FIFO, to `/dev/null` or to the value is not a failure. An error of the redirection itself, for example a FIFO with no ingress envelope, still stops the line. ### Names in the text A target is the name of a FIFO, with no variable. Thus the graph knows each FIFO that an envelope reads or writes, as it knows the FIFOs of `tee`, and the save refuses a loop: an envelope of `ping` with `> pong`, and an envelope of `pong` with `< ping`, get `422`. ### `<` and `>` in a word In a shell, `<` and `>` out of quotes end a word: `printf a>log` writes `a` into `log`. The words of an envelope do the same now. One thing changed with it: out of `\$( )`, the words of a pipe go to the end of the line, so `<td>\$x | tr a-z A-Z</td>` reads a FIFO `/td`, and the save refuses it. The pipe goes in `\$( )`: `<td>\$(\$x | tr a-z A-Z)</td>`. A sealed word, `<seal:KEY>`, stays a word. ### The function that runs a command A pipe gives the function that runs a command a name, its words, its input, and the flag for the line breaks at the end of its output. The redirections use the same function, with two more names: `{:read, fifo}` for `<`, and `{:write, fifo}` for `>`. For an envelope, these are `FIFO.read/2`, a new `GET` with the hops and the messages of the Request, and `FIFO.send/3`, which `tee` uses. For the terminal, they give an error, as a pipe to a FIFO does: the terminal sends nothing. `/dev/null` never goes to the function.

Show the body Show the header

Egress envelopes of ingress envelope 17

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7076-a781-182543f7b2bd@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

All the icons of mkfifo.com come from one SVG in an envelope, through the builtin `resvg`. Cloudflare Images made the other sizes for one day, and then a cache in front of the Worker took its place. ## favicon.ico is a FIFO Until today, `/favicon.ico` and `/robots.txt` were the files that Phoenix makes for a new project: the icon of Phoenix, and a `robots.txt` with only comments. Now both are FIFOs of the site, as `/fonts`: the FIFO `mkfifo` holds them, and their answers come from envelopes in `priv/repo/seeds/mkfifo/`. `GET /mkfifo` shows them in a locked editor. ### The icons I followed "How to Favicon" of Evil Martians, and looked at what changed after its version of 2021. The ICO link now has `sizes="32x32"`, not `sizes="any"`, because of a bug of Chrome (2023). A maskable icon came for the web apps that a person installs (2024). Safari 26 shows SVG icons. Google wants a square icon that its crawler can read, and asks for more than 48 pixels. The icon is an ingress envelope of the editor: brown paper, the flap, and a blue stamp. `scripts/icon.svg` is the source, and `scripts/icons.mjs` makes the files: Chromium draws the SVG at 16, 32, 48 and 180 pixels, and the script writes the ICO file itself. An ICO file is a header of 6 bytes, an entry of 16 bytes for each image, and the images, which can be PNG files. ```envelope To: favicon.ico X-HTTP-Method-Override: ^GET\$ Content-Type: form file: ^\$ ``` ```envelope To: - Content-Type: image/x-icon Cache-Control: public, max-age=86400 \$(cat icons/favicon.ico) ``` A second envelope takes `?file=NAME.png` and gives the icon of 180 pixels for the home screen of iOS. Each page links it with a version, `?file=apple-touch-icon.png&v=...`, so a browser keeps it for one year. There is no SVG icon. My plan had one, with `cat icons/icon.svg`. But `image/svg+xml` is XML, and an answer with an XML body gives each value the escapes of HTML: `<svg` becomes `<svg`. That rule stops a capture from adding a tag to a page, and a FIFO of the site gets no exception from it. The ICO file has images for 16, 32 and 48 pixels, which is sufficient for a tab. There is also no web manifest: mkfifo.com is not an app to install. ### A dynamic robots.txt A FIFO can give a different answer to a different Request. `robots.txt` has two envelopes, one for each value of `Host`: ```envelope To: robots.txt X-HTTP-Method-Override: ^GET\$ Host: ^(mkfifo\.com)?\$ ``` For mkfifo.com (or a Request with no `Host`), the answer lets each search engine read the site, and gives the feed of this blog as a sitemap. For each different host, for example a preview of the Worker or `localhost`, the answer is `Disallow: /`, so that a copy of the site does not go into a search engine. A test on `localhost:4000` got `Disallow: /`, so the field `Host` of the server comes into the Request. ### Not the editors The name of a FIFO is the key to change it. `robots.txt` cannot list the editors, because each name of a FIFO is a path of the root. So the editor of each FIFO now has `<meta name="robots" content="noindex">`: if a person puts a link to an editor on a public page, a search engine does not keep it. A rule of `robots.txt` would not be sufficient: a search engine can keep a URL that it cannot read. `apple-touch-icon.png`, `apple-touch-icon-precomposed.png` and `sitemap.xml` are names of the site now. Some clients ask for them at the root of a site, so a FIFO of a person must not have these names. ## One SVG, all the icons "How to Favicon" of Evil Martians starts from one SVG, and makes the other icons from it. My first FIFO `favicon.ico` did not: a script drew the SVG in Chromium on my computer, and the FIFO gave two files from `priv/icons/`. There was no SVG icon. Now the SVG is the text of an envelope, and each icon comes from it when a browser asks for it. | Request | Answer | | --- | --- | | `/favicon.svg` | the SVG: the text of the answer envelope of the FIFO `favicon.svg` | | `/cdn-cgi/image/width=192/favicon.svg` | a PNG of 192 pixels, from Cloudflare Images | | `/favicon.ico` | `\$(printf '\0\0\1\0\1\0\40\40\0\0\1\0\40\0\337\2\0\0\26\0\0\0')\$(resvg -w 32 - -c < favicon.svg)` | | `/favicon.ico?file=apple-touch-icon.png` | `\$(sed 's/viewBox="0 0 32 32"/viewBox="-4.5 -4.5 41 41"/' < favicon.svg \| resvg -w 180 --background '#dde2ea' - -c)` | `< favicon.svg` is the answer of a `GET` of the FIFO `favicon.svg`. The icon of iOS needs space around the envelope and no transparency: `sed` makes the view box larger, and `--background` gives the color of the desk. ### Two FIFOs My first plan had one FIFO: the SVG in one answer envelope, and the other envelopes read it from the same FIFO. That cannot work. A FIFO that reads itself is a loop, and the save refuses a loop. Then I put the SVG into a file of the site, and `cat` gave it as markup, because an answer of `image/svg+xml` gives each value the escapes of HTML. That was an exception to a rule of safety, for one file. Two FIFOs are better. The SVG is the text of the envelope of `favicon.svg`, and the text of an envelope gets no escapes: only the values do. `favicon.ico` reads a different FIFO, so there is no loop. A FIFO that holds a FIFO cannot be held, so the FIFO `mkfifo` of the site holds both, as it holds `fonts` and `robots.txt`. ### A converter in the Worker The site runs in a Cloudflare Worker, so the converter must run there too. I looked at three: - **ImageMagick.** A Worker runs no program. - **image_plug, on Vix and libvips**, in the VM. A NIF in the Worker is WebAssembly, with WASI preview 1 and no threads. libvips needs GLib, and GLib needs threads. - **Cloudflare Images.** It gives an SVG back as it is, with no PNG. resvg is Rust, with no C libraries. Its crate compiles to `wasm32-wasip1`, so it can be a NIF in WebAssembly, as the NIF of lazy_html. beam.com has a change for rustler 0.38 that makes the `enif_*` functions imports of WebAssembly. With Rust 1.97 it needed one more line, `#[link(wasm_import_module = "env")]`: the linker of Rust for WebAssembly does not accept an unknown function now. The module also exports its `malloc` and `free` for the VM. The file is 1 MB, and the build puts it into `nifs.js` with lazy_html. The builtin `resvg` has the name and the options of the program: `-w`, `-h`, `-z`, `--dpi`, `--background`, and `- -c` for the input and the output. It gives the bytes of the program resvg 0.48.1. I compared 13 cases, with gradients, a clip path, a mask, dashes, `<use>` and the unit `mm`: the bytes were the same. The tests keep the SHA-256 of four of them. The NIF is in the repository as `priv/resvg.wasm`, and the CI builds it again from `native/resvg` and compares the bytes: the build gives the same file on each computer. ### Cloudflare Images in front With the transformations of Cloudflare Images on, `/cdn-cgi/image/OPTIONS/SOURCE` changes the size and the format of an image of the site. Cloudflare gets the source from the Worker. To see that `GET`, I saved a test FIFO that agreed only with `Via: image-resizing`, and answered with a PNG of one pixel. A direct `GET` got `404`, and the URL of Cloudflare got the PNG: the field is there, and the VM sees it. So now an answer of `image/svg+xml` to such a Request is the PNG of the SVG, at most 512 by 512 pixels, from `resvg`. Cloudflare makes each size and format from that PNG. To the outside, an image of an SVG is only the path of Cloudflare, and each FIFO with an answer of SVG gets it, not only the icons. Two things stay with `favicon.ico`. Cloudflare makes no ICO files. And it has no `format=png`: it selects JPEG or PNG itself, and for the icon of iOS, which has no transparency, it gave a JPEG. iOS wants a PNG there. ### An SVG from anyone Any FIFO can give an SVG to `resvg`, and a call of a NIF cannot stop before it ends. So the NIF examines the SVG before it draws, and refuses each thing that can use much memory or much time: the entities of a DTD (they can copy text a billion times), more than 128 levels of elements, more than 20,000 elements or 2 MiB of attributes after the copies of `<use>`, a mask or a clip path on each element through a style sheet, an image of more than 1,048,576 pixels, and more than 16 MiB of pixmaps. A layer of resvg can be 25 times the image, so the NIF computes the box of each layer. It also refuses text, images, filters, patterns and markers: the NIF has no fonts and no files, and these are the slowest parts. The steps of the work count in the steps of the Request, as the matches of `grep`: the pixels of the image and of its PNG, of each layer, of the box of each path, the rows of each edge, and each dash. The NIF gets the steps that the Request has, and refuses a larger work before it draws. I gave each part its weight from measures: a stroke costs about four times a fill, and a gradient ten times a color. In `wrangler dev`, the PNG of 512 pixels takes 160 ms with the HTTP request, the largest work that a Request can do takes 0.23 s, and an SVG with a billion copies gets its error in 22 ms. The memory of the NIF stayed under 15 MiB after the largest work, and a test keeps it under 32 MiB. ### The ICO file An ICO file is a header of 22 bytes for one image, then the image, and the image can be a PNG. `printf` gives the header: the type 1 and one image (`\0\0\1\0\1\0`), 32 by 32 pixels (`\40\40`), one plane of 32 bits, the length of the PNG, and its position, 22. `printf` had only `\n`, `\t`, `\r` and the quotes. Now it has `\NNN` and `\xHH`, as GNU printf, in the same pass as the conversions: `\045d` gives `%d`, not a number. The length is fixed in the envelope: 735 bytes, `\337\2\0\0`. resvg gives the same bytes for the same SVG, so the length changes only with the SVG, and a test tells the new value. The ICO file now has one image, of 32 pixels: the article recommends it, and the SVG is the icon of the browsers that read SVG. ### Two bugs of grep While I worked on this, the property test of the builtins failed one time: it runs each builtin with random words and inputs, and expects no exception. I ran it on `grep` for many more inputs, and found two bugs. A pattern of more lines with a character that is not UTF-8, as the bytes `E1 0A`, raised an exception: each character of such a pattern was compiled also as UTF-8. And an error message with a word that is not UTF-8 raised one in `String.length/1`. Now that pattern matches by bytes, as GNU grep does, and each byte of an error that is not UTF-8 becomes U+FFFD. ## A cache in front of the Worker Yesterday the other sizes of the icon came from Cloudflare Images, at `/cdn-cgi/image/OPTIONS/favicon.svg`. Today the transformations are off, and a cache of Cloudflare is in front of the Worker. The images of other sizes will come from the VM, and the cache will keep them. ### A transformation counts when it fails Cloudflare counts each new pair of a source and options as one transformation of the month. I wanted a limit for each FIFO, so I looked at what the VM sees. For the first size of a source, Cloudflare sends one `GET` to the FIFO. For each new size after it, Cloudflare sends nothing: it uses a copy of the source in its memory, also with `Cache-Control: no-store`. The `GET` has no options. So the VM cannot count the transformations. Then I sent 20 URLs with a source that was not there, each with a different width. Each one failed with the error 9408, and the count of the month went from 22 to 42. A failed transformation counts too. So each person could use the transformations of the month with any URL, and a refusal of the VM could not stop it. I turned the transformations off. A rule of the firewall of Cloudflare with a secret header could let only the VM through. But then the secret is in two places, and the site can run only on Cloudflare. ### `/cdn-cgi/` is for Cloudflare With the transformations off, I wanted the VM to answer `/cdn-cgi/image/` itself, with the same options. Then the URL stays, and only the work changes. It cannot: Cloudflare gives its own `404` page for each path of `/cdn-cgi/`, also for `/cdn-cgi/mkfifo-test`, and the Worker never gets the request. The images will have a path of mkfifo.com. ### The cache Workers Cache is one line in `wrangler.jsonc`: `"cache": { "enabled": true }`. Cloudflare looks in its cache before it runs the Worker, and the `Cache-Control` of the answer controls it. A copy does not run the Worker or the VM: it uses no CPU, and the rate limits do not see it. The header `cf-cache-status` tells `MISS` or `HIT`. The `cf` options of `fetch()` do not help here: they are for a request that a Worker sends to an origin, and this Worker sends to a Durable Object. And `wrangler dev` does not have the cache: with the line, two `GET`s of `robots.txt` both came to the VM. So the test of the cache is on mkfifo.com. ### The key has no host The key of the cache is the path and the query. It has no host and no header field of the Request. Three answers changed for this: - `robots.txt` has a different text for a host that is not mkfifo.com, for example a preview of the Worker. With `public`, a preview could put its `Disallow: /` into the copy of mkfifo.com. Now the two answers have `private, max-age=86400`: only the browser keeps them. - The Worker makes some answers itself: `429`, `503`, `413`, and each answer of `sendmail.mkfifo.com`. They had no `Cache-Control`. Now they have `no-store`. - The PNG for a Request with `image-resizing` in `Via`: a client with this field could put the PNG into the copy of `/favicon.svg`. The transformations are off, so I removed the rule. An answer of a FIFO with `public` goes into the cache too. A `GET` in that time does not come to the FIFO: the editor shows no Request, and the egress envelopes send nothing. An answer with no `Cache-Control` gets `max-age=0, private, must-revalidate` from Phoenix, so the cache does not keep it. An answer that changes with a header field of the Request must be `private`.

Show the body Show the header

Egress envelopes of ingress envelope 18

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-707d-9f58-4b7f5d6919d1@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

Four changes to the pages in one evening: a field behind an envelope that a link brings to the front, an image for links, a dark mode, and a test of accessibility at each push. ## The field behind An envelope in the editor has two sides in one cell of a CSS grid: the face with the header fields, and the letter with the body. One is in front, and the other is behind it and invisible. A switch changes them, with CSS only. When a save fails, a summary at the top of the page has a link to each field with an error. A link to a field on the side behind went to a field that did not show. ### With no JavaScript A link to `#KEY-body` makes the field of the body the `:target` of the page. CSS can see it: `article:has([data-side="letter"] :target)`. So the side with the target can come to the front. But the switch must still work after that. If the target always puts its side in front, the switch does nothing while the address has the target. CSS has no memory, so the state must come from what the page has now: the switch, its `checked` attribute, and the target. The `checked` attribute is the state of the render, when the server made the page, and the `:checked` state is the switch now. A target in the side that was behind at the render changes the places of the two sides, and the switch changes them again: ```css @custom-variant letter-front { article:is( :has(> * > [role="switch"]:not([checked]):checked):not(:has(> * > [data-side="letter"] :target)), :has(> * > [role="switch"]:not([checked]):not(:checked)):has(> * > [data-side="letter"] :target), :has(> * > [role="switch"][checked]:checked):not(:has(> * > [data-side="face"] :target)), :has(> * > [role="switch"][checked]:not(:checked)):has(> * > [data-side="face"] :target) ) & { @slot; } } ``` The face, the letter and the button "Open the letter" use the variant `letter-front:` of Tailwind. A link to the body brings the letter to the front, a link to a header field brings the face back, and the switch works between them. ### With JavaScript LiveView sends the state of the switch to the server, and the server renders the `checked` attribute again. Then the state of the render changes, and a target in the address could move the sides at the wrong time. So with JavaScript, the link does not change the address. A click on a link of the summary turns the switch when the field is behind. The server then knows that the letter is in front. The field gets the focus when its side shows, after the movement of 0.2 seconds. ### A checkbox of a seal The button "Open the letter" had the classes `group-has-checked/env:hidden` and `group-has-checked/env:inline`: the text changed when the envelope had a checked element. But the switch is not the only checkbox in an envelope. Each header field has a lock, a checkbox that seals its value. In a browser, an envelope with a checked lock matched `:has(:checked)`, and the button said "Close the letter" while the letter was behind. The new variant reads the switch only. ## An image for links A link to mkfifo.com in a chat or on a social site showed only a title and a description. Now it also shows [an image](/images/og.png): the title of the home page, and the example pipe of the home page, with the ingress envelope, the pipe and the egress envelope. ### A screenshot of the site I did not draw the image again. `scripts/og-image.mjs` opens the home page of a running server in Chromium, takes the figure of the pipe, and puts it in a page of 1200 x 630 pixels with the styles and the fonts of the site. Then it makes a screenshot into `priv/static/images/og.png`. When the envelopes change, the script makes a new image from them. The first version of the script used Tailwind classes for the parts around the figure, such as `text-[64px]`. They did nothing: the CSS of the site has only the classes that the site uses. The figure has its classes from the page, and the parts around it have their own small style sheet. The image is a PNG, not an SVG: the sites that show a preview of a link read PNG and JPEG, but not SVG. ### The tags The home page and the posts of this blog have these tags now, with the title and the description: ```html <meta property="og:image" content="https://mkfifo.com/images/og-....png" /> <meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" /> <meta property="og:image:alt" content="mkfifo.com: named pipes for ..." /> <meta name="twitter:card" content="summary_large_image" /> ``` The URL is absolute, because a site that reads the tags does not know the page that it came from. Phoenix adds a hash of the file to its name, so a new image gets a new URL, and a site that keeps the old image in its cache gets the new one. ## Dark mode, with paper on the desk mkfifo.com now follows the dark mode of the system. The page is a desk: in the dark mode, the desk, the panels and the text change. The envelopes and the letters do not. They are paper, so they keep their brown, white and airmail colors, and their dark text, as a real envelope on a dark desk. ### The roles of a color The colors of the site are tokens of Tailwind, and a token is a custom property of CSS. So the dark mode is one block: `@media (prefers-color-scheme: dark)` gives the tokens new values, and each utility follows. The paper is a second block: `.envelope-kraft`, `.envelope-airmail`, `.ruled` and `.bg-paper` set the tokens back to the values of the light mode, so each element on the paper keeps them. That was the plan. The work was in the names. `ink` was the color of the text, and also the background of the header, of the code blocks and of the terminal. In the dark mode the text becomes light, but the header must not. Each use needed its role: | Token | Light | Dark | Role | | --- | --- | --- | --- | | `ink` | `#15171c` | `#e8ebf0` | the text, and the filled buttons that are on | | `night` | `#15171c` | `#08090b` | the surfaces that stay dark: the header, the code, the terminal | | `contrast` | `#ffffff` | `#121418` | the text on a filled `ink`, `link` or `error` | | `surface` | `#ffffff` | `#1c1f26` | a panel or a field (it was `bg-white`) | | `soft` | `#374151` | `#c4cbd6` | the second color of text (it was 43 copies of `text-[#374151]`) | A blue button keeps white text in the light mode. In the dark mode, the blue of the links is light (`#8db4ff`), and white text on it has a contrast of 2.1:1. With `text-contrast`, the text of the button is the color of the desk: 8.9:1. ### What the screenshots found I made screenshots of each page in Chromium with `colorScheme: "dark"`. They found three places that the plan did not have. The backdrop of a modal dialog was `bg-ink/50`: in the dark mode, a light gray veil on the page. It is `bg-night/50` now. The six cards of "What can a FIFO do?" on the home page are paper (`bg-paper`) with text of the desk, so their text was light on white: `.bg-paper` is paper now. And the white button on the dark panel at the end of the home page became dark: it has the class `paper`. FIFO Code, the font with the colors of a syntax, has two palettes. A field on an envelope uses the light palette, and a code block of the blog the dark one. A value on a panel of the desk needs the light palette in the light mode and the dark palette in the dark mode, so the palette is a custom property too: `font-palette: var(--code-palette)`, `dark` on the desk and `normal` on paper. ### A test of the colors `test/mkfifo/colors_test.exs` reads `app.css`. It checks that the paper sets back each color that the dark mode changes, to its value of the light mode, and it computes the contrast of WCAG for each color of text on its backgrounds, in the two modes. In the dark mode the lowest is 6:1, for the label of the pipe. In the light mode it is 4.8:1, for the green of a successful egress on its pale green. The test fails at less than 4.5:1. ## axe on each page The pages of mkfifo.com work with a keyboard and with no JavaScript, and I checked that by hand. Now a test checks them with axe-core 4.13, in Chromium, at each push: 13 pages (the home page, an editor with envelopes, the letter of "Try", the locked editors of `/contact`, `/auth` and `/mkfifo`, the docs, the blog, a post, the templates, `//bin/jq` and the terminal), each in 8 modes: light and dark, 1280 and 390 pixels wide, with and without the JavaScript of the site. A violation of WCAG 2.2 A or AA, or of a best practice of axe, fails the test. ### What axe found Three problems, in all the modes: - **Links only in a color.** A link in a paragraph had the blue of the links and no line under it. Against the text around it, that blue has a contrast of 2.25:1, and WCAG asks for 3:1 when the color alone shows a link. Now a link in a paragraph, a list, a table or a caption has a line under it. The links of the header and the footer are menus, and the buttons are buttons: they have none. - **Code that scrolls.** A block of code that is wider than the page scrolls to the side, but a keyboard could not go into it to scroll. Each such block now takes the focus (`tabindex="0"`): the examples of the home page and of `/docs`, the pages of `//bin`, and the code blocks of the blog. - **Small targets on a phone.** At 390 pixels, the links of the footer go on two lines, and each one was 22.5 pixels high, close to the next one. WCAG 2.2 asks for 24 pixels, or space around the target. Each link now has 4 pixels above and below it. The dark mode had no problem of its own: the test of the colors had already checked its contrast. ### How the test runs `test/mkfifo/a11y_test.exs` has the tag `a11y`, so `mix test` does not run it. With `MKFIFO_A11Y=1`, the server of the tests starts, and the test seeds the FIFOs of the site and an example FIFO. Then `scripts/a11y.mjs` opens each page in Chromium, waits for LiveView, puts axe into the page, and prints each violation. The CI uses the Chrome of the runner. Three things did not work at first: - With `javaScriptEnabled: false`, Playwright cannot run a script in the page, also not axe. So a page "with no JavaScript" is a page whose `app.js` the browser does not load: it stays the HTML of the server, and axe still runs. - On my computer, the first run found 178 violations, most of them colors of the light mode in the dark mode. The server of the tests sent an old `app.css.gz`: `Plug.Static` sends the compressed copy when there is one, and an old `phx.digest` had left it in `priv/static/`. The CI starts from a clean copy. I deleted the old files, and noted it for the next person. - The database of the tests is a sandbox, and the browser comes from the processes of the server. A shared owner of the sandbox gives them its connection, but only for 2 minutes, and the run takes about 4. The test now keeps the owner for 15 minutes.

Show the body Show the header

Egress envelopes of ingress envelope 19

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7084-b712-0592f3ea5675@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

The icons and the images of the site always came with `200`, also when the browser had them already. The answers had `Cache-Control: public, max-age=86400`, but no `ETag`. When the browser asked again, for example when a person loaded the page again, it had no tag to send, and mkfifo.com sent all the bytes again. ## A tag for each answer Now an answer with the status `200` has an `ETag`: the first 16 bytes of a SHA-256 of its `Content-Type` and its body. A `GET` or a `HEAD` with the same tag in `If-None-Match` gets `304`, with no body. The values of `If-None-Match` can be a list, a tag with `W/`, or `*`. An answer with `Set-Cookie` gets no tag. A `304` has no cookie, and a browser that keeps its old copy would also keep no new cookie. mkfifo.com makes the answer, then compares the tags. Thus a `304` does not save the work of the VM, only the bytes. The cache of Cloudflare in front of the Worker saves the work: it keeps a `public` answer for its `max-age`, and the VM does not get its Requests. ## Turns for the clients The rate limits count the Requests of each client address in a window of time: 120 in one minute for one FIFO. They do not count the work of a Request. One Durable Object does the work of all the FIFOs, and the VM gives each process a part of the time. Thus many Requests of one address at the same time took the time of many processes. Now at most 4 Requests of one client address run at the same time. A process, `MkFIFO.Slots`, gives the turns. The other Requests of that address wait in the order of arrival, at most 20 seconds, then get `503` with `Retry-After: 2`. A line of the terminal, and a letter of a page or of "Try", get a message. The Requests of the other addresses do not wait for them. The process monitors each Request that has a turn and each Request that waits. A Request that stops with an error gives its turn to the next one. The process also ends the wait itself, after 20 seconds: a turn cannot go to a Request that stopped to wait. An email from the Worker has no client address. The rate limits do not count the emails, because Cloudflare Email Routing limits them, and the turns do the same. ## A regex in each keyword `/fpo/300x250` took 26 to 32 ms in the Worker on my computer, and `robots.txt` 16 ms. The answer of `/fpo` had 7 calls of `jq`, each with the same filter of 575 characters, and the parse of that filter took 413 µs of the 590 µs of a call. The parser of `jq` used a regex to make sure that a keyword is a whole word: `or` and not the start of `order`. It looks for `and`, `or` and `as` after each term. Since OTP 28, Elixir compiles a regex of `~r` again each time it runs. A check with that regex took 2.2 µs on my computer, and the same check with a match of the bytes took 0.22 µs. Now the parser has no regex for keywords, names and numbers. The parse of the same filter takes about 200 µs, and a call about 270 µs. The test against jq 1.7 gives the same output for its 41,897 cases. ## Fewer calls in /fpo Each text of `/fpo` had two values from `jq`: its `y` and its `font-size`. Now each text has `font-size="10"`, and one value: `transform="translate(150 125) scale(5)"`. A short call gives the height of a square. The answer has 2 long calls, not 7. I drew the old SVG and the new one in Chromium, and compared the pixels. Only the edges of some letters differ, by the anti-aliasing of a font of 10 that is 5 times larger. A `/fpo` takes 2.4 ms on my computer now, not 5.5 ms. In the Worker on my computer, it takes 17 to 19 ms, and `robots.txt` 15 ms. ## /image and /img `/image` was a free name, and any person could make a FIFO there that looks like a part of `/images`. Now `image` and `img` are names of the site, and each route of `images` has the line `Cc: image, img`: `/img/width=192,format=webp/photo` gives the same image as `/images/width=192,format=webp/photo`. A mirror gets the Requests to its own name, but a route had the name of its FIFO in its pattern: `/images/width=:width/:src` did not agree with `/img/width=192/photo`. Now a route examines the path after its first segment, the name of the FIFO that got the Request. The same rule works for a FIFO of a person: an envelope with `To: shop/:item` and `Cc: store` takes `/store/apple`. ## Fewer minutes of CI A run of the CI took 15 to 23 minutes, also for a change of one post. The test of the builtins against the tools of the shell took 9.5 minutes, the test of accessibility 4, the TLA+ models 3, and `mix precommit` 3. Now `mix precommit`, the fonts and the contracts run each time, and `scripts/changes.sh` decides for the other checks. It finds the last commit with a good run: the branch of a merge, else the commit before the push, else `main`. A check runs only when a file that it examines changed after that commit. A change of the CI, of `mix.exs`, of `mix.lock` or of `config/` runs all the checks. Thus the commit that sets the date of a post, and the merge of a tested branch, need only a few minutes.

Show the body Show the header

Egress envelopes of ingress envelope 20

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-708b-9403-4306a2ff4209@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177 This blog will be a FIFO: each post an envelope, and each page an answer. Then the blog of mkfifo.com is also an example of a blog that each person can make. This post tells each step. ## Pages of Markdown An answer of a FIFO has a sandbox: `Content-Security-Policy: sandbox` with `default-src 'none'`. A page in a sandbox cannot run a script, and cannot read the cookies of mkfifo.com. It also cannot load the style sheet and the fonts of the site, so a post in an answer would not look like a page of the site. I did not want an exception for the FIFOs of the site. GitHub shows the README of a repository in its own page, with its header and its style. It changes the Markdown into HTML on its server, and keeps only the tags of an allowlist. A file that can run a script comes from a different origin, as `raw.githubusercontent.com`. mkfifo.com has its own Markdown converter already, for this blog and for emails. It gives the escapes of HTML to each character of the text, and makes only its own tags: headings, paragraphs, lists, code, tables, and links to `https:`, `mailto:` and the paths of the site. So now an answer with `Content-Type: text/markdown` is a page in the frame of the site, from any FIFO: ```envelope To: - Content-Type: text/markdown Subject: Opening hours Cache-Control: public, max-age=3600 We are open from **9 to 17**, Monday to Friday. ``` `Subject` is the title and the first heading of the page. A value in the body is text, as in an email of Markdown: `\$name` cannot add a link or a heading. An answer of HTML keeps its sandbox: its tags are the tags of the FIFO. ### The same page for each person The key of the cache in front of the Worker has no cookie. The header of the site shows the address of a person who signed in, so a public page with that header could go from the cache to a different person. A page of Markdown has no data of the person: the header shows "Sign in", and the page has no CSRF token. Each client gets the same bytes, and the same `ETag`. The script of the site read the CSRF token at its start, so on the first page with no token it stopped with an error. The accessibility check did not see it: axe examines the page, not the console. Now the check also fails on an error of a script, and it found this error before I changed the script. ### Who wrote it A page of a FIFO of a person has the banner of the page of a held FIFO: "mkfifo.com did not write the text of this page." A link of Markdown can still go to a different site, as a link in a README can. A call, a pipe and a read of the FIFO get the text of the body, not the page: `< opening-hours` gives the Markdown. ## Any number of envelopes Each post of the blog will be one ingress envelope with a route, so the FIFO of the blog needs many envelopes. A FIFO had at most 32. The owner said that an envelope is a row of the database: a query can find the envelopes that agree with a Request, and the editor can show them in parts. The limit had four causes. Each one now has a different solution. ### A Request examined each envelope Now the `To`, `Cc` and `Bcc` edges of an envelope with a route keep the key of the route: its full segments of text after the name. `blog/2026/:slug` has the key `/2026`, and `blog/2026/a-post` has the key `/2026/a-post`. An index of the edges has the keys. A Request for `/blog/2026/a-post` loads only the envelopes with the empty key, the key `/2026` and the key `/2026/a-post`, and a Request with no path loads only the envelopes with no route. A test examines the key on each case of `URLPattern` in the tests, and on random routes: each path that agrees with a route has the key of the route at its start. ### Envelopes with no route A Request with no path still examines each envelope with no route. Now each envelope takes 1,000 of the 10,000,000 steps of the Request, as the work of `grep` or `jq` does: at most 10,000 envelopes examine one Request. The report of the editor tells which envelopes did not examine it. ### Memory The process of a FIFO kept all its envelopes, compiled. Now it loads each part at the first Request that needs it: the envelopes with no route, and the envelopes of the keys of the recent paths, at most 256. ### The editor The editor showed all the envelopes. First I added a link "More envelopes" that showed 50 more on the same page. Then I measured it: the page with all of 1,000 envelopes took 3 seconds in a local Worker, and each person who knows the name of a FIFO can open its editor. So now each part has only its 50 envelopes: `?part=2` shows the envelopes 51 to 100, and "Earlier envelopes" goes back. "Try" has only the envelopes of the part with no route, because a letter has no path. ### The measure I measured in a local Worker (`wrangler dev`) on my computer, with the median of 30 Requests: | The FIFO | A `GET` | |---|---:| | 4 routes | 12.7 ms | | 1,001 routes | 13.2 to 14.4 ms | | 1,001 routes, and a path that no route has | 12.0 ms | | 1,001 envelopes with no route | 92 to 99 ms | The number of routes does not change the time. Each envelope with no route adds about 80 µs. A part of the editor with 50 envelopes took about 200 ms, the last part with one envelope 80 ms, and the editor of a FIFO with 4 envelopes 65 ms. The live database has envelopes with routes from before the keys: the routes of `/images` and `/fpo`. A migration gives their edges the keys. I ran it on the database of my local Worker, which had these envelopes, and `/images`, `/img` and `/fpo` still answered. ## The date and the keywords Each post of this blog has a date and keywords, and the page shows them under the title. A post in an envelope must show them too. I did not want a first line of the body for the date: the description of a page is its first paragraph, so the description would be the date. An envelope is an email, and an email has the fields `Date` and `Keywords`. So the page of an answer of Markdown now shows them under its title, as an email client does, for each FIFO: ```envelope To: - Content-Type: text/markdown Subject: A blog in a FIFO Date: 2026-10-08T19:17:00Z Keywords: planned, changed This blog will be a FIFO... ``` A date in ISO 8601 shows as a day, "8 October 2026", in a `<time>` element. A different text shows as it is. The keywords are the words between the commas. ## A list from data The list of the posts must come from the envelopes of the FIFO, with a link to each post. But a value in a page of Markdown is text: the output of `jq` cannot add a link or a heading. This rule stops a capture of a Request from adding a link to a page. The builtin `markdown` has the same converter as the page. It gives the escapes of HTML to each character of the text, and makes only its own tags. So now its output goes into a page of Markdown as it is, as it does in a body of HTML. A list alone in its paragraph takes the place of the paragraph: ```envelope To: - Content-Type: text/markdown Subject: Posts \$(\$posts | markdown) ``` A capture alone is still text. Only the owner of the envelope can put `markdown` in the pipe, and then the links can go only to `https:`, `mailto:` and the paths of the site. The HTML part of an email of Markdown has the same rule. ## Larger posts An envelope had at most 16 KiB. The largest post of this blog has 14.6 KB, and a post gets a section at each merge, as this post did now. So now an envelope and a note can have 32 KiB. ## The posts as files The list of the posts must change when I add a post, with no change of the envelope of the list. So a FIFO now has files, and the commands of rclone list them: `ls`, `lsl`, `lsd`, `lsf` and `lsjson`. A file is an ingress envelope with a route of fixed text: `To: blog/2026/a-post` is the file `2026/a-post` of the FIFO `blog`. A directory is a start of the path of a file. The data of a file come from its answer: the size of the body, its `Content-Type`, and its `Date`. `lsjson -M` also gives the subject, the keywords and the first paragraph of an answer of Markdown. So `jq` can make the list, and `markdown` can make the links: ```envelope To: - Content-Type: text/markdown Subject: Posts \$(lsjson -R --files-only -M blog | jq -r '.[] | "- [\(.Metadata.subject)](/blog/\(.Path))"' | markdown) ``` The output has the formats of rclone, also the escapes of Go in the JSON: `<` is `<`. ### Only the envelopes of the home A route can be a secret, as the name of a FIFO: a person can give a link to `/notes/k7f2x9` and to no other path. So an envelope lists only the envelopes of its own FIFO, the envelopes that its editor shows already. The FIFO that holds `blog` lists the posts of `blog`. A different FIFO, `//bin/ls` and the terminal list nothing. ### Limits A list reads at most 1,000 envelopes under its path, with the index of the keys of the routes. It takes 1,000 steps of the Request, and each envelope 1,000 more, as an envelope that examines a Request. The first paragraph of a post comes from the converter, which stops at the end of that paragraph: each byte that it reads takes one step. ## A feed The feed of this blog has the full text of each post. The new feed will have a summary of each post: its first paragraph. `atom` changes a JSON Feed 1.1 into an Atom feed, so `jq` makes the JSON Feed from `lsjson`: ```envelope To: - Content-Type: application/atom+xml \$(lsjson -R --files-only -M blog | jq '{title: "Posts", home_page_url: "https://mkfifo.com/blog", items: [.[] | {id: "https://mkfifo.com/blog/\(.Path)", url: "https://mkfifo.com/blog/\(.Path)", title: .Metadata.subject, summary: .Metadata.description, date_published: .ModTime}]}' | atom) ``` A value in a body of XML gets the escapes of XML, so the output of `jq` cannot add an element. `atom` gives each text the escapes of XML, and its output goes into the body as it is, as the output of `markdown` goes into a page. A control character becomes U+FFFD, because XML 1.0 has none, and a link must start with `https://`, `http://` or `/`. ## The blog is a FIFO Now this blog is the FIFO `blog`, and the FIFO `mkfifo` of the site holds it. Each of the 18 posts is two envelopes of `mkfifo`: an ingress envelope with the route `blog/DATE-NAME` for a `GET`, and its answer of Markdown with `Subject`, `Date` and `Keywords`. The list of the posts and the feed are two more envelopes, with `lsjson`, `jq`, `markdown` and `atom`. The 417 lines of the old code of the blog went away. Open the editor of [mkfifo](/mkfifo) to read them. ### Each \$ is \\$ now The body of an answer is a template, and the posts show many commands. The 18 posts had 182 dollar signs, and the template found 96 variables and commands in them: `\$(totp \$email)` in a post would run `totp`. So each `\$` of a post is `\\$` now, and the page shows a `\$`. The description of `lsjson -M` reads `\\$` as `\$` too. ### The day in the list The `jq` of mkfifo.com has no functions for dates. So the list writes the day with an array of the names of the months, and `.ModTime[5:7] | tonumber` is the position in it. ### Old names The old names of the posts, from before I joined the posts by subject, gave a redirect to their new post. They give 404 now. ### The measure I measured in a local Worker, with the median of 30 Requests, and with a new query in each Request, so that the cache did not answer: | The page | A `GET` | |---|---:| | `/blog`, the list | 96 ms | | `/blog/feed.xml` | 91 ms | | A post | 27 ms | | `/docs`, a page of the code | 19 ms | The list and the feed read 19 envelopes, and the first paragraph of 18 posts. Each answer has `Cache-Control: public, max-age=300`, so the cache in front of the Worker answers most Requests.

Show the body Show the header

Egress envelopes of ingress envelope 21

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7092-a67b-1183cd64b796@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

The builtin `image` became `magick`, with the words of ImageMagick 7 and a test against ImageMagick itself. A FIFO can have 32 ingress envelopes now, and `/fpo` gives placeholder images with no new code. ## magick, with the words of ImageMagick The builtin `image` had the options of a URL of Cloudflare Images as its word. It was the only builtin that was not a tool of a shell, and `/bin/image` next to the FIFO `/images` was strange. Now the builtin is `magick`: a part of the command `magick` of ImageMagick 7, with the same words. ``` \$(magick - -auto-orient -strip -thumbnail '192x>' -quality 100 webp:- < photo) ``` A person who knows ImageMagick knows these words. And a test can give the same words to ImageMagick and compare the two images. ### The same routes `/images/width=192,format=webp/NAME` still works. The envelopes of `/images` change the options `width`, `height` and `format` into the words of `magick`. They come in this sequence, with a comma between them, and each shape has a route. A route does not make an image larger (`192x>`), a PNG and a WebP are lossless, and a JPEG goes on white with the quality 85. The other options of Cloudflare are gone. I wrote one route for each of the 11 shapes, and the seed failed: a FIFO has at most 16 ingress envelopes, and `mkfifo` had 8. A route can have an optional group, so a route with a width also takes a height: ``` To: images/width=:width([1-9]\d{0,3}){,height=:height([1-9]\d{0,3})}?/:src([^\/]+(?<!\.svg)) ``` With no height, `-thumbnail "\${width}x\${height}>"` is `192x>`. I could not do the same for the width: ImageMagick reads `x>`, with no width and no height, as a size of 1 by 1 pixel. Thus there are 8 routes, and `mkfifo` has 16 envelopes now. ### A test against the real tool Ubuntu 24.04 has no package of ImageMagick 7. `scripts/magick.sh` builds ImageMagick 7.1.2-32 from its source, and gives the same random images (PNG, JPEG, WebP and GIF) and the same random words to the two. The two images must have the same format and the same size, and a pixel of a PNG or a WebP can differ by at most 3 levels of 255. The CI runs it on each push, and keeps the build in its cache. To get there, the builtin does the work as ImageMagick does it: - The resize has the code of `MagickCore/resize.c`: the same filters (Lanczos, Mitchell for an image with alpha, and Box and LanczosSharp for `-thumbnail`), the same weights, and the same pass first. Between the two passes, ImageMagick HDRI keeps floats with no clamp: a pixel near a sharp edge can be more than white for a moment. With a clamp there, the test found pixels that differed by more than 3 levels. - After a resize, the pixels have 16 bits, with no clamp, and the colors stay multiplied by their alpha. A color with an alpha near 0 can be very large in ImageMagick, but the product stays small. - A JPEG of ImageMagick has the sampling factors of its input, else 4:4:4 for a quality of 90 or more, and 4:2:0 below. Its quality comes from `-quality`, else ImageMagick estimates the quality of the input from its tables. The encoder is now the crate jpeg-encoder, which can write these sampling factors. - At the right and the bottom edges of a JPEG with half the color, the first decoder took the padding of the blocks, and libjpeg repeats the last color. The crate jpeg-decoder gives the colors of libjpeg. Some differences stay. A JPEG of ImageMagick uses the fast DCT of libjpeg up to the quality 90, and the builtin the accurate DCT: the mean of the pixels differs by up to 4 levels. On a small image with much noise, two encoders of JPEG round in different ways, and the difference can be more. There the test asks that the JPEG of the builtin is as near to the image as the JPEG of ImageMagick. ### An error, not a different image Some words make an image that the builtin cannot make. Then `magick` gives an error, and the error tells the words that give the same image: - An image with an EXIF orientation needs `-auto-orient` or `-strip`, and an image with a color profile needs `-strip`: the builtin writes no profiles. - `-crop` needs `+repage` after it. After `-auto-orient` of the orientation 5 or 7, ImageMagick keeps the old size of the page, and `-crop`, `-extent` and `-flatten` read it: `+repage` must come before them. - A JPEG has no alpha: transparent pixels need `-background COLOR -flatten`. - A WebP must be lossless: `webp:-` needs `-quality 100` or `-define webp:lossless=true`. The encoder of the builtin writes only lossless WebP. With `-define webp:lossless=true` and a quality below 100, ImageMagick writes a "near lossless" WebP, which the builtin cannot write either. I found each of these with the test: a case that differed, then the source of ImageMagick. `-crop` of an area out of the image gives an image of one transparent pixel, not an error. `-resize 56x^` reads the missing height as 0, not as the height of the image. ### The cost The first version needed 12,200,000 steps for an image of 1200 by 630 pixels to a WebP 600 pixels wide: more than the 10,000,000 that a Request has. The resize read each source pixel again for each weight, and changed it to a float each time. Now it changes each row one time. It keeps only a few rows: the rows of a target row, or, when the image gets much smaller, the sums of the target rows. The small functions of a pixel are inline, and the output goes into a buffer of its size. A work of many output pixels takes a third of the time it took. I measured each part again: a step of the resize is about 0.08 µs, as a step of `resvg`, in the interpreter of WAMR on my computer. The same image needs 9,200,000 steps now. A photo of 1920 by 1008 pixels to a width of 800 still needs 27,900,000 steps, so it gets no image. The Worker runs the WebAssembly in V8, which is much faster than the interpreter, but the steps of all the builtins come from the same interpreter, so the limit stays the same for each of them. ## More envelopes in a FIFO A FIFO can have 32 ingress envelopes now, not 16. The limit of 16 was a first value from the start of the project, and the routes of `/images` found it. The FIFO `mkfifo` of the site holds `fonts`, the icons, `robots.txt` and `images`, with 8 envelopes. I wanted one route for each shape of the options of `/images`, 11 routes, and the seed failed. So the routes with a width took an optional height, and `mkfifo` had 16 envelopes, with no free place. ### Why a limit stays Each person who knows the name of a FIFO can add an envelope to it. Each Request to a FIFO goes through all of its ingress envelopes, the process of the FIFO keeps all of them in memory, and the editor shows all of them. One Durable Object does the work of all the FIFOs. A FIFO with thousands of envelopes would make each FIFO slow, not only its own. 32 gives room for a FIFO with many routes, and keeps the work of one Request small. The limit of 64 egress messages for one Request stays. Each ingress envelope can have 4 egress envelopes, so 32 of them can have 128. But a Request that agrees with more than 16 ingress envelopes is not usual, and the messages after the 64th fail with an error. ### One route for each shape `/images` has one route for each shape of `width`, `height` and `format` again: 11 routes, and `mkfifo` has 19 envelopes. A route is easier to read with no optional group: ``` To: images/width=:width([1-9]\d{0,3}),height=:height([1-9]\d{0,3})/:src([^\/]+(?<!\.svg)) ``` The URLs did not change: `/images/width=192,format=webp/NAME` gives the same image as before. ## Placeholder images `/fpo/300x250` gives a placeholder image: a gray box of 300 by 250 pixels, with `300×250` on it. FPO is "for position only": an image that holds the place in a design until the real image is there. The words are those of fpoimg.com, as the words of `/images` are those of Cloudflare: the size in the path, one number for a square, and the fields of the query. ``` /fpo/300x250?text=Hero+image&bg_color=4361ee&text_color=white ``` `text` goes above the label, `bg_color` and `text_color` take hexadecimal digits or a name of CSS, and `dims=false` removes the label. ### No new code `/fpo` is one ingress envelope and one answer envelope in the seed of the FIFO `mkfifo`, and it uses only the parts that are there already. A route takes the size, with the height as an optional group: `fpo/:width([1-9]\d{0,3}){x:height([1-9]\d{0,3})}?`. A `GET` of a held FIFO is a form, so the fields of the query are field lines, and their patterns refuse a color that is not a color. The answer envelope is the SVG itself, with `Content-Type: image/svg+xml`. A template cannot calculate, and the size of the text must change with the size of the image and the length of the text. The builtin `jq` does the arithmetic: the font size is the smaller of a part of the height and the width divided by the number of characters, and two lines stay at the center together. The colors needed a default with no `if`. CSS ignores a declaration that is not valid, so the rectangle has `fill="#dddddd" style="fill: \$bg_color; fill: #\$bg_color"`. With `steelblue`, the first declaration is valid. With `4361ee`, only the second one is valid. With no color, the two are not valid, and the gray of the attribute stays. ### Safe text in an SVG An SVG can have a script, and the text comes from the URL. Two rules of the answers make it safe. A value in a body of XML gets the escapes of HTML, so `<script>` becomes text. And each answer has `Content-Security-Policy: sandbox` with `default-src 'none'`, so a script does not run. The tests send `<script>` in `text`, and check that the SVG is well-formed XML. ### Only SVG A placeholder as a PNG needs the label as pixels. resvg draws an SVG in the VM, but it has no fonts, and refuses `<text>`. Thus `/fpo` gives only SVG, and the browser draws the text with its own font. ### Late timers in the tests Two tests failed one time each this week: a timer of 250 ms came after 1 s, and a trace message after 100 ms. The cause was the NIFs of `magick` and `resvg`. The calls into one library of WebAssembly run one at a time in beam.com, and a call that waits for a different call waits on its scheduler. The tests of `magick` render large images at the same time, so they kept all the normal schedulers. With 8 renders, a timer of 50 ms came 4.8 s late on my computer. Now the functions of the two NIFs run on the dirty CPU schedulers, and the same timer comes at most 1 ms late. In the Worker there is one thread, so this changes nothing there: the steps of a Request still limit the work of each call.

Show the body Show the header

Egress envelopes of ingress envelope 22

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7099-8996-e75aad1f726c@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

A post of this blog is an envelope now, and a person can write a blog in a FIFO. But the body of an envelope had the size of the envelope in the editor. This post tells how the editor gets room for a long text. ## The full view Each envelope has a button "Open in full view". It opens the envelope in a modal dialog that fills the window. It is not the full screen of the browser: the window of the browser stays as it is. On a wide screen, the header fields are at the left, and the body is at the right with the height of the window. On a phone, the letter is in front of the envelope, as before, but it is high. The body of an egress envelope is a text, so in the full view its long lines wrap. Then a line of the text can take more than one row, and the line numbers do not agree with the rows. So the line numbers go away there. The list above the body still names a line with an error. ### One form The dialog has the same form as the envelope in the page: a copy would be a second form with the same fields. Each envelope is in a `<dialog>`. When the dialog is closed, a rule of the style sheet gives it `display: contents`: the dialog has no box, and the envelope is in the page as before. Before I changed the editor, I checked this in Chromium. A closed dialog with `display: contents` shows its fields in the page, and they take the focus. The tree of accessibility has no dialog for it, only the heading, the fields and the buttons. When the dialog opens as a modal dialog, it is in the top layer, it fills the window, and Escape closes it. ### No JavaScript The button has `commandfor` and `command="show-modal"`, as the dialogs to add an envelope. The browser opens the dialog, so the full view works with no JavaScript. LiveView does not change the attribute `open` of the dialog, so a save keeps the full view open. ## Live Markdown In the full view, the body of an egress envelope with `Content-Type: text/markdown` shows the styles of Markdown now, while I write: a heading is large, `**strong**` is bold, `_emphasis_` is italic, and code, links, the items of a list and the tables have their styles. The marks stay in the text, in a lighter color. I wanted the text to stay the text: the view hides no mark, so the place of the caret is the same in the text and on the screen, and a save sends what I see. The view follows the rules of the converter of this site, not the rules of CommonMark. `# Title` and `* item` are not Markdown here, so they get no style: the view shows what the page will show. A variable of the template, such as `\$name`, has a color too. ### A view next to the textarea The textarea stays the field of the form. The view is an element with `contenteditable="plaintext-only"` next to it. After each change, the view reads its text, writes its HTML again with a class on each part, puts the caret back at the same place, and puts the text into the textarea. Enter in an item of a list starts the next item, and Ctrl+B and Ctrl+I put the marks of strong and emphasis on the selected words. The browser cannot undo a change of HTML that a script wrote, so the view keeps its own history for Undo and Redo. The functions that make the HTML and find the caret have no DOM, so `node:test` tests them. One test makes 20,000 random texts and checks that the text of the HTML is the same text, character for character. ### Three things that I found - Chrome sends `insertLineBreak`, not `insertParagraph`, for Enter in an element with `plaintext-only`. My first version waited for `insertParagraph`, so a list did not continue. Now the view handles the key Enter itself. - The view is in a container with `phx-update="ignore"`. LiveView still sets the `data-*` attributes of the server on such a container, and removes its other `data-*` attributes. The view kept its state in `data-active`, so the first answer of the server hid the view and took its focus. Now the state is a class. - A new value of `contentEditable` takes the focus away from the element. The view set it after each answer of the server. Now it sets it only when the field becomes read-only or editable. The server also writes the textarea, and an answer that comes late has an older text of the view. The view keeps a short list of the texts that it sent: when one of them comes back, the view writes its own text again. A different text is a change on the server, and the view shows it. The full view of a locked envelope, such as a post of this blog in the editor of `mkfifo`, did not fill the window. Its envelope has a `<div>` in place of a form, and the rules of the style sheet named the form. Now they name both. ## Blocks The tab "Blocks" next to "Text" shows the same body as blocks, as the notes of an ingress envelope have: a paragraph, a heading, a list, a numbered list, a quote, code, a table and an image. The body stays Markdown. A change of a block writes the Markdown of that block into the body, and the tab "Text" shows the same text. Each block keeps its source, and a block that did not change writes its source again, character for character. So when I change one paragraph, the other blocks keep their text, with their spaces and their line breaks. A test makes blocks, writes their text, reads the blocks of that text again, and compares them. I planned to write `\\$` for each `$` in a block, so that a `$` is a `$` on the page. But the template keeps `\$5` and `\$USD` as text already: only `\$name`, `\${name}` and `\$( )` are variables. So a block keeps the text of the template as it is, and `\$name` in a block is still a variable. ### Blocks that look as the page My first blocks were fields: each block had a label, a textarea or a grid of fields, and a select of its type. They worked, but they did not look as the page. Now each block is the element that the page shows, with the styles of a post: a paragraph is a paragraph, a heading is a heading, and a table is a table. I write in the block itself, as in the paragraphs and the headings of the notes. Bold words are bold, with no marks, and the block writes the marks into the Markdown. A new module, `markdown_inline.js`, makes the HTML of the words of a block, and reads the Markdown again from the HTML after a change: strong, emphasis, code, links and images, with the rules of `FIFO.Markdown`. A variable of the template is a chip, and I cannot change a part of it, so a variable stays a variable. The tests of the module run in Node.js, on objects with the properties of DOM nodes. The commands and the settings of a block are in one floating toolbar over the block with the focus, as in the notes: the type of the block, the buttons of bold, italic, code, a link and a variable, the settings of the type (the language of code, the rows, the columns and the alignment of a table, the address and the alt text of an image), and the buttons that move and delete the block. "+" in the gap after a block adds a paragraph. Enter in a paragraph starts a new paragraph with the words after the caret, and Backspace at the start of a paragraph joins it to the paragraph before it. A body with no blocks showed one empty paragraph, and its "+" showed only on a pointer or with the focus, so it was not clear how to add a block. Now the tab shows the "+" button of the notes, with the text "Add a block", and the new paragraph takes its place. An empty paragraph goes away when the focus leaves the blocks, as an empty new block of a note. The checks found these problems: - Enter in a field of a form sends the form. The fields of my first blocks were in the form of the envelope, so Enter in a cell of a table or in the address of an image saved the envelope. The fields of the toolbar are in the same form. Now their attribute `form` names a form that is not on the page. Such a field has no form: Enter does not save the envelope, and LiveView does not send its changes. - A new quote had an empty paragraph with no height, and the browser could not put the caret in it, so the words that I typed went nowhere. Now an empty line of a quote or of a list has a line break, as the browser writes it. - axe found `role="textbox"` on the headings and the lists, where it is not permitted: it hid their roles. Now each element keeps its role, and a group around each block has its name, for example "Heading 2, block 3". - `npm test` must cover 100% of the files that its tests load, but its pattern `*.js` matched only the files of the Worker at the root, not the modules of the editor. Now it also includes `assets/js/`. ## After a save On a phone, the dialog of a new egress envelope looked broken after a save with an error: it had no backdrop, and the ingress envelope of the page was over it. When a save has an error, the error summary comes before the envelopes, and LiveView moved the envelopes after it. A move takes an element out of the document for a moment, and a modal dialog in it stops being modal: it stays open as a usual dialog. Now the summary has a place that is always in the page, so nothing moves. If a different change moves a dialog, an observer in the page makes the dialog modal again, with its scroll and its focus. A save also changed the tab of the full view to "Text". While LiveView sends a form, it makes the fields of the form read-only for a moment. The view of the body took that for a locked envelope, and a locked envelope shows only the text. Now the view reads the value that LiveView keeps in `data-phx-readonly`. ## Next Buttons, a cover, and media with text are not blocks. Markdown has no syntax for them, so they wait for a syntax that the converter can read.

Show the body Show the header

Egress envelopes of ingress envelope 23

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70a0-93e6-4f65c0444d4b@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

A FIFO can have more than one path now: a route after its name, in the syntax of URLPattern. The first routes give the icon at each width, and the images of each FIFO with the options of Cloudflare Images. ## Routes for a held FIFO Yesterday a cache came in front of the Worker, for the images that the VM will make. Today the first one has a path: `/images/width=192/favicon.svg` gives the icon of mkfifo.com as a PNG of 192 pixels. `images` is a FIFO, and the path after its name is a **route**. ### A path after the name Until today a FIFO had one path: `/NAME`. Now the `To` of a holder can have a path after the name of the FIFO that it holds: ``` To: images/width=:width([1-9]\d{0,2})/favicon.svg X-HTTP-Method-Override: ^GET\$ ``` A `GET` of `/images/width=192/favicon.svg` is a Request to the FIFO `images`, and the route gives the capture `width`. The answer envelope draws the SVG of `favicon.svg` with `\$(resvg -w \$width - -c < favicon.svg)`. The answer has `Cache-Control: public, max-age=86400`, so the cache keeps each width, and the VM draws each width one time. A width of 0, of more than 999, or with a 0 before it gets `404`. Each holder can have routes, not only the FIFOs of the site. The holder `shop-k7f2` can save `To: shop/:item`, and then `GET /shop/apple` is a Request to `shop` with `\$item` as `apple`. The first plan was the syntax of Cloudflare Pages: `[name]` for a segment, and `[[path]]` for the rest of the path. But the other lines of an envelope have patterns, and a group of a route can have one too. The web already has a syntax for this: `URLPattern`, from the URL Pattern Standard of WHATWG. It has `:name`, `:name(PATTERN)`, and `?`, `*` and `+` after a group. Each browser and Node.js has it, so you can try a route in the console of a browser. ### The same match as URLPattern `FIFO.Route` follows the algorithms of the standard: it reads the route into tokens, makes the parts, and makes the same regular expression. The pattern of a group is a pattern of `re`, as each pattern of an envelope. I added some rules. Each group must have a name, because a group is a capture: the standard gives a number to `*` and to `(PATTERN)` with no name. And `URLPattern` changes some text before the match. It removes a segment `..` and the segment before it, also `%2e%2e`, and it encodes a space as `%20`. Then the text that a person writes and the text of the match are different. So the text of a route can have only the characters that a URL keeps in its path, and no segment `.` or `..`. A path with such a segment agrees with no route. ### A model, and a check against Node.js The TLA+ model `specs/Routes.tla` has routes of whole segments: fixed text, and groups with each modifier, with a pattern for all text or only for digits. For each route and path, the model gives the match. Each part takes a count of segments, and the regular expression of the standard tries the larger count first, from the left. Thus the match has the greatest list of counts, in the order of a dictionary. TLC checks four invariants, and writes 44,440 cases. `scripts/routes.sh` gives each case to `FIFO.Route` and to `URLPattern` of Node.js, and compares the two results with the result of the model. Then it makes 5,000 random routes with prefixes, suffixes, `{ }`, patterns and modifiers, and 1,000 routes with one character less, which are often errors. For each one, `FIFO.Route` and `URLPattern` must give the same groups, or both must refuse the route. To test the check, I changed the regular expression of `?` to the lazy `??`: the check found 933 differences. The CI runs the check on each push. ### Each envelope decides More than one route can agree with one path. I did not add an order of routes. Each ingress envelope examines the Request, as before, and each egress envelope decides what it sends, and where. The first answer egress gives the answer to the client. An envelope with no route agrees only with `/NAME`, so the envelopes of the FIFOs before today do not get the new paths. An email, a Request from a different FIFO and a letter of a page have no path, so they agree only with an envelope with no route. For this reason an envelope with a route gives no letter on the page of a FIFO. The editor shows the path of each Request. The path of a request that fails is also in the log, so do not put a secret in a route. ### A number too large for a float The full tests of this change found a different problem, in a test. A property test compares the errors of the JSON tokenizer of the selector lines with `JSON.decode/1` of Elixir, with random texts. One run made `100e911`. `JSON.decode/1` refuses it, because no float has this value. But it is valid JSON, and the value of a number in a selector line is its text, so the tokenizer keeps it. The tokenizer was correct, and the test was not. Now the test expects no error for a number out of the range of a float. ## The images of each FIFO `/images/width=192,format=webp/NAME` now gives the image of the FIFO `NAME`, 192 pixels wide, as a WebP. The options are the options of Cloudflare Images, but the VM makes the image, and the cache in front of the Worker keeps it for one day. Each FIFO that gives an image to a `GET` can be a source. ### The options of Cloudflare The new builtin `image` takes the text of the options of a URL of Cloudflare Images as its word: ``` \$(image width=192,height=192,fit=cover,gravity=top,format=webp < photo) ``` It has `width`, `height`, `fit` (`scale-down`, `contain`, `cover`, `crop`, `pad` and `squeeze`), `gravity`, `format`, `quality`, `background`, `dpr`, `rotate` and `flip`, also the short names `w`, `h`, `f`, `q` and `g`. It reads a PNG, a JPEG, a WebP or the first frame of a GIF, and writes a PNG, a JPEG or a lossless WebP. Each builtin before it has the name and the options of a tool of a shell. This one has the options of a URL, so that the same text works in a URL and in an envelope. Some options of Cloudflare give an error. `format=auto` selects the format from the field `Accept` of the browser, but the key of the cache has no header field: two browsers would share one copy. `avif` needs an encoder that the NIF does not have, and the builtin has none of the effects, as `blur`, `sharpen` and `trim`. ### A read from a variable The envelope of `/images` is short: ``` To: images/:options/:src([^\/]+(?<!\.svg)) X-HTTP-Method-Override: ^GET\$ ``` ``` To: - Content-Type: image/* Cache-Control: public, max-age=86400 \$(image \$options < \$src) ``` `< \$src` is new: it reads the FIFO whose name is the value of a variable. Until now the target of a redirection was a name in the text, because it is an edge of the graph, and the save refuses an edge that makes a loop. A variable has no name at the time of the save, so the save cannot check it. Thus only an envelope of the site can read the FIFO of a variable, and the limit of 8 hops stops a loop at the time of the Request. A script of `sh` can do it too, because a script never had edges. `Content-Type: image/*` is new too. The format of the output can change with the options and with the source, and a variable in `Content-Type` is an error, because a value of a Request could make an answer of HTML. Now the answer gets the type from the first bytes of the body: `image/png`, `image/jpeg`, `image/webp` or `image/gif`. Any other body makes the egress fail, so this answer is never HTML or SVG. ### A resize with no SIMD The image comes from the crate image of Rust, in WebAssembly, as the NIF of resvg. My first resize was the crate fast_image_resize, and beam.com did not load the module: "v128 value type requires simd feature". The crate has SIMD code for wasm32, and the WebAssembly of beam.com has no SIMD. The resize of the crate image works, but it keeps a buffer of floats, 16 bytes for each pixel, and the memory of WebAssembly does not get smaller. So the NIF has its own resize. For a factor of 2 or more, a box filter shrinks the image first, as the shrink of libvips. Then a Lanczos3 filter gives the exact size, with weights of 14 bits, on pixels with the alpha channel multiplied, so a transparent pixel gives no color to the pixels near it. A test compares it with the Lanczos filter of ImageMagick: for a factor below 4, the mean difference is less than one level of 255, and for a factor of 11 it is 2.1, because of the box filter. ### The cost of an image The DO has one thread, so a long image stops each other Request. The NIF reads only the header of the image first, and counts the steps of the work before it starts: decode, resize, crop and encode. I set the steps from the time of each part, so that a step of `image` takes about the time of a step of `resvg`. The encoder of PNG was the slowest part. With the Paeth filter in place of adaptive filters, a PNG is 1 to 2% larger, and its encode is 25 to 30% faster. An image of 1200 by 630 pixels to a WebP 600 pixels wide needs about 4,700,000 steps, less than half of the 10,000,000 that a Request has. A photo of 1920 by 1008 pixels to a width of 800 needs about 16,600,000 steps, so it gets no image. The largest work keeps the memory of the NIF at 23 MiB.

Show the body Show the header

Egress envelopes of ingress envelope 24

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70a7-8abe-8dfd3ae6fb66@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

This blog had 55 posts after six days, often three or four in one evening, a few minutes apart. Now it has 17: one post for each subject. Each merged branch adds a post, so the list followed the branches, not the subjects. Email had three posts on two days, and the shell had seven. A reader who came for one subject had to find its parts between the other posts. Now the posts of one subject are the sections of one post, in the order of their days. A section keeps the text and the title of its old post. The name of a post has the first day of its subject, and its `Date` is the time of its last part. Each post stays under 16 KiB. ## The old addresses A post has a new header field, `Replaces`, with the names of the posts that it joins. The address of an old post gives `301` to its new post, so a link from a different site still works, and a feed reader finds the new address. The build stops when an old name is still a post, or when two posts replace it. A link from one post to a different one goes to the new post now. A link to a section of the same post became a reference in the text, for example `(see "Mirrors" below)`.

Show the body Show the header

Egress envelopes of ingress envelope 25

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70ae-9d8c-209704c0a513@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

The backend `s3` is envelopes, and each envelope is a pipeline of builtins. The signature of AWS is 26 runs of `printf`, `sed`, `cut`, `sha256sum` and `hmac -K` in `sh -c`, and the answer of a `PROPFIND` changes a list of 1,000 keys with one filter of `jq`. A Worker of Workers Paid can send 10,000 subrequests for each request, so a FIFO can send a request for each key of a list. Then a builtin runs many times for one Request, and its speed is the speed of the backend. So I measured the builtins, and made them faster. ## Three places to measure `scripts/bench.exs` runs each case in the shell of mkfifo.com, in the VM on my computer, and gives the time, and the steps and the runs that the case takes from the work of a Request. `scripts/bench.mjs` sends the same cases to `//bin/sh` of the Worker in `wrangler dev`, where the VM runs in WebAssembly, as on Cloudflare. With `--live`, it sends them to mkfifo.com itself, after the deploy: at most 30 requests in a minute, and the median of 5 requests for each number. The Worker was harder to measure. An HTTP request takes about 30 ms there, much more than a small case. In a Worker, the clock does not move while the code runs, so the VM cannot measure itself. So a request runs the script of a case on many lines, and the time of one run is the difference of many lines and one line, divided by the number of lines less one. The query of a request can be about 8 KB, so the long script of the signature fits only 5 times, and its time changes by about 1 ms from run to run. The rate limit of `/bin/sh` stopped my first run, so the script now sends at most 50 requests in a minute, and waits when it gets `429`. The two places do not agree. In the Worker, the code of Erlang is about 3 times slower. A NIF is faster there: the VM on my computer runs a NIF of WebAssembly in an interpreter, and V8 compiles it. scrypt of rclone takes 1.7 s on my computer and about 0.2 s in the Worker. So I measure a NIF only in the Worker. ## The parse was the work The profile of the signature showed little work in the builtins. Most of the time went to the parse of the commands, again for each Request. The filter of `jq` that checks the configuration of `s3` (872 bytes) took 272 µs to parse, and 10 µs to run. The parse of a text is always the same, so a process now keeps its last parses: of templates, of scripts, of filters of `jq` and of formats of `printf`, at most 32 of each. Two smaller things were in the same profile. The shell split each command into words to look for `set`, `unset` and `exit`, and `String.split/1` makes a pattern each time. Now only a command that starts with one of them is split. Each `~r` of Elixir imports its regular expression again on each use, so the shell reads the name of a variable with patterns of binaries. ## jq, step by step The list of 1,000 keys took 450,000 steps of `jq`, and 0.8 s on my computer. - Each step took one step from the work of the Request, with four operations on counters. Now a run takes 1,000 steps at a time, each step is one operation on an atomic, and the run gives back the steps that it did not use. A test gives a run exactly the steps that it needs, then one step less, so I know that the limit stays exact. - `capture` compiled its regular expression for each key. A run now keeps them. `capture` is also in the code now, not in the language of jq, with the outputs and the errors of jq 1.7. - jq gives the offsets of a match in characters. The count was a loop with a float, and a float is a new term at each byte. Now the count is an integer, and a search in C finds the first byte over 127 first: each byte before it is a character. That search helped most in the Worker, where a loop of Erlang over each byte is slow. The same search finds a string of JSON that needs no escape. - The program of `s3` had six `gsub` for the entities of XML, and `with_entries` to remove a null date. One `gsub` with an object does the same work, and a directory gets its date only when it has one: 264,000 steps in place of 450,000. The 41,897 cases of `jq` in `scripts/builtins.sh` still give the outputs of jq 1.7, and more cases for `capture`, `tonumber` and the strings of JSON too. ## The numbers | Case | Before, VM | After, VM | Before, Worker | After, Worker | After, mkfifo.com | |---|---:|---:|---:|---:|---:| | Signature of AWS, in a header field | 2.2 ms | 0.56 ms | 7.8 ms | 1 to 4 ms | 2.4 ms | | List of 1,000 keys of S3, as `rclone lsjson` | 803 ms | 162 ms | 1,452 ms | 460 to 500 ms | 341 ms | | `jq` with one value | 0.14 ms | 0.012 ms | 0.37 ms | 0.03 to 0.13 ms | 0.08 ms | | `hmac -K` of 64 bytes | 0.11 ms | 0.021 ms | 0.23 ms | 0.03 to 0.19 ms | 0.03 ms | | scrypt of rclone | 2.0 s | 1.7 s | 0.17 s | 0.17 to 0.22 s | 0.11 s | The small cases in the Worker are ranges of three runs, because of the time of HTTP. The NIFs did not change: scrypt only shows the places. On mkfifo.com, the numbers are of one run. Cloudflare is faster than `wrangler dev` on my computer, by about 1.5 to 2 times: `base64` and `basenc` of 512 KiB give 28 MB/s there, and `gzip` of 1 MiB gives 113 MB/s. For `sha256sum` and `secretbox` of a large body, the time of the upload changes more than the time of the work, so I measure them only in `wrangler dev`. ## One rule Each of these changes made a known builtin faster for each FIFO, and none of them is a builtin for `s3`. That is the rule now: a builtin is a tool that people know, with its usual options, and a FIFO joins the builtins. When a FIFO needs a step that no builtin does, a builtin gets the option of a known tool, as `hmac -K` got the key in hexadecimal of `openssl`.

Show the body Show the header

Egress envelopes of ingress envelope 26

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70b5-a4d3-0ca3fc87351a@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258 Before mkfifo.com, I wrote rfetch: rclone on the APIs of the Web, where each remote is a `fetch()` that takes a request and gives a response. A FIFO has the same shape: a Request goes in, and its answer comes out. So a FIFO can be a remote of rclone. This post tells the first step: a FIFO lists its files to other programs, and the commands of rclone ask a FIFO for its files. ## A method for the list rfetch lists a folder with a `GET`, and reads the links of its HTML page. A FIFO already answers a `GET` with a page, so the list needs a different method. A new method, as `LIST`, cannot work: the edge of Cloudflare answers `501` to a method that is not standard, and the Worker never sees it. `PROPFIND` of WebDAV gets through, and other programs know it: ```sh curl -X PROPFIND -H 'Depth: 1' https://mkfifo.com/blog/2026 ``` A `PROPFIND` is a Request with the path of the URL, the header field `Depth` (the number of levels, as `--max-depth` of rclone), and the query as the fields of a form. As with a `GET`, only an envelope that asks for the method agrees with it. Its answer is the JSON of `rclone lsjson`. A FIFO with no envelope for `PROPFIND` gives an empty list. The files of a FIFO are routes of its holder, and a route can be a secret, as the name of a FIFO. So the holder decides what other people see. ## The commands are clients `ls`, `lsl`, `lsd`, `lsf` and `lsjson` still list the files of their own FIFO with no Request. For a different FIFO, they now send a `PROPFIND`, read the JSON of the answer, and write the format of rclone. The query after a `?` goes with it, as the flags of rclone go in the URL of rfetch: `lsjson crypt/docs?remote=vault`. `cat NAME/PATH` reads a file with a `GET`, as `rclone cat`. The first test found a loop. The envelope for `PROPFIND` of the holder runs `lsjson` of the same FIFO. When that `lsjson` sent a `PROPFIND`, the Request came back to the same envelope, and again, until the limit of 8 hops. Now a FIFO lists its own files itself. ## JSON in JSON An answer of `application/json` gives each value the escapes of a JSON string, so that a capture cannot change the structure of the body. But then the list of `lsjson` came out as one long string. The output of `markdown` already goes into HTML as it is, because a builtin wrote it. Now the output of `lsjson`, and of `jq` with no `-r` and no `-j`, goes into JSON as it is. The holder of `blog` can make its list public with two envelopes: ```envelope To: blog/:path* X-HTTP-Method-Override: ^PROPFIND$ Depth: ^1$ ``` ```envelope To: - Content-Type: application/json \$(lsjson -M blog/\$path) ``` ## The crypt of rclone, as tools The first backend is `crypt`: it encrypts the names and the data of a different remote. My first version had builtins of crypt, `cryptname`, `cryptdata` and `cryptlist`, with the flags of rclone. They agreed with rclone to the byte. But they hid the logic of crypt in Elixir, and they kept the keys of a Request in memory, so that a list and a read made one key. I removed them before the merge. Now there are tools, as the commands of a shell. Each one does one thing, and a pipeline joins them, as the streams of rfetch: - `scrypt` makes a key from the password in its input, as RFC 7914. - `eme` encrypts a short text with EME and AES-256: a segment of a name. - `secretbox` encrypts data with the secretbox of NaCl. With `-b`, it makes a box for each block, with the next nonce: the format of the files of rclone. - `basenc` is `basenc` of GNU coreutils 9.4, and `base32768` is the encoding of rclone for long names. - `obscure` and `reveal` are `rclone obscure` and `rclone reveal`. The keys come from the password, and `cut` takes the key of the data, the key of the names and the tweak from them: ```sh key=\$(printf %s "\$(reveal -- "\$password")" | scrypt -l 80 -S a80df43a8fbd0308a7cab83e581f86b1) ``` A name of rclone is a pipeline, and the data of a file is one more: ```sh printf %s "\$name" | eme -K "\$namekey" -T "\$tweak" | basenc --base32hex -w 0 | tr -d = | tr A-Z a-z cat vault/\$path | secretbox -d -K "\$datakey" -M 52434c4f4e450000 -b 65536 ``` No data stays: the key comes from the password of the Request, and it goes away with the answer. The same tools read a configuration file of rclone with a password (`sha256sum`, `basenc --base64 -d` and `secretbox -d`), so a FIFO can keep the configuration of its remotes encrypted, and only a Request with the password opens it. `basenc -d` needs the padding of base32, as GNU basenc 9.4: with no padding, GNU writes the data but exits with 1. rclone writes no padding, so the pipeline adds it with `sed` first. I read the source of basenc and of gnulib for the rules, and a script compares the builtin with GNU basenc on random options and inputs. It showed one surprise: `--base32hex -d` reads `W` to `Z` as base32, because GNU changes the alphabet before it decodes. The builtin does the same. A second script runs the pipelines in the shell of mkfifo.com, and compares them with rclone 1.75.1 in the two directions: the names in each encoding, the files, a bad block, and the configuration files. It also compares `scrypt` with Python. The key of rclone takes 16 MiB of memory and about 100 ms in V8, but 1.7 s in the interpreter of my tests: it counts 4,194,304 steps of a Request. ## Universal files A FIFO is a file: a `GET` gives its bytes. So a backend of rclone is a FIFO too, as a folder of files, and the builtins of files work with it as with each FIFO: `ls` and `lsjson` list it, and `cat` reads it. The FIFO `rclone` of the site holds the backends, one FIFO for each: `s3` now, `crypt` and `alias` later. Each backend has all its envelopes, with no FIFO for its parts. `cat` is a stream now, as `cat` of a shell. An answer whose body is one `\$(cat FILE...)` sends each file to the client as it comes, and the reply of an HTTP request with `Reply-To: -` does the same. The runtime of BEAM.com gives the body of a `fetch()` to the VM in pieces, with a window, and sends a chunked answer of the VM to the client in pieces. Req reads the next piece in the process of the client, only after the client has the last one. So a file of each size goes through, and the VM keeps only one piece of it. A pipe (`cat FILE | gzip`) still takes all the value, at most 1 MiB. `cat NAME` reads a FIFO itself, as `< NAME`. An error of `cat` shows the path of a file, not its query: the query can have a key. ## The first backend: s3, for R2 The first backend is not `crypt`, but `s3`: the buckets of Cloudflare R2, with the API of Amazon S3. `crypt` needs a remote under it, and `s3` is such a remote: ```sh export R2='-H RCLONE_S3_ACCESS_KEY_ID:ID -H RCLONE_S3_SECRET_ACCESS_KEY:SECRET -H RCLONE_S3_ENDPOINT:https://ACCOUNT_ID.r2.cloudflarestorage.com' curl \$R2 -X PROPFIND -H 'Depth: 1' https://mkfifo.com/s3/BUCKET/docs curl \$R2 'https://mkfifo.com/s3/BUCKET?list-type=2&prefix=docs/' curl \$R2 -L https://mkfifo.com/s3/BUCKET/docs/a.txt ``` The configuration follows rclone: the header fields have the names of the environment of rclone, and a field of the query takes the place of its header field, as a flag. mkfifo.com keeps no key and no file. A `GET` from a client gets a redirect to a presigned URL of R2, and a `PUT` too. A pipe or a FIFO gets the bytes, so a FIFO can give a film from a bucket with one line: `\$(cat "s3/BUCKET/movie.mp4?...")`. `GET /s3/BUCKET?list-type=2` gives the list of S3 as it is, and the answer of a `PROPFIND` reads that list with `cat` and changes its XML into the JSON of `rclone lsjson` with `jq`. My first version had four FIFOs: `s3` for the configuration, `s3api` for the requests, `sigv4` for the signature, and `s3list` for the lists. But `rclone` must hold only backends, as a folder holds folders. Now each envelope of `s3` does its own steps. Two features of the envelopes made this possible: - A Request must agree with only one envelope, but the key can come from a header field or from the query. A line of `jq` in a pattern fails when the configuration is not valid (section 7.8), so the envelope of a valid configuration and the envelope of the `400` never agree with one Request. - The signature is a chain of HMACs: the key of each step is the output of the step before it. `hmac` took its key as text, so I added `-K`, which takes the key in hexadecimal, as `openssl`. Now each envelope signs with `sha256sum` and `hmac -K` in `sh -c`, with no builtin for S3: ```sh key=\$(printf %s "\$day" | hmac "AWS4\$secret"); key=\$(printf %s "\$region" | hmac -K "\$key") ``` The envelopes repeat the configuration and the signature, so a script writes them from one source. The URL of R2 has the account in its host. Before, a URL could have no variable in its host, so that a value could not send a request to a different site. Now a variable can be one full label, before two fixed labels or more: `https://\$account.r2.cloudflarestorage.com/`. When the egress sends, the value must be one label of letters, digits and `-`. A value such as `evil.com/x` makes the egress fail. A `PUT` and a `DELETE` of `/NAME/PATH` got `404` before. Now they are Requests, with their method in `X-HTTP-Method-Override`, and the client cannot change it. `PUT /NAME` and `DELETE /NAME` stay the save and the delete of an envelope. I have no bucket of R2 for the tests. So a stub of R2 in the tests examines each signature with its own code, and a script sends the same Requests to `rclone serve s3`, the S3 server of rclone, which examines each signature with the code of gofakes3, also for a file of 3 MiB through the stream. The keys of the tests have a space, `&` and `<`, because the XML of a list gives them as entities. One question stays: a value in a URL gets percent-encoding, so a `/` of a key is `%2F` in the URL, and the signature has the key with `/`. The server of rclone reads `%2F` as `/`, and so must R2. I could not check this on R2 itself before the merge. ## Keys in a FIFO, and the next page With the key in each Request, each client must know the key. A FIFO can keep it instead: its egress envelope goes to `s3`, with the key in sealed fields. Only the FIFO opens them, and `s3` gets them as header fields. The `To` of a FIFO egress has no variable, because the save examines the graph of the FIFOs, so the path comes in a header field: ``` To: s3 X-HTTP-Method-Override: GET Path: photos/2026/\$file RCLONE_S3_ACCESS_KEY_ID: <sealed:...> RCLONE_S3_SECRET_ACCESS_KEY: <sealed:...> RCLONE_S3_ENDPOINT: https://ACCOUNT_ID.r2.cloudflarestorage.com Reply-To: - ``` My first envelopes for `Path` did not agree with any Request. They were copies of the envelopes of the routes, and those read the key from the query too, with the line `Content-Type: form`. A Request from a FIFO egress has no query and no form, so that line did not agree. The copies now read the key only from the header fields. A list of S3 has at most 1,000 keys. A list with more has `NextContinuationToken`, and `GET /s3/BUCKET?list-type=2&continuation-token=TOKEN` now gives the next page, as in S3. The query of the signature has its keys in order, and a token has `+`, `/` and `=`, so the test gives a token with them. A Request could cause at most 64 egress messages, with its hops and tees. A FIFO that sends a request for each key of a list needs more, and a Worker of Workers Paid can send 10,000 subrequests for each request. The limit is 1,000 now. ## A real bucket, and no list of all the levels Then I got a test bucket of R2, and sent the Requests of `s3` to it through mkfifo.com: the lists, the next page, the presigned links of `GET` and `PUT`, the bytes of a file of 3 MiB, a name with a space, `&` and `<`, `DELETE`, and the keys in sealed fields of a FIFO. All of them worked. R2 reads `%2F` in a path as `/`, as the server of rclone does, so the question above has its answer. One answer was not correct. A `PROPFIND` with `Depth: infinity` of the bucket gave 1,000 of its 1,105 keys, because one list of R2 has at most 1,000 keys. A list of all the levels can be very large, and rclone does not ask for one: it lists one directory at a time, and goes into each directory, to the depth of `--max-depth`. WebDAV lets a server refuse `infinity` (RFC 4918). So `Depth` is now that number, from 1 to 1000. `Depth: infinity`, and a `PROPFIND` with no `Depth`, get `403` with the error `propfind-finite-depth`. The commands do as rclone does. `lsf --max-depth 2 NAME` sends `Depth: 2`. `ls`, `lsl` and `-R` with no `--max-depth` walk: a `PROPFIND` with `Depth: 1` for the path, then one for each directory in it. `s3` lists one level with the delimiter `/`, and a larger `Depth` with no delimiter. An envelope can give the `Depth` to `lsjson`: ```envelope To: blog/:path* X-HTTP-Method-Override: ^PROPFIND$ Depth: ^(?<depth>[0-9]+)$ ``` ```envelope To: - Content-Type: application/json \$(lsjson -M --max-depth \$depth blog/\$path) ``` Each `PROPFIND` and its answer are two messages of the Request, so a walk of more than about 500 directories stops at the limit of 1,000 messages. ## Pages A number in `Depth` stops the large list of all the levels, but one folder can also have more than 1,000 keys, and one list of R2 has at most 1,000. So the answer of a `PROPFIND` can now be one page, and it gives the next page in the header field `Link`, as the APIs of the Web do (RFC 8288): ``` Link: <?continuation-token=TOKEN>; rel="next" ``` The FIFO selects the size of a page. For `s3`, it is the list chunk of rclone, `RCLONE_S3_LIST_CHUNK` or `list_chunk` in the query, and the token is the `NextContinuationToken` of R2. The commands follow each page to the same path, with the fields of their query. A link to a different path is an error, so a key in a query goes only to the same FIFO. An answer can give `Link` only for the next page, on the same site, because a different link could make a browser load a different site. The header field and the body both need the list of R2, and a template has no variable that two lines share. So in one envelope, `cat` of the same files now reads them one time. A `GET` does not change its file, so the second `cat` gets the same bytes, and R2 gets one request for each page. The S3 server of rclone found one more problem. With the delimiter `/` and pages of one key, its token of the third page gave the first page again, and `ls` followed the loop until the limit of 1,000 messages. Now `ls` stops when a link comes back to a page before. R2 gives its pages in the correct sequence: a folder of 1,100 keys in the bucket of the test gave two pages. ## crypt `crypt` now reads a crypt remote of rclone: `PROPFIND /crypt/PATH` lists it, and `GET /crypt/PATH` reads a file. The configuration has the names of rclone again. `RCLONE_CRYPT_REMOTE` is the remote under it, with the configuration of that remote in its query, and `RCLONE_CRYPT_PASSWORD` is the password as `rclone obscure` gives it: ```sh curl -X PROPFIND -H 'Depth: 1' -H 'RCLONE_CRYPT_REMOTE: s3/BUCKET/secret?access_key_id=...' -H 'RCLONE_CRYPT_PASSWORD: ...' https://mkfifo.com/crypt/docs ``` The envelopes are the pipelines above. For a list, a script encrypts each segment of the path, lists the remote with `lsjson --max-depth N`, and then makes one more script with `jq`: for each entry, a pipeline that decrypts each segment of its name. `eval` runs it. A name that does not decrypt is not in the list, as rclone skips it. The size of a file comes from its size in the remote: less the header of 32 bytes, and less 16 bytes for each block of 64 KiB. Each name takes about 4 builtins, and a Request could run 1,024 builtins: a list of about 250 names. I did not want a tool only for the names of crypt, so the limit is now 8,192 runs for one Request. The other limits stay: 16 MiB of work and 10,000,000 steps. Two problems came up. The body of an envelope reads each line alone, so a script in single quotes cannot have more lines: each script of `sh -c` is one line now. Then the list of the remote gave the envelopes of `rclone`, not the bucket. A FIFO lists the files of a FIFO that it holds with no Request, and `rclone` holds `s3`. A script of `sh` has the home `~`, but its lists still had the home of the envelope. Now a list in a script is a Request to the FIFO, as for a client, and a script does not see the envelopes of the holder. The tests use files that rclone wrote. `scripts/s3.sh` copies files into crypt remotes with rclone 1.75.1: names in base32 and in base64, the names of the directories encrypted and not, a second password, an empty file, and a file of two blocks. Then a test reads them through `crypt` and the S3 server of rclone. The name that the builtins make for `big.bin` is the name that rclone wrote. `crypt` only reads now. `PUT` and a sealed password in a FIFO come next. Each backend streams the data to its destination, and keeps nothing. ## Large files of crypt At first, `crypt` gave only files of at most 1 MiB, because `secretbox -d` took all its input as one value. Now `cat` and `secretbox` stream together. In an answer, `\$(cat FILE | secretbox -d -K KEY -M MAGIC -b 65536)` sends each box of 64 KiB to the client when it opens. The pieces from R2 do not have the size of a box, so the stream keeps the rest of a piece for the next one. The nonce of a box is the first nonce plus the number of the boxes before it. The NIF did not change: it opens a list of full boxes, as before. The `GET` of `crypt` needs the key for two things: the name of the file in the remote, and its data. Two runs of `scrypt` take 0.4 s, and most of the steps of a Request. So the `GET` makes the keys one time, and its answer is `cat` of a different file of `crypt`: `crypt?crypt_file=FILE&crypt_key=KEY`. That envelope has no route, and its answer is the stream. The key goes from one envelope to the other in the same Request. The test of rclone has a file of 3 MiB too. rclone writes it with crypt, and the test reads it back through `crypt`, a box at a time. ## Remotes over remotes rclone has backends that read other remotes. `alias` gives a different name to a remote, or to a path in it. `combine` puts each remote in a directory of its own. `union` puts the files of all its remotes in one tree. Now they are FIFOs of `rclone` too. Each remote under them is `NAME/PATH?QUERY`, with its configuration in its query, as the remote under `crypt`. Thus `union` can join two buckets, or a bucket and a `crypt` remote. `union` lists the path in each remote, and keeps one entry for each path. rclone selects that entry with a search policy: `ff` takes the first remote that has the path, and `newest` takes the newest file. The jq of mkfifo.com has no `def`, so the program of `newest` has all the steps that change a time into a number: the days of the date, the seconds, and the offset. The policies that need the free space of each remote get an error for now: R2 does not tell its free space. This time the test compares with rclone itself. The test of rclone starts `rclone serve s3`, then runs `rclone lsjson` and `rclone cat` with the same remotes, for each depth. The first run found a difference that the old tests did not see: rclone gives the size 0 to a directory of S3, and -1 only to a bucket. `s3` gave -1 to each directory. Now it gives 0, and the test compares `crypt` with rclone too. ## Compressed files The backend compress of rclone keeps each file compressed, with gzip or with zstd. Its names have the size of the data: `a.txt.BgAAAAAAAAA.gz` is `a.txt`, with 6 bytes, as a number of 8 bytes in base64url. The jq of mkfifo.com has `@base64d`, but it gives text, not bytes. So the envelope decodes the 11 characters itself: 6 bits for each character, then the 8 bytes. A compressed file can be large, so `gunzip` and a new builtin, `zstd -d`, stream after `cat`, as `secretbox` does. `zstd` is the zstd tool 1.5.7: Erlang/OTP has the same library, and the tests compare the bytes with the tool for each level from 1 to 19. The library did not do two things that the tool does. A frame that stops too soon gave no error, so the builtin reads the header of each frame and of each block, which has the size of the block. And for an empty input, the tool writes the size 0 in the frame, so the builtin does too. The stream of `gunzip` was harder. zlib in Erlang does not tell where the data of a member end: it says `finished` also when its input ends. In a stream, the input ends only with the last piece. So the stream decompresses the first member, and expects its trailer in the last 8 bytes. A small input gets more checks: two members can have the same trailer, and the first property test found exactly that, with two copies of one byte. rclone writes zstd that a reader can seek: frames of 1 MiB, and at the end a skippable frame with the table of the frames. The test of rclone reads these files and the files of gzip with `rclone cat` and with mkfifo.com, and they agree. ## Files in chunks The backend chunker of rclone keeps a large file in chunks: `big.iso.rclone_chunk.001`, `big.iso.rclone_chunk.002`, and the next numbers, and a small JSON object in `big.iso` with the size and the number of the chunks. The list must join the chunks again. rclone does this in `processEntries`: it sorts the names of a directory, so the metadata comes before its chunks, and it puts each chunk in its file. The envelope does the same in one `reduce` of jq. The number of a chunk is a key of an object, not an index of an array: a name with the number 9999999 would make a large array. The `GET` was the hard part. The answer must give the chunks one after the other, as a stream. `cat` takes more files, but each word of `cat` is one file, and the envelope does not know the number of the chunks before the list. A FIFO for each chunk, one after the other, stops after 8 hops. The shell has a tool for this work: `xargs`. Now `\$(LIST | xargs -d '\n' cat)` streams too: `LIST` runs first, then `cat` of all the files streams to the client. The test of rclone writes files in chunks of 1 MiB, with the metadata and with no metadata, and compares `rclone lsjson` and `rclone cat` with mkfifo.com. With no metadata, rclone keeps a small file as one chunk too: `top.txt.part0`. ## crypt writes Until now, `crypt` only read. A file had to come from rclone itself. Now `PUT /crypt/PATH` encrypts the body and `DELETE /crypt/PATH` removes the file, so an app can keep private files in R2 with no key of its own on disk: the password comes with each request, and mkfifo.com forgets it. The pieces were there. `secretbox` already writes the format of rclone: the magic bytes, a random nonce, and a box for each 64 KiB. `eme` and `basenc` already encrypt names for the `GET`. So the envelope of the `PUT` makes the keys with `scrypt`, encrypts the path and the body, and sends the bytes to `s3`. Two things were missing. First, `s3` gave a redirect for each `PUT`, also from a FIFO: the client then sends the plain body to that URL, and the file in R2 is not encrypted. Now a FIFO egress with `Proxy: true` sends its body to R2 itself, signed with `UNSIGNED-PAYLOAD`, as `proxy=true` already gave the bytes of a `GET`. With no `Proxy`, a `PUT` still gets the redirect, for a large file. Second, no envelope could take a body of bytes. A body line does not agree with a body that is not UTF-8, so a photo did not agree with any envelope. I did not want text patterns to find matches in bytes by chance, so only the line of the full body, `(?s)(?<body>.*)`, takes such a body now, with all its bytes. Bytes still cannot go where only text fits. A JSON string, a header field and an email hold only UTF-8 text, and the editor gets each report as JSON. So a capture of bytes in a JSON body, in a header field or in an email makes that egress fail, with an error that says to encode it first, for example with `\$(\$body | base64 -w 0)`. A header field also refuses a control character such as NUL. The editor shows the size of such a capture, not its bytes. A write is one request, so the body is at most 1 MiB, and the output of `secretbox` too: the data are at most 1,048,288 bytes, the 1 MiB less the header of 32 bytes and 16 bytes for each box. The `PUT` makes the keys two times, for the path and for the data. That is about 0.4 s in the Worker, and fine for a photo. The test writes files with mkfifo.com, then reads them with `rclone cat`: a file of two boxes with random bytes and a line break at its end, an empty file, a file of exactly 1,048,288 bytes, and the names in base32 and in base64. ## The backends move to rfetch Everything above is the work of rclone, done again with builtins in envelopes: the signatures of S3, the names and the data of crypt, the lists of the backends over backends. It works, but each new backend was a lot of jq, and each fix had to happen twice: once in rfetch, my port of rclone to JavaScript, and once in the envelopes. rfetch now runs as a Worker of its own at `rfetch.pages.dev`, with its own tests against rclone, and it already has these seven backends and more. So the envelopes of `rclone` now send each request to rfetch, and give its answer to the client. mkfifo.com still keeps no file and no key, and rfetch keeps nothing between requests either. The options were the hard part. My first try named each option in each envelope, in three places, `RFETCH_S3_ACCESS_KEY_ID`, `RCLONE_S3_ACCESS_KEY_ID` and `access_key_id` in the query, and sent each one on under the same name. It was explicit, but a FIFO is for the people who call it, and they know the options of rclone, not my list. An option that I forgot could not get through, and a remote inside `crypt` could not get its own options at all. So the options now pass through as they come. Two parts of that are new in mkfifo.com: - A route can match the query too, the way `URLPattern` does in a browser: `To: s3/:path*\?:query*` captures the whole query in `\$query`, and the egress sends `?\$query` to rfetch. I check these routes against `URLPattern` of Node.js with thousands of random routes and queries. - An egress header line like `RFETCH_*:` copies each header field of the request whose name starts with `RFETCH_`. Fields of Cloudflare, of mkfifo.com and of the connection, and cookies, never get copied. Secrets still go in header fields, and the other options in the query. Nothing else from the request goes to rfetch. Two more small changes made this work: - A route like `s3/:path*` captures a path with `/` in it. In the URL of an HTTP egress, each variable got percent-encoding, so `a/b.txt` became `a%2Fb.txt`. Now a capture of the route keeps its `/` in the path of the URL, and a capture of the query keeps its `&` and `=` in the query. They are still encoded everywhere else. - The answer of a reply kept only `Content-Type` and `Location`. Now it also keeps `Content-Range`, `Accept-Ranges`, `Last-Modified` and `ETag`. So `curl -r 0-99` gets the first 100 bytes of a file, and a download can resume. Some things went away. `s3` gives no redirect to a presigned URL now: the bytes go through rfetch, so a `PUT` is at most 1 MiB for now. A `PROPFIND` is one list from rfetch, with no pages. The HTTP egress cannot send `PROPFIND`, so the envelope sends a `GET` with `Accept: application/json` and the `Depth`, and rfetch answers it with the same list. A remote under `crypt` or `union` is now a remote of rclone, like `:s3,access_key_id=...:bucket`, not the path of a FIFO. rfetch reads only the default names of crypt: base32, with the names of the directories encrypted. With no check, a request for names in base64 would read and write the wrong names. So `crypt` answers 501 to each other name option, and the request goes nowhere. The 102 files of the seed and their three scripts became 60 files from one small script. With the options passing through, a new backend is one more line in that script, so the other backends of rfetch are FIFOs now too, in 114 files: `archive`, `azureblob`, `doi`, `drive`, `ftp`, `http`, `sftp`, `tiles` and `webdav`. Only `local` and `memory` stay out: the Worker has no local disk, and a memory remote would put the files of different people in one place.

Show the body Show the header

Egress envelopes of ingress envelope 27

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70bc-9847-e169b1d1be35@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

I made a set of decisions about links, the sign-in and the words on the site. Each one fixes something that surprised people. ## A link is a symbolic link A FIFO in your home can link to a public FIFO with `Bcc: my-shop`. Until now, the loop check at save time counted that link as part of the graph. So the owner of `my-shop` could get "This To makes a loop of FIFOs" because of a link they could not even see. Unix solved this long ago. A symbolic link only points to a file, and takes no part in what the file does. A loop of symlinks is not refused when you create it: it fails when you follow it, with `ELOOP`. Links now work the same way: - A link is not an edge of the graph, so a save never fails because of someone else's link. - A Request that goes through a link remembers the FIFOs it passed. If it comes back to one of them, through an egress, a pipe, `tee`, a redirection, `Reply-To` or `Errors-To`, it stops there, and the report says why. - A link to a free name keeps the name free. A Request to that name still gets 404, and anyone can still take the name. Before, a link quietly made the name look used. ## Fairer sign-in codes The sign-in allowed 5 wrong codes for each email address in 15 minutes. That stops guessing, but it also let anyone who knew your address lock you out with 5 wrong codes. Now 5 wrong codes from one network address only block that network address. A second limit, 50 wrong codes for your email address from everywhere, keeps guessing slow: 50 tries in 15 minutes, against 100,000,000 possible codes. ## Sign in with the link only The sign-in email had a link and a code to type. A code that you type can be typed in the wrong place: any page can show a form that asks "Enter the code we just sent you". So now there is nothing to type. The email has only the link, and the sign-in form has only Email. The link opens a page with your address and one **Sign in** button, and that button sends the code. Opening the link alone does nothing, so a mail scanner that opens links does not use up your code. The email also says it plainly: mkfifo.com never asks you to type a code. ## Email to yourself mkfifo.com sends email only for its own FIFOs, so nobody can use it to send spam. But one wish comes up again and again: "send each message of my contact form to my inbox". A FIFO in your home can now email the address that you sign in with, at most 10 emails an hour: the sign-in already proved that the address is yours. Put `To: you@example.com` in an egress envelope of `~/inbox`, add `Bcc: my-contact` to its ingress envelope, and each message to the public FIFO `my-contact` reaches you. To email anyone else, you still use your own email provider. ## A warning for pipe names In `\$body | rev`, `rev` is not a builtin, so the body goes to the public FIFO named `rev`, and anyone can create that FIFO. A typo can send your data to a stranger. I thought about a separate syntax for a pipe to a FIFO, but a typo there still goes to a FIFO. So the editor now warns after a save when a pipe or a `tee` goes to a public FIFO that has no envelopes yet. ## `ls ~` `ls ~` in the terminal showed nothing: `rclone ls` lists files, and the FIFOs of a home were not files. Now a listing of your home shows the FIFOs in it with their paths, as `rclone ls` does: `club`, `work` and `work/2026`. ## Dates on the blog, and a security page Each post now keeps the day it was first written in `Date`, and the time of its last change in `Last-Modified`. The page, the list and the Atom feed show both. Before, each addition to a post moved its date. The security model is now a section of [the docs](/docs#security), not a blog post: it is reference text, and it changes with the product. ## One time for each Request A check found a bug that was not about any of this. The FIFO `s3` signs each request to R2: the time goes in the header `X-Amz-Date`, and again into the signature. Each `\$(date)` read the clock on its own, so when a second ended between the two, R2 refused the signature. Now a Request has one time, from when it comes in: every command, every egress and every Request it causes see the same time. ## Plain words The code and its docs use Simplified Technical English, a controlled language with a small vocabulary. On the pages for visitors, it read stiffly: a Request "agreed" with an envelope, a form was a "letter", and the buttons said "Push". These pages now use plain English: match, people, message, Click. The specification and the code stay in the controlled language, where one word for one meaning still helps.

Show the body Show the header

Egress envelopes of ingress envelope 28

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70c3-bd9d-e251c049380b@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32"> <rect x="1" y="5" width="30" height="22" rx="3" fill="#e9d7b3" stroke="#5a4a32" stroke-width="2"/> <path d="M2.5 7.5 16 18l13.5-10.5" fill="#e0ca9e" stroke="#5a4a32" stroke-width="2" stroke-linejoin="round"/> <rect x="20" y="8" width="8" height="9" rx="1" fill="#1f4d7a" stroke="#fffefb" stroke-width="1.5"/> </svg>

Show the body Show the header

Egress envelopes of ingress envelope 29

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70ca-8200-ef3e439d054e@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

Each model is made from real parts, in real sizes, by [World](https://world.mkfifo.com). Open a model for the list of its parts: what to buy to build it. $(cat "http/models/list.json?url=https://world.mkfifo.com/" | jq -r '.[] | "- [\(.)](/world/models/\(.)/parts)"' | markdown)

Show the body Show the header

Egress envelopes of ingress envelope 30

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70d1-9cd9-dd25be63b071@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(cat "http/models/$name.parts.json?url=https://world.mkfifo.com/" | jq -r '"| Count | Part | Kind | Source |", "| ---: | --- | --- | --- |", (.parts[] | "| \(.count) | \(.name) | \(.kind) | \((.sources[0] // "") | gsub("\\|"; "/")) |"), "", (.parts | map(.count) | add | if . == 1 then "1 part in all." else "\(.) parts in all." end)' | markdown) [The 3D model](https://world.mkfifo.com/models/$name.mid.glb) · [The parts as JSON](https://world.mkfifo.com/models/$name.parts.json) · [All the models](/world)

Show the body Show the header

Egress envelopes of ingress envelope 31

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70d8-9ee4-09bf3481ee96@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(cat "http/o/$hash.parts.json?url=https://world.mkfifo.com/" | jq -r '"| Count | Part | Kind | Source |", "| ---: | --- | --- | --- |", (.parts[] | "| \(.count) | \(.name) | \(.kind) | \((.sources[0] // "") | gsub("\\|"; "/")) |"), "", (.parts | map(.count) | add | if . == 1 then "1 part in all." else "\(.) parts in all." end)' | markdown) [The 3D model](https://world.mkfifo.com/o/$hash.mid.glb) · [How the world built it](https://world.mkfifo.com/replay.html?order=$hash) · [The parts as JSON](https://world.mkfifo.com/o/$hash.parts.json)

Show the body Show the header

Egress envelopes of ingress envelope 32

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70df-b14d-99cfd8220a54@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(sed 's/viewBox="0 0 32 32"/viewBox="-4.5 -4.5 41 41"/' < favicon.svg | resvg -w 180 --background '#dde2ea' - -c)

Show the body Show the header

Egress envelopes of ingress envelope 33

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70e8-bdbb-9e2ad75d42c6@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

# mkfifo.com: named pipes for webhooks, forms and emails. # This file is the answer of a FIFO: https://mkfifo.com/mkfifo User-agent: * Allow: / Sitemap: https://mkfifo.com/blog/feed.xml

Show the body Show the header

Egress envelopes of ingress envelope 34

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70ef-87ed-bebf8cd22baa@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

# This host is not mkfifo.com: a copy of the site is not for search. User-agent: * Disallow: /

Show the body Show the header

Egress envelopes of ingress envelope 35

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-70fa-9933-7f989f9084fe@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(resvg -w $width - -c < favicon.svg)

Show the body Show the header

Egress envelopes of ingress envelope 36

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7107-a87d-5fad9e56b0a1@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -quality 100 ${format}:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 37

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7112-8ae9-09c50266af8c@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "x${height}>" -quality 100 ${format}:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 38

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-711d-bdaf-bde77e687b7e@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "x${height}>" -background white -flatten -quality 85 jpeg:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 39

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7128-9e83-ddae9e97ecc0@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "x${height}>" - < $src)

Show the body Show the header

Egress envelopes of ingress envelope 40

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7133-994d-e0b2c0b86f41@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -background white -flatten -quality 85 jpeg:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 41

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-713e-8678-ca67e074393a@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x>" -quality 100 ${format}:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 42

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7149-8944-c663913f407e@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x${height}>" -quality 100 ${format}:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 43

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7154-87d4-39b0dbacc39f@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x${height}>" -background white -flatten -quality 85 jpeg:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 44

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-715f-ab55-a56552a90b78@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x${height}>" - < $src)

Show the body Show the header

Egress envelopes of ingress envelope 45

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-716a-8a86-283614570474@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x>" -background white -flatten -quality 85 jpeg:- < $src)

Show the body Show the header

Egress envelopes of ingress envelope 46

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-7175-8129-d5209ad17009@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

$(magick - -auto-orient -strip -thumbnail "${width}x>" - < $src)

Show the body Show the header

Egress envelopes of ingress envelope 47

Egress envelope 1

In reply to an ingress envelope of this FIFO

To:

Other header fields of Egress envelope 1
Seal: mkfifo.com encrypts the value when you save, and never shows it again.

Message-ID <01a18fc1-8eb5-717c-9ac5-a9b9225a943b@mkfifo.com>

Body of egress envelope 1
The text of the message. $name inserts a capture from the ingress envelope.

<svg xmlns="http://www.w3.org/2000/svg" width="$width" height="$(jq -nr --arg w $width --arg h "$height" 'if $h == "" then $w else $h end')" viewBox="0 0 $width $(jq -nr --arg w $width --arg h "$height" 'if $h == "" then $w else $h end')" font-family="system-ui, sans-serif" font-size="10" text-anchor="middle" dominant-baseline="central"> <rect width="100%" height="100%" fill="#dddddd" style="fill: $bg_color; fill: #$bg_color"/> <g fill="#666666" style="fill: $text_color; fill: #$text_color"> <text transform="$(jq -nr --arg w $width --arg h "$height" --arg t "$text" --arg d "$dims" '($w | tonumber) as $w | (if $h == "" then $w else $h | tonumber end) as $h | ($t | length) as $n | (if $d == "false" then 0 else "\($w)×\($h)" | length end) as $m | (if $n > 0 then [$h * 0.16, 1.5 * $w / $n] | min else 0 end) as $cs | (if $m == 0 then 0 elif $n > 0 then [$cs * 0.5, 1.5 * $w / $m] | min else [$h * 0.2, 1.5 * $w / $m] | min end) as $ls | (if $n > 0 and $m > 0 then $cs * 0.4 else 0 end) as $gap | (($h - $cs - $gap - $ls) / 2) as $top | "translate(\($w / 2) \($top + $cs / 2 | . * 10 | round / 10)) scale(\($cs * 10 | round / 100))"')">$text</text> <text transform="$(jq -nr --arg w $width --arg h "$height" --arg t "$text" --arg d "$dims" '($w | tonumber) as $w | (if $h == "" then $w else $h | tonumber end) as $h | ($t | length) as $n | (if $d == "false" then 0 else "\($w)×\($h)" | length end) as $m | (if $n > 0 then [$h * 0.16, 1.5 * $w / $n] | min else 0 end) as $cs | (if $m == 0 then 0 elif $n > 0 then [$cs * 0.5, 1.5 * $w / $m] | min else [$h * 0.2, 1.5 * $w / $m] | min end) as $ls | (if $n > 0 and $m > 0 then $cs * 0.4 else 0 end) as $gap | (($h - $cs - $gap - $ls) / 2) as $top | "translate(\($w / 2) \($top + $cs + $gap + $ls / 2 | . * 10 | round / 10)) scale(\($ls * 10 | round / 100))"')">${width}×$(jq -nr --arg w $width --arg h "$height" 'if $h == "" then $w else $h end')</text> </g> </svg>

Show the body Show the header

Egress envelopes of ingress envelope 1

Egress envelopes of ingress envelope 2

Egress envelopes of ingress envelope 3

Egress envelopes of ingress envelope 4

Egress envelopes of ingress envelope 5

Egress envelopes of ingress envelope 6

Egress envelopes of ingress envelope 7

Egress envelopes of ingress envelope 8

Egress envelopes of ingress envelope 9

Egress envelopes of ingress envelope 10

Egress envelopes of ingress envelope 11

Egress envelopes of ingress envelope 12

Egress envelopes of ingress envelope 13

Egress envelopes of ingress envelope 14

Egress envelopes of ingress envelope 15

Egress envelopes of ingress envelope 16

Egress envelopes of ingress envelope 17

Egress envelopes of ingress envelope 18

Egress envelopes of ingress envelope 19

Egress envelopes of ingress envelope 20

Egress envelopes of ingress envelope 21

Egress envelopes of ingress envelope 22

Egress envelopes of ingress envelope 23

Egress envelopes of ingress envelope 24

Egress envelopes of ingress envelope 25

Egress envelopes of ingress envelope 26

Egress envelopes of ingress envelope 27

Egress envelopes of ingress envelope 28

Egress envelopes of ingress envelope 29

Egress envelopes of ingress envelope 30

Egress envelopes of ingress envelope 31

Egress envelopes of ingress envelope 32

Egress envelopes of ingress envelope 33

Egress envelopes of ingress envelope 34

Egress envelopes of ingress envelope 35

Egress envelopes of ingress envelope 36

Egress envelopes of ingress envelope 37

Egress envelopes of ingress envelope 38

Egress envelopes of ingress envelope 39

Egress envelopes of ingress envelope 40

Egress envelopes of ingress envelope 41

Egress envelopes of ingress envelope 42

Egress envelopes of ingress envelope 43

Egress envelopes of ingress envelope 44

Egress envelopes of ingress envelope 45

Egress envelopes of ingress envelope 46

Egress envelopes of ingress envelope 47

Make your own FIFO like this one