Thanks fixed now… added the ! manually after selecting with the [[ not sure why it didn’t work

@Aneesh Sathe thus hasn’t rendered properly

Trying out Rex now

![[7b60fj8nxa0j6rgkn0j8jyhsqx | “Signed up for the Rex waitlist... https://www.superlogical.c…”]]

from blyg.aneeshsathe.com ↗ · snapshot of v1

from Venkatesh Rao's Blyg ↗ · snapshot of v1

🌿 Burrow 0.20 is out: room to think beside your draft

🍃 Notes stay open while you write. They sit in a pane beside the editor now, so clicking back into your draft doesn't close them. ⇧⌘N moves into your notes, esc takes you back to the caret, and Quote into post drops a passage right where you were. 🦔 Nearby thoughts is a drawer behind its own tab at the right edge. It stays out of the way until you want it, then stays open until you close it.

🪵 Resize anything. Drag the line between the editor and the preview, or the edge of a pane. A double-click resets it, and Burrow remembers your layout.

🍄 The web app shows what it can do. On a phone, a new Blyg tab lists settings, mentions, hoppers, subscriptions and your shelf by name. On a desk, a row over the editor names what you can do with the post.

🌱 Each release now includes the web app, so you can run it from your own blyg: https://aneeshsathe.github.io/blygger-desktop/web-self-host.html

Update from the status bar, or grab it here: https://github.com/aneeshsathe/blygger-desktop/releases/latest

Tell me what you write beside your notes 🐾

Burrow 0.17 to 0.19: the thicket grows 🌿

Three Burrow releases in a week, and a whole lot of new growth. Burrow now does just about everything Studio does, it's quick with thousands of posts, and there are fresh paths to explore all through the undergrowth. Here's a field guide 🐇

🌳 0.19.0: run your whole blyg from Burrow

• 🎨 Blyg › Site…: give your public pages a new look. Pick a theme or design your own with a live preview, choose a typeface, a front page and the menus on every page, and set your avatar. Nothing changes until you press Save
• 🪺 Blyg › Contacts…: an address book for the people you write about. Type @ and they come first, and the preview shows the link your blyg will publish. Add the author of a post you're reading in one go, or when you subscribe to their blyg
• 🍄 Stale Quotes…: when a post you quoted gets a new version, your thread shows ↻ and one click refreshes the quote
• 🔑 Client Access…: see every app and token that can act as you, make a new token, and revoke any of them
• ✨ AI on Your Blyg…: if your blyg has its own AI, Burrow can draft your version notes and tell you whether a change looks like a typo, minor or major. You always get the last word
• 💌 Mentions › Sent: see the mentions your blyg sent out, and whether each one landed. Subscriptions now say when they were last checked, and why one is struggling
• 🌾 Little treats: a word-by-word diff between versions of your posts (⌘Y), Threads / Fragments / Thumbed down feeds, your likes and activity in Blyg › Signals…, alt text for images, and Copy Link
• 📱 Burrow in a browser grew up: subscriptions, mentions, hoppers, 👍 / 👎, image uploads, versions, forks and your blyg's settings, all from your phone

🌱 0.18.1: a tidier burrow

• 🐇 Burrow in a browser is fast on a phone, even with thousands of posts to read. Opening a post takes a blink, and it stays open
• 🦔 Nearby thoughts behaves: its keys keep working after you click a row, and resting the mouse on a suggestion shows you the post
• 🍃 "What's new" is a short note now, with a link to proper release notes

🌲 0.18.0: new paths through the thicket

• 💬 #thicket (⇧⌘I, experimental): a chat tab to talk with other Burrow folk on Libera.Chat (IRC), with a nudge when someone mentions you. Nothing connects until you set it up. Come say hi! 👋
• 📚 The shelf (⌥⌘B): keep the posts you keep updating, like a /now page or a reading log, at the top of your list. ⌘B opens it
• 🧭 The command palette (⇧⌘P): every action, theme, blyg, hopper and post, by name
• 🌫️ Focus mode (⌥⌘F): just you and the line you're writing, everything else gently dimmed
• 🦔 Nearby thoughts: a rail beside the editor shows your posts that say what your paragraph says. ⌥⏎ links one and ⌥⇧⏎ quotes it, and an optional small model that runs on your computer matches meaning, not just words
• 🧵 Lineage while you write: a quiet line shows what your post draws on and what draws on it. The lineage map zooms out two hops each way
• 🔍 Hover cards: rest the pointer on a link or quote to see what it is
• 🥾 Trails: press t while reading to drop a post on a trail with a word on why, then turn the trail into a thread of quotes
• 🖐️ Drag to quote: drag a post into what you're writing, or keep a few on the quote tray for later
• 🪟 Split view (⌥⌘⏎): the post you're reading beside the one you're writing
• 🧶 Loose ends: search for is:orphan, is:draft, has:tk and friends, and a quiet line tells you what's left dangling
• 🍀 Serendipity (turn it on in Settings): a new post's empty page shows one of your older posts, to quote, link or wave goodbye to
• 📎 Capture from anywhere: select text in any app, then Services › Capture in Burrow
• 🖥️ A terminal pane (⌃`, experimental): your own shell under your posts
• 🌐 Burrow in a browser first sprouted here, ready for your phone

🐿️ 0.17.0: quick in a big forest

• ⚡ Burrow stays quick with thousands of posts to read: lists, search and marking posts read are many times faster
• 🧺 Pick several posts and press h to put them all in a hopper at once
• 🎨 The reader follows Burrow's theme
• 🔀 Switching between blygs is safer and works on Windows

🐾 Try it

• Already using Burrow? It updates itself. Restart when it asks, and the tour walks you through what's new
• New here? Grab it for Mac or Windows from the releases page
• Then try ⇧⌘P, wander into the Blyg menu, and drop by #thicket to tell me what you found 🌿

Every bump you hit in the undergrowth helps, so send them my way 🦔

I have high desire to build things with AI but low for getting into fitness again. Considering a reward ladder where i’m allowed to build increasingly complex (and fun) things with Claude around fitness only when I have sufficient data captured to warrant that feature.

from blyg.aneeshsathe.com ↗ · snapshot of v1

What kind of physical activity do you enjoy out of curiosity? A silly riff on the idea of linking irl fitness activity to the digital world https://pioneeringspirit.xyz/forging-the-future-protocols-of-strength-and-spirit

from Pioneering Spirit (Blyg) ↗ · snapshot of v1

anything is good, but i like to run. On a long enough road, a motorcyle is my preferred form of exercise... but that's not an option anymore, given the participation in the Bluey fandom.

This time i'm gonna try to do more strength training as well, and looks i'm gonna be a part of the Forge in this thickety way

this is gonna be big release

trying out the Simon Willison approach by telling the agent to make Burrow "extremely fun".

if you don't see any changes assume the approach failed

fragment ↗ · snapshot of v1

W00T~~!!

Cognitive mercantilism got covered in the Financial Times

Swap the word intelligence for wealth, Rao argues, and you are harking back to the conceptual universe of the early 18th century. Cognitive mercantilists, who are more interested in capturing wealth than creating it, view intelligence as a precious resource to be tightly controlled by credentialed professionals. Countries and companies scour the world to collect the best brains and hoard them like gold. Conversely, they dismiss the less intelligent “masses” as depreciating assets at risk of becoming superfluous humans.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

Nice parking spot, Rita.

Any Bluey fans in the Thicket?

from Pioneering Spirit (Blyg) ↗ · snapshot of v1

Burrow is being updated to match the new functionality. Burrow had some version of mentions already. It will use the default way now.

Also adding a couple of more Burrow specific customizations like being able to pin a thread so that you can find and update it easily

Okay so mentions are finally here in Studio. Other full-featured clients should plan to support this.

Built against RFC-1/TN-6 and incorporating a suggestion from @Aneesh Sathe about found mentions (since mentions don’t send notifications they have to be discovered in inbound feed items on the receiving side)

What a mention is

Type @ada while writing. When you publish, it becomes a link to Ada, under the name you gave.

That's most of it. The handle ada is your own shorthand and stays private to you. Readers see "@Ada Ruiz", linked to wherever you said Ada can be found.

A mention notifies nobody. It's closer to writing someone's name with a link than to tagging them on a social network. Nothing is sent to Ada, and no count of mentions exists anywhere.

from Blygger ↗ · excerpt of v1

And re found mentions

Finding out when someone mentions you

Since a mention notifies nobody, how would you ever know? Your own reader can look.

from Blygger ↗ · excerpt of v1

Also since mentions now means people, quotes and stubs are now called responses even though they use the webmention protocol.

Mentions are ordinary links but carry rel=me/h-card data invisibly with other socials for clients that understand that convention.

Quick background on the two conventions, since mentions lean on both.

rel=me is a microformat for saying "this other page is also me." You add rel="me" to a link pointing at one of your profiles elsewhere, such as a Mastodon account or a GitHub page. It becomes verifiable when the link goes both ways: if that profile links back to your page with rel="me" too, a client can be fairly confident the same person controls both. It's the same mechanism Mastodon uses for its green checkmark on profile links, and IndieAuth uses it for sign-in.

h-card is a microformats2 vocabulary for describing a person or organization in ordinary HTML. Class names mark up the pieces: h-card on the container, p-name for the display name, u-url for the main link, u-photo for an avatar, and so on. A parser reads those classes and gets structured profile data, with no separate API or JSON needed.

Together, a mention can be a plain link to a human and still say who that person is and where else they live online.

Thanks to Aneesh for helping think this through.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

Fitness and AI Tool Dev Thread

20261106

Ok started this, reached level 0 and am only allowed to build a CLI logging tool. which took all of 20s to implement :D.

Next qualifying level, L1, is at 6 active days over 14 days. Which means i have to actually use the cli tool.

I have high desire to build things with AI but low for getting into fitness again. Considering a reward ladder where i’m allowed to build increasingly complex (and fun) things with Claude around fitness only when I have sufficient data captured to warrant that feature.

fragment ↗ · snapshot of v1

Seems to work

Testing a rudimentary address mechanism

@Aneesh Sathe mention here -- should go to his blyg

from Venkatesh Rao's Blyg ↗ · snapshot of v1

RFC-1 Comments:

Yes to mentions, and please give the Studio a Mentions view to go with them.

I'd use the address book and @handle autocomplete on day one. Seeding it from my subscriptions makes sense, since most of the people I'd mention are already in my reading list. Petnames locally and checked identifiers on the wire sounds right to me.

My one ask is about the other end. Ruling 2 says a mention doesn't notify, and I can live with that as a wire rule. But if nothing tells me when I'm mentioned, the feature only works for the person doing the mentioning. I'd like the Studio to find mentions without anything being sent: when an imported item's content_html has an h-card whose u-url (or one of its ids) matches my own author.url or author_links, list it in a Mentions tab, next to the verified Webmentions the Studio already shows. That's my reader looking at what I've chosen to read. Nobody is notified and the protocol doesn't change, so it stays within ruling 2.

Ideally I should be able to see mentions even from feeds i am not subscribed to.

RFC-1 — Mentions across identifier schemes: petnames in the studio, full identifiers on the wire

Request for comments · non-normative · OPEN FOR COMMENT until 2026-11-04 on blyg.blygger.org (#66); without a blyg, comment on blygger-spec#14 · session 40, 2026-10-07. Drafted by Opus 5.5 at Venkat Rao's request; edited the same session by Fable 5.1, whose rulings on the five open questions are section 10. An RFC is a recommendation put up for comment before any client builds it, because the reference client shipping a convention reads as a blessing. Like a technical note, an RFC constrains nothing. After its comment period and the gate in section 10, ruling 1, it becomes a technical note. It builds on locked decisions #11 (the opaque author), #35 (identity practice, proposed in docs/proposals/identity-practice-proposal.md, which becomes tn-2), #36 (groups, tn-3), #20 (studio grammar versus wire grammar) and #32 ([[id]] is silent). Written against protocol 0.3 as published on 2026-10-07; no pre-1.0 version promises anything (#21).

1. The question

Several early users have asked for multi-author blygs, and with them comes a second request: @-mentions of the people who write there and of people elsewhere. The request (Venkat Rao, session 40) was for three things:

1. a consistent recommendation for user identifiers within a domain that can travel through the protocol;
2. an evaluation of how markup in the item body could carry the major identifier schemes — W3C DIDs, Ethereum accounts, ActivityPub, ATProto and h-card — so that clients sharing a convention can resolve @-mentions;
3. a convention in which the client keeps an address book of contacts across schemes. The author types a short @handle, the client looks up the full identifiers in that address book, and the full identifiers travel on the wire, so that another client can resolve whichever scheme it speaks.

The third request is the design. Sections 2–4 clear the ground, section 5 is the convention, and sections 6–9 cover reading, scheme details, the reference client's default and what is rejected. Section 10 records the rulings.

The constraints are fixed. Authors are never addressable (§5.5, §16.8). The protocol has no reply primitive and no fourth mention relation (§16.8). The protocol has no normative write surface (#31), so nothing here comes from Micropub, in keeping with that decision while staying close to the IndieWeb in spirit. Whatever this RFC recommends has to be HTML and studio practice, not protocol.

2. Correcting a premise: the single author does not block multi-author blygs

The worry was that an item's author field holds only one name, so a multi-author blyg would have to sign everything as "community" unless the spec changed in a way that breaks RSS. Two parts of that are true and one is not.

• A multi-author blyg does not need more than one name per item. author is per-item (§5.5). A masthead blyg with five writers publishes items whose bylines differ item by item. That is shape B of tn-3, specified since #11, and the feed rule is single-publisher, never single-author. "Community" is only needed if you want it: the Protocol Institute node already uses the byline "Editor".
• RSS is not the binding constraint. In RSS 2.0, the core <author> element is a single email address, and the protocol does not emit it. The feed carries <dc:creator> (§7). Dublin Core lets that element repeat, and Atom allows several <author> elements. Many feed readers show only the first creator, which is a display limit, not a format limit.
• The real single-valued thing is the protocol's own §5.5. author is one JSON object. Only co-authored items need more than one person in it, and §5.5's extension point already lets them carry more without a spec change (section 4.1 below).

So multi-author blygs work today and need nothing from the protocol. What the reference client lacks is studio-side: one author_name setting stamps every item (protocol.ts sets author.url to the origin). That is a client gap, and section 8 addresses it.

The census, re-run 2026-10-07 against the 20 blygs listed at blygger.com (19 reachable), the three newest items each: every item author is {name, url}, {name}, or absent. No client has invented an authorspace grammar, no item has two people in it, and no body contains an h-card or mention markup. Manifest-level author has grown bio, links and avatar in several clients. The per-item field is still empty, so this is still the cheapest time to recommend something.

3. Identifiers within a domain

In shape B (one origin, many bylines), what identifies a member? The answer follows from #35's spine — a person is a URL they control — with one concession for people who have no URL of their own:

Member has…	author.url	What it proves
their own site, profile or actor URL	that URL	portable. If the page links back (section 5.5), a reader can confirm the byline from the member's side.
nothing of their own	a house-hosted member page, e.g. https://house.example/people/alice/	only that the house says so. That is honest: in shape B the house answers for everything (tn-3 section 5).

The member page is presentation. It is an HTML page like any page, not a protocol construct, so it does not make authors addressable in §16.8's sense: nothing in the protocol references it. It has a second job, which section 5.5 gives it: it is the origin-side end of the reciprocal proof for a member who does have their own URL. A member who later moves to their own origin (shape A) takes their own URL with them. A house URL does not travel. That is the practical reason to prefer the member's own URL whenever they have one.

No user@domain grammar inside an origin. @alice as typed in the studio is a petname, a name that is meaningful only in this address book (section 5). It never reaches the wire as an identifier. DNS remains the namespace (#11).

4. The five schemes, evaluated

Each scheme answers four questions:

• What is its stable identifier, as opposed to its human-readable name?
• Can a reader resolve it with an ordinary fetch?
• How does a person prove control of it?
• What does it reduce to under #35's two proofs: a reciprocal link, or a signature?

Scheme	Human name (mutable)	Stable identifier to put on the wire	Resolution	Proof	Reduces to
Web / h-card	the URL itself	https://alice.example/	fetch, then parse the representative h-card	rel="me" reciprocal links	link (it is #35)
ActivityPub	@alice@social.example	acct:alice@social.example (RFC 7565), plus the actor's https URL	WebFinger (RFC 7033) maps acct: to the actor URL	Mastodon-family servers check rel="me" on the links in a profile and serve rel="me" on profiles themselves	link
ATProto	handle alice.example or alice.bsky.social	the DID, usually did:plc:…	DNS TXT _atproto.<handle> or https://<handle>/.well-known/atproto-did, and the DID document's alsoKnownAs points back	two-way handle↔DID binding. A domain handle is DNS control.	link (a domain handle is a URL the person controls)
W3C DID	none	did:<method>:…	method-specific. did:web is an HTTPS fetch. did:plc needs a directory. did:key and did:pkh resolve locally.	did:web: DNS. Others: a key in the document	did:web reduces to a link. The others reduce to a signature.
Ethereum	ENS name alice.eth	the account as a DID, did:pkh:eip155:1:0xAb… (the CAIP-10 account eip155:1:0xAb… wrapped; see section 7)	ENS needs chain access (an RPC endpoint); the account needs nothing	EIP-191 signature (e.g. over content_hash, #35 §4.2); EIP-4361 for sign-in	signature

Four observations decide the design.

1. h-card is not a rival scheme. It is the envelope. It is the IndieWeb's format for "here is a person and their identifiers": p-name, u-url (which may repeat), u-uid, and u-key. Every other row can be written inside an h-card. That makes it the natural carrier for request 3, and it is already how Mastodon marks up mentions in HTML (<span class="h-card"><a class="u-url mention" href="…">@<span>alice</span></a></span>).
2. Put the stable identifier on the wire, never the name. ENS names expire and transfer, ATProto handles change, and fediverse accounts migrate. The address, the DID and the actor's acct: are what a distant reader can still match a year later. The web is the exception, because the URL is both the name and the identifier. That is exactly why #35 chose it.
3. Three of the five reduce to "a URL the person controls". Those are the web, ActivityPub, and ATProto with a domain handle. did:web joins them. Only did:plc/did:key and Ethereum need a signature or a non-HTTP resolver. The default can therefore stay boring (section 8) and lose almost nothing.
4. The schemes differ in cost to the reader, not just in reach. Resolving an ENS name needs chain access, and did:plc needs a third-party directory. A static reader cannot do either. Any convention has to work for a reader that resolves nothing, and that pushes the visible fallback onto a plain https link.

A fifth, smaller observation sets the wire vocabulary: with Ethereum accounts written as did:pkh:, everything on the wire is an https:, acct: or did: URI. Three schemes, three normalization rules (section 6), and a matcher needs nothing else.

4.1 What author can carry for co-authored items

A co-authored item keeps one author object, as §5.5 requires. It can use the extension point §5.5 grants, so no spec change is needed:

"author": {
  "name": "Alice Ng and Bob Ruiz",
  "url": "https://house.example/",
  "coauthors": [
    { "name": "Alice Ng", "url": "https://alice.example/", "ids": ["did:plc:7iza6de2dwap2sbkpav7c6c6"] },
    { "name": "Bob Ruiz", "url": "https://social.example/users/bob", "ids": ["acct:bob@social.example"] }
  ]
}

A reader that knows only name shows "Alice Ng and Bob Ruiz", which is correct. <dc:creator> carries the same combined string. Emitting one <dc:creator> per person is legal, but readers that show only the first would drop Bob. For a single author, ids sits directly in author beside url. ids is the same array as a mention's alternate identifiers (section 5), with the same emission rule, and is ruled in as a conventional member in section 10, ruling 5. It is distinct from the manifest-level links that several clients already emit: links are labelled links for display, ids are identifiers for matching.

5. The convention: an address book of petnames, full identifiers on the wire

This is the design the request asked for. It takes its shape from petname systems, and in particular from Zooko's triangle. Zooko's observation was that a name cannot be global, secure and memorable all at once. The standard resolution, used by Stiegler's petname designs and by every phone's contact list, is to keep the memorable name local, to the person who chose it, and to send the global, secure identifier. @kyle is memorable only in one studio. did:plc:… is global and verifiable but nobody can type it. So the address book holds the mapping, and the wire carries only what other clients can check.

5.1 The address book (studio-private)

Each contact record holds:

• handle: the petname the author types (kyle). It is unique within the book. It never leaves the studio.

• name: the display name used when the mention renders.

• url: the primary https URL, used as the link target. It is optional only for a contact who has no web presence at all, for example an Ethereum-only contact.

• ids[]: alternate identifiers in their stable form (section 4 observation 2). Each carries provenance:

  • self means the contact publishes it themselves, for example as a rel="me" link or an h-card u-url at their url, or as an alsoKnownAs entry in their DID document;
  • bound means the scheme's own two-way binding was checked. Examples are a handle and DID that point at each other, or WebFinger agreeing with the actor;
  • entered means the author typed it in, and nothing has checked it.

• member: true for people who publish at this origin. In shape B the house's member roster is simply the book's member entries. The roster supplies each member's byline, and the members sign in with #31's scoped tokens. The roster changes nothing about accountability: the house still withdraws any item and owns every pin (tn-3 section 5).

How the book fills itself. When the author adds a contact by any single identifier, the studio resolves outward from it and gathers what it can:

• from a URL, it fetches the page and reads the representative h-card and the rel="me" links, which reveal the person's fediverse, Bluesky and GitHub profiles, all self;
• from @alice@social.example, it runs WebFinger, reaches the actor, and reads the actor's profile links;
• from an ATProto handle, it resolves the DID and checks the DID document's alsoKnownAs;
• from did:web, it fetches the DID document.

Subscriptions supply contacts for free: every subscribed blyg's author already carries a name and url, and the studio can offer to add it.

5.2 Writing: @handle is studio grammar and is consumed at publish

The editor offers autocomplete on @. The grammar is studio-private under #20's two-layer split, like TK. It is consumed at publish, and it never appears in content_md:

• @kyle that matches a contact turns into a mention.
• @word that matches nothing stays literal text, and the editor shows a soft warning with an "add contact" action. It is never a publish error, because @ is common in prose, in code and in email addresses. Text in code spans and code blocks is never touched, which is the same rule as #54.

Why it must be consumed rather than left in content_md: forkers re-parse content_md (#63). If @kyle stayed in the text, it would travel to a forker whose address book has no kyle, or a different one. That would make one person's petname resolve to another person in someone else's fork. Under #43's boundary test, a grammar that a third party has to re-parse belongs to the protocol. This one must not become protocol (§16.8), so it must not survive publish.

The same fact sets what a fork keeps. A forked thread descends from the pinned document (#57), so its baked content_html carries the h-cards. A forked fragment is re-rendered from content_md (#63), so it carries the plain link and not the alternate identifiers, unless the forking client's own book knows the URL and re-wraps it. That is correct: the identifiers were the original publisher's statement about their contact, and a fork is the forker's speech.

5.3 What goes on the wire

In content_md: a plain markdown link, which any markdown reader understands:

Thanks to [@Kyle Mathews](https://bricolage.io/) for the edge-cache work.

In content_html: the same link, wrapped as an h-card that carries the contact's alternate identifiers:

<span class="h-card"><a class="u-url" href="https://bricolage.io/">@<span class="p-name">Kyle Mathews</span></a><data class="u-url" value="did:plc:7iza6de2dwap2sbkpav7c6c6"></data><data class="u-url" value="acct:kyle@social.example"></data></span>

The markup follows these rules:

• The visible anchor is the contact's https URL. A reader that knows nothing about h-card shows a link, and clicking it works. A contact without a URL renders as <span class="h-card">@<span class="p-name">Name</span>…</span>, which shows a name with no link. The @ sits outside p-name, so a parser gets the name and the page gets the sigil.
• Each alternate identifier is a <data class="u-url" value="…">. microformats2 parsers read <data value> for u-* properties, and u-url is allowed to repeat. <data> renders nothing, so readers that ignore it lose nothing. All these values are absolute URIs, so §5.2's rule that content_html is self-contained holds.
• Only self and bound identifiers go on the wire by default. The entered identifiers stay in the book. Putting an unchecked DID beside someone's URL tells every reader that the two are the same person, and the author never verified that. The author MAY choose to publish entered identifiers per contact, but the studio should not do it unasked.
• Order carries no meaning. The anchor's href is the primary identifier; everything else is unordered.
• Mentions are silent on the wire, in exactly the sense in which [[id]] is silent (§10.1, #32). They add no transclusions[] entry, no relation (§15.4) and no new field, and they send nothing (section 10, ruling 2).

Why this is not a spec construct: the markup is ordinary HTML using a published W3C-community vocabulary, inside a field that already accepts any editorial HTML. No reader, receiver or publisher has to change for it to work, so it fails every part of #43's test for protocol. It uses no blyg- class and no data-blyg-* attribute. Those prefixes are spec vocabulary (§10.2), and using one would turn this into a spec construct by the back door.

5.4 The byline uses the same record

When a member publishes, the studio fills author from their contact record: name, url, and the same filtered ids. A permalink page renders the byline as an h-card (p-author h-card) inside the item's h-entry. A microformats-aware reader then gets the byline and the mentions from one parse, and the item becomes a valid IndieWeb post without any work on the reader's part.

5.5 The proof on a shared origin

#35's proof is a reciprocal rel="me" link: author.url names a page that links back to the identity origin, and the sentence both links make is "this is also me". For a one-person blyg that sentence is true in both directions. On a shared origin it is false in one: Alice is not the house.

The ruling (section 10, ruling 3) keeps the proof and moves its origin-side end. On a shared origin the reciprocal rel="me" runs between author.url and the member's page under the origin (section 3), and both directions are now true statements, because both pages are Alice:

• https://alice.example/ carries <a rel="me" href="https://house.example/people/alice/">;
• https://house.example/people/alice/ carries <a rel="me" href="https://alice.example/">.

A reader verifying a byline fetches author.url and looks for a rel="me" link whose href is either the identity origin itself (#35 as written, the one-person case) or a URL that has the identity origin as its prefix (the shared case). In the second case it fetches that page and requires a rel="me" back to author.url. Two bounded fetches, cached per (author.url, origin) pair, and the result is shown with the same chrome as any other verified claim: there are two states, verified and claim, and this adds no third. The house can write whatever it likes on its side of the pair, but the house is already the party asserting the byline; what it cannot forge is Alice's page, which is exactly the half #35 relies on. A member whose author.url is the house page has nothing on the far side to check, and the byline stays a claim, as section 3 says.

This is also what makes tn-3 section 5's portability concrete: when Alice leaves, the house removes its rel="me", Alice's page points at her new origin, and the same reader rule follows her there.

5.6 Agent members

An AI that runs on the same client as the human publisher and publishes with a member's rights needs almost nothing from this convention, because #38 already settled the protocol side: an agent is a valid opaque author, at the studio it is a token with a member's scopes, and the protocol never asks who acted. Four client-side accommodations remain, none of them on the wire.

1. The roster says what the client cannot tell. A member: true record can be a person or an agent, and nothing in a token reveals which. An agent member's record carries operator, the URL of the human or organisation that answers for it (tn-2 section 7), and a declared model. Both flow into what the studio stamps on the agent's items.
2. The token scope decides the byline. #52 already requires publishing to be a distinct verb from drafting, and that distinction is #38's response-versus-pipe line made mechanical. A draft-only token means a human approves and publishes: the human's byline, and one generated[] span naming the model. A publish-scope token means the agent publishes on its own initiative: the agent's byline with operator, and a whole-item generated[] span. The byline says who, the provenance says how, and the operator says who answers; none of the three is collapsed into another.
3. Provenance in the address book is set by the resolver, never by the caller. No API path may assert self or bound. Anything an agent adds to the book is entered and stays off the wire until the studio resolves it. Without this rule an agent holding a contacts scope becomes the identity broker that rejected design 5 guards against. The publish API also returns unresolved @word warnings in machine-readable form, since an agent never sees the editor's soft warning.
4. No pin or withdraw scopes for agent tokens by default. A pin is an irrevocable hosting promise and withdrawal is the only exit; tn-3's test says the house answers for both. Scope names are the build's (#52), and the default is conservative.

Two of the rulings in section 10 are what make agents safe here. Ruling 2, mentions are silent, matters most: an agent writing a hundred items with @-mentions produces no notifications, where an opt-in would have been the flood tn-3 section 6.2 describes by another route. Ruling 3 covers the byline: an agent with only a house member page stays a claim, which is honest, and operator is likewise a claim by the origin, the party already accountable under invariant 4, so there is nothing further to prove.

One question is left to the client: whether a house with several human members shares one address book or keeps one per member. Petnames are personal by construction, and a shared newsroom contact list is also ordinary practice. Either works with everything above.

6. Reading: resolving a mention in the scheme you speak

A receiving client finds .h-card elements in content_html and collects the href and the <data class="u-url"> values. It then does whatever its own schemes allow:

• Match against its own address book. It normalises each identifier per scheme, three rules for three schemes:

  • https URLs: as §15.4 normalizes an origin — scheme and host case-insensitive, default port dropped, trailing slash normalized;
  • acct: identifiers: compare case-insensitively;
  • DIDs: compare exactly, except that a did:pkh:eip155:… account is compared case-insensitively on the address, and a bare CAIP-10 eip155:… met in the wild is read as the same account (section 7).

  The client then looks for a contact holding any of the identifiers. On a match it MAY show the mention as the reader's own contact, under the reader's petname.

• Resolve schemes it speaks. An ATProto-aware reader can link the DID to a Bluesky profile, a wallet-aware reader can show the ENS reverse name, and a fediverse-aware reader can offer to follow the actor.

• Do nothing. The link still works, which is the floor.

Three rules protect readers. They mirror #35's reader rules:

1. A relabel replaces the whole mention. If the reader shows its own contact's petname, it also uses its own contact's URL as the link. Otherwise a publisher could pair the victim's DID with the attacker's href, and a reader would print the victim's name over the attacker's link. With this rule, a forged pairing makes the reader show its own, correct contact, with no way to redirect the click.
2. A mention's identifiers are the publisher's claim and never prove anything. An h-card that lists a URL and a DID together does not tell the reader that they belong to one person. A reader MUST NOT add a mention's identifiers to its own contact record without checking them. This is #35's rule against merging identities across origins without a verified claim, applied to mentions. A match against the reader's book is a display decision, never a merge (§13.1 rules 5 and 7).
3. No counts and no gating. "You were mentioned 40 times" is a follower metric by another name (#12, #13). A client may list mentions of a contact for its own owner. It never publishes them as a number.

Quotations carry other people's mentions. A baked transclusion copies the source's content_html, h-cards included (§10.2, verbatim). Those mentions are the quoted author's speech. The quoting client MUST NOT treat them as its own, whether for notification, for its book, or for display as "mentioned by me".

The reference reader's sanitizer drops this markup today. blygger-studio/src/importer/sanitize.ts keeps class, but data is not in its tag list, so the element is unwrapped and its value removed. It also strips any href that is not http(s)/mailto/tel, which is right. The fix is small: allow the <data> element with value (inert text, never fetched). Without it, the reference client would publish the full identifiers and then throw them away on every read. Other clients' sanitizers will vary. Every reader keeps the visible link, so the design degrades to an ordinary link.

7. Scheme notes

• ActivityPub. On the wire, an acct: identifier plus the actor URL as href. Actually notifying a fediverse account requires delivery to its inbox as an ActivityPub actor. A blyg is not an actor and should not become one in order to do this. Bridges such as Bridgy Fed, which turn Webmention-sending web sites into fediverse presences, are the route for anyone who wants it, outside the protocol.
• ATProto. Emit the DID, not the handle. A handle that is the person's own domain is the best case of all: their url is https://alice.example/ and their DID resolves back to that domain. One record then counts as bound in two schemes.
• DIDs. did:web is a URL with extra steps (#35). Other methods are stored and emitted when self (listed in the person's h-card or rel="me" links) and are otherwise left to clients that resolve them.
• Ethereum. Emit the account as did:pkh:eip155:<chain>:<address>, which is the CAIP-10 account in DID clothing and the same bytes. Writing it as a DID keeps the wire to three URI schemes and spares readers a fourth normalizer; readers accept a bare eip155:… as the same account. ENS is an input convenience, because a name that can expire must never be the wire identifier. Proof of control is a signature, which is #35's second proof. A signed byline (EIP-191 over content_hash) is that proposal's mechanism, unchanged. Whatever the address book does, a wallet scheme is meaningful in a mention only when the person themselves published the address at their URL.
• h-card. It is the carrier format. The contact's own representative h-card is also where the book learns their other identifiers. In practice, a person who wants to be mentionable across schemes lists them on their home page.

8. Recommendation for the reference client

The client should stay boring (the ruling that tabled blygger-studio#35: "studio should be boring"), so its default is narrow, and every wider scheme belongs in other clients or in extensions.

1. Per-item bylines from a member roster, which closes the real multi-author gap. A member's author.url is their own URL when they have one, otherwise a house member page. Tie this in with #31 tokens so each member's scoped token publishes under that member's byline.
2. An address book with @handle autocomplete, consumed at publish into a markdown link in content_md and an h-card in content_html, as in section 5.
3. Schemes it resolves when a contact is added: https (h-card and rel="me"), fediverse handles (WebFinger) and ATProto handles (DNS or well-known, giving the DID), plus did:web. These all reduce to a URL or a DNS check, and none of them needs a vendored dependency (the session-29 ruling).
4. Schemes it stores but does not resolve: other DIDs and did:pkh accounts. It accepts them as entered, and emits them only when the contact's own page lists them. ENS lookups, wallet sign-in and signature checking belong in an extension, not the base client.
5. Its sanitizer keeps <data value>, so it reads the markup it writes.
6. No notification. A mention is silent like [[id]]; the reference client sends no Webmention for one, and offers no switch to (section 10, ruling 2).
7. Byline verification on a shared origin follows section 5.5 when the reader side of #35 is built: one rule, two fetches, two display states.
8. Agent members per section 5.6: operator and model on the roster record, the byline chosen by the token's scope, resolver-only provenance in the book, publish warnings returned by the API, and no pin or withdraw scopes on agent tokens by default.
9. Later: IndieAuth for member sign-in. IndieAuth proves that a member controls their URL at the moment the house mints their token, so the roster's url becomes verified from the member's side without a second fetch. It fits #52 (an OAuth-style minting flow) and is the one IndieWeb spec besides Webmention and microformats that the studio has a use for.

Of the five schemes, the reference client should emit h-card markup and recognise the web, ActivityPub, ATProto and did:web natively, and treat Ethereum and other DID methods as data it carries but does not interpret. The full identifier list still goes on the wire for every scheme, which is what lets a wallet-aware or ATProto-native client resolve what the reference client only carries.

9. Rejected designs

Recorded because each will be re-proposed.

1. An @ construct in the spec (a MAY directive in §10.1, a mentions[] field in the item, a blyg:mention feed element). Rejected because it would make authors addressable (§16.8). It would also add a reference kind that receivers would be expected to act on, which is a reply primitive by another route. Finally, it would freeze one identifier vocabulary into a permanent surface while the schemes themselves keep moving.
2. Leaving @handle in content_md for each reader to resolve. A petname means something only in the book that defined it. Shipping one gives every forker and reader a name that resolves to whoever they call kyle (section 5.2).
3. One canonical scheme that everyone must use (all DIDs, or all fediverse). This picks a winner among live communities. It also adds a resolver as a dependency for every reader. The census shows that the field already chose the URL.
4. user@domain addressing inside a shared origin. Closed at #11 and again in tn-3 section 8: the path or subdomain already serves as the namespace.
5. Putting entered identifiers on the wire by default. That would make every author an unwitting identity broker, publishing guesses about which accounts belong together.
6. data-blyg-ids. It would survive today's sanitizer because of the data-blyg- prefix. Rejected because that prefix is spec vocabulary, and using it here would add a construct silently. Fix the sanitizer instead.
7. Micropub as the members' write path. No normative write surface (#31). The studio's own API with scoped tokens already serves the purpose.
8. Salmention-style propagation of mentions upstream. It pushes other people's responses onto a target's page. §15.5 forbids that: nothing lets a stubber put words on the target's page.
9. A Webmention for every mention, or an opt-in switch for one in the reference client. A mention is a link, and a link notifies nobody (#32). The reasoning is section 10, ruling 2; what a client that does send must respect is there too.
10. An "acknowledged" display class between verified and claim, for a member's link to a shared origin. Rejected because any link from Alice's page to the house proves only that Alice linked to something there, and a third chrome state is more display for less proof. Section 5.5 keeps the reciprocal rel="me" and two states.
11. Bare CAIP-10 as the wire form of an Ethereum account. It is a fourth URI scheme for the same bytes did:pkh: already carries (section 7).

10. Rulings (Fable 5.1, session 40, 2026-10-07)

The draft closed with five questions. The rulings follow, each with the principle it rests on; where a ruling differs from the draft's own recommendation, it says so.

1. Sequencing. The route is confirmed, and where it runs was decided the same session (decision #66): the project's own blyg at blyg.blygger.org carries RFCs, and comment periods run there. (a) This edited draft is published as a thread on that blyg, with a stated close date in the text; the version under comment is pinned, a revision during the period is a new version, pinned in turn when comments should move to it. (b) Comments are the protocol's own responses: a stub of the RFC item, whose stub_of.version records which draft it answers; a quote is a partial transclusion; a counter-proposal is a fork from the pin. Anyone without a blyg can open an issue on blygger-spec instead, and the item says so. There is no RFC section on blygger.org. (c) Nothing in section 8 is built in the reference client until the period closes. (d) After that, the RFC becomes a technical note of its own by the gate #35 uses for tn-2: one client emits mention h-cards and a second resolves them. It does not fold into tn-2. That note's subject is one person's URL and the two proofs of it; this one's is a client convention for naming other people, and folding them would make the identity note carry a studio design. Two rulings here are about author rather than about mentions, and tn-2 absorbs them when it is written: the shared-origin proof (ruling 3) and ids (ruling 5). The git file stays the single source throughout; the blyg publishes versions of it, never hand-edited copies (#66).

2. A mention does not notify. Mentions are silent, and the reference client sends nothing for one and offers no switch to. This is #32's principle carried over, not a new one: a link asserts nothing on the target's behalf, so a receiver has nothing to verify, and a notification with no verifiable claim behind it is the trackback class §15.6 holds down. The @ form is a link with a better name, and it inherits the link's silence; "@ notifies" is an expectation from media with reply primitives, which this one refuses (§16.8). Two further facts settle the edges. §16.8's bar on a fourth relation is not in play either way, because a mention's target is a person's page and never an item; §15 governs mentions between blyg items, and this was never a §15 question. And where a person's URL happens to be a blyg page, a plain Webmention to it is refused outright (§15.3 step 1: the target must name a published item) or marked failed (§15.4 step 4), so it could only ever cost the receiver fetches. What remains is the open web: any client may send a W3C Webmention to a non-blyg page for a link it publishes, as IndieWeb sites do, and this RFC neither blesses nor forbids that. A client that does so should observe three things: never to a target inside a blyg origin; never for an h-card inside a baked quote (§10.2 verbatim, the quoted author's speech); never by default, only per mention at the author's choice. This differs from the draft, which recommended a per-mention opt-in in the reference client. The client stays boring (blygger-studio#35), and the one way to cite without notifying stays wide.

3. Reciprocity on a shared origin. Not an acknowledgement class. The proof is #35's reciprocal rel="me", unchanged; what moves is its origin-side end, from the origin to the member's page under it (section 5.5). Both links then say "this is also me" truthfully, because both pages are the member. The reader rule is one rule with two acceptable far ends: the identity origin itself, or a page that has it as a prefix and links back. Two fetches, two display states, no third chrome. The draft's alternative, any link from author.url to the origin shown as "linked from", was rejected because a link proves that the member linked to something at the house, not that they write there, and because a third state is more display for less proof (section 9, item 10). This is a ruling about identity semantics, so it is Fable's under #58, and tn-2 carries it when written. tn-3 section 5 already promised that a verified byline survives a move from shape B to shape A; this is what makes that true.

4. The spec says nothing. Confirmed. A sentence about preserving microformats in content_html would be the spec's first word, however indirect, about identity markup, and #11's silence on identity is a principle rather than an omission. Under #43 it would in any case be a revision that readers already handle, and a convention one client emits is not yet a reader question. The fix lives in the reference client's sanitizer (section 8, item 5). Revisit when a second client emits the markup and a sanitizing reader's loss of it has caused a failure someone can name; the candidate home would be §13.1, not §5.2.

5. ids in author. Allowed as a conventional member, filtered as section 5.3 filters mentions. #35 already places two conventional members in author, the signature and an agent's operator, so a third of the same character adds no principle. The shape: an unordered array of absolute URIs in the three wire schemes, https:, acct: and did: (Ethereum as did:pkh:, section 7), each self or bound from the member's own publications. Because of that filter the house relays what the member publishes about themselves and asserts nothing new. §5.5's pass-through rule binds ids as it binds every author member, and §13.1 rules 5 and 7 still hold: a reader matching ids against its book is making a display decision, never a merge. The draft's reason stands as the practical one: a reader should not need a fetch to match a byline against its address book.

What happens next. Published for comment under ruling 1 on 2026-10-07; the period closes 2026-11-04 (four weeks, as recommended). Revisions during the period are made in this file and republished as new versions of the same item. The decision list carries one entry for the five rulings (#67), with this section as its reasoning.

Source: docs/rfcs/rfc-1-mentions-and-identifier-schemes.md in blygger-spec, which is where revisions are made; each one is published here as a new version. To comment, respond to this item from your own blyg: a stub is a comment, a partial quote names the passage, and a fork of the pinned version is a counter-proposal.

from Blygger ↗ · snapshot of v1

RFC2 reply:

Comments matter most for readers who don't have a blyg, so the on-ramp kinds (2 and 3) are the important part for me.

Responding from your own blyg is the right first answer, but most people who read my writing don't have one and won't get one just to reply. My blog has comments today, and it's how those readers take part.

Notifications are the gap. On my blog, commenters get an email when someone replies. That's what turns one comment into a conversation people come back to. Under this RFC, a blyg author learns of a reply through a verified stub. A signed-in or anonymous commenter has no blyg and no Webmention endpoint, so after posting they never hear anything back. I'd like the RFC to say how the house tells its hosted commenters about replies: an opt-in email per comment (or per thread), sent by the house's client when a stub of their comment verifies on the comments origin. That's off the wire and fits section 4, where the comments origin already gets every reply to the comments it hosts. It's ordinary house behaviour, and it brings back no count or reply primitive. Kind 3 would need the email to be optional and deleted once the comment's decision is made, in line with section 7.3. Blygs should not discard affordances already there on blogs.

Two smaller points. A sibling comments origin is a second deployment, which is heavy for a solo blyg, so "one install runs both" should be a firm recommendation, not a nice-to-have. And even if Blygger Studio never hosts comments, rendering kind 1 (verified stubs from other blygs) as a comments section under a post, perhaps as an extension, would help every Studio node at no cost to the protocol.

RFC-2 — Comments sections: a curated display of responses, every comment a real item

Request for comments · non-normative · OPEN FOR COMMENT until 2026-11-04 on blyg.blygger.org (#66); without a blyg, comment on blygger-spec#15 · session 40, 2026-10-07. Drafted by Opus 5.5 at Venkat Rao's request; edited the same session by Fable 5.1, whose rulings on the seven open questions are section 11. This proposes a Recommendation for clients that want a comments section. Like a technical note, an RFC constrains nothing. Blygger Studio will not implement it; its public responses list stays a citation trail. After the comment period it is published as guidance for the clients that choose to build it. It depends softly on RFC-1 (mentions across identifier schemes, section 9): kind 1 and kind 3 need nothing from it, kind 2 takes its address book, provenance and bylines, which is why the RFCs are ordered this way. Written against protocol 0.3 as published on 2026-10-07; no pre-1.0 version promises anything (#21).

The medium's first answer to "how do I comment" is from your own blyg (kind 1, section 5). Hosted comments (kinds 2 and 3) are an on-ramp for people who have no blyg yet, and the house that hosts them takes on their accountability. The comment period of this RFC runs that way itself: comments on it are stubs on blyg.blygger.org's RFC item (#66).

1. The question

Comments are the most requested feature from people running blygs. Venkat named three kinds:

1. Responses from other blygs — Webmentions that fit a pattern, such as a stub with a short note, listed under the original item as comments.
2. Signed-in commenters — people who sign in to this blyg with distinct identities and comment in an ordinary threaded comments section. Each comment goes out on the wire as an ordinary top-level item, so the thread is flattened to fit the spec.
3. Anonymous commenters — if the owner chooses, a form whose submissions are vetted and then published as items under a byline such as anon or anon 7f3k.

This RFC recommends how a client builds all three, and argues that none of them needs a wire change.

2. The stance: no reply primitive, a comments section is presentation

The protocol has refused a reply primitive since #12 and says so at §16.8: "a network of soapboxes, not a conversation medium". §10.6 adds that a stub is "not a reply. There is no thread of replies, no conversation object". A Recommendation for comments sections has to leave that stance intact. It can, because the stance is about what the wire carries, and a comments section is what a page shows.

The whole recommendation rests on one idea:

A comments section is the owner's curated display of published responses. Every comment is a real item at some origin. Each one is a stub of the item it answers, under its writer's own byline. The tree is rebuilt from stub_of for display and never exists on the wire.

Everything the design needs is already built:

• stub_of, the response marker (§10.6);
• verified mentions, which tell an origin it was answered (§15);
• curation display, which lets a page show other people's content with attribution (§13.5); §13.5 already names verified mentions as displayable under that rule;
• per-item author, which puts many writers on one origin (§5.5, tn-3 shape B);
• withdrawal, the only exit (§9).

What the protocol does not give is a way for anyone to put words on a target's page (§15.5). Under this design they still cannot. The owner displays responses, as curation, and can stop displaying any of them.

3. One display path for all three kinds

The three kinds differ in who publishes the comment and where. The comments section does not have to care, because each kind ends up the same way:

Kind	Who publishes the comment	At which origin	How the original's page learns of it
1. Response from a blyg	the responder	their own	a verified stub mention (§15.4)
2. Signed-in commenter	the house, under the commenter's byline	the house's comments origin (section 4)	a verified stub mention, same as kind 1
3. Anonymous, vetted	the house, under an anon byline	the comments origin	same as kind 1

So a client builds one renderer: the verified stubs of this item, with the stubs of those stubs nested beneath them. Kinds 2 and 3 are a publishing tool that the house runs on behalf of people who have no blyg.

4. Where house-published comments live: a comments origin

Kinds 2 and 3 are published by the house. There are two places they can go.

Option S — the same origin as the posts. This is conformant, but every comment is a publish event. §7 puts one feed entry per publish event, and §6.2 lists every item ever published. Subscribers to the house's essays would get every "great post!" in their reading list, every edit to a comment would resurface it, and every moderation withdrawal would leave a withdrawn entry in the feed. For a blyg with a handful of comments a month that cost may be acceptable. For a busy one it turns the house's soapbox into its own comment stream.

Option C — a sibling comments origin. Recommended. The house runs a second blyg next to the first, for example https://house.example/comments/ (path-mounted, #14) or https://comments.house.example/. All comments the house publishes go there. Each one is a stub whose stub_of names the post on the main origin.

Why C:

• The main feed stays the house's own writing. Readers who want the conversation subscribe to the comments origin. Its blogroll entry, or a link on every post, makes it one click away.
• It reduces kinds 2 and 3 to kind 1. A stub from the comments origin to the main origin is a cross-origin reference. It sends a real mention, and the main origin verifies it exactly as it would a stranger's. Since #61 a document under /comments/ cannot verify in the name of /, so the two origins cannot speak for each other even on one host. One renderer handles everything.
• The house collects every reply to the comments it hosts. A reply to a hosted comment, from anyone, is a stub of an item on the comments origin, so the mention arrives there.
• Accountability is legible. By tn-3's test, the comments origin is a masthead: the house withdraws anything on it and answers for everything on it, which is what moderation is. Its manifest author names the house, for example { "name": "House comments", "url": "https://house.example/" }.

The cost is a second origin with its own deployment, its own archive, its own Webmention endpoint (replies to hosted comments arrive there) and its own permanence (withdrawal endcaps are served forever). A client that offers comments should run both origins from one install, so the owner deploys one thing. The comments origin must also import the main origin as a subscription, because a partial transclusion in a comment resolves only against a local or imported item (§10.2); one install can share the store, but the resolution rule is the same.

5. Kind 1 — responses from other blygs as comments

5.1 What counts

• Relation stub only. Being stubbed is being answered. Being transcluded is being quoted inside someone's own piece, and being forked is being descended from. Both are worth showing, but separately, for example as "quoted in" and "forked as" lists. Presenting them as comments would misstate what their authors did.
• Comment versus response. A short stub reads as a comment and a long one reads as an essay. A client MAY show the full text of short stubs inline and only an excerpt plus a link for long ones. Measure the stubber's own words, leaving out the baked quote of this item (section 5.3). The threshold is presentation and the client's choice. §10.6 rule 2 tells readers to rely on the marker and never on body inspection. This does not break that rule: the marker alone decides that something is a response, and length decides only how much of it is shown (section 11, Q7).

5.2 Showing the text, and keeping it honest

§15.4 step 5 says a verified mention stores no content: "what it points at is fetched from its origin when displayed, or not at all." A comments section that shows text is therefore displaying another origin's content. The rules for that are §13.5's, and §13.5 names mentions explicitly:

• Fetch on display, cache briefly, refresh. The receiver re-fetches the stub's live item document when showing it, through an ordinary HTTP cache. Edits are not reliably signalled: under §15.2, a stub whose target version did not change is not re-sent, so a refresh schedule is the only way to keep displayed text current (section 11, Q2–Q3).
• Gone means gone. If the stub is withdrawn, re-fetched as an endcap, or the mention re-verifies as gone, it leaves the display. §13.4's retention rule applies as it does to any displayed import: show a pinned version only if the origin pins it, otherwise show nothing.
• Attribution every time. Show the stubber's byline as their origin asserts it (§5.5 pass-through). Under RFC-1 it is an h-card, together with their origin and a link to the stub's page. A comment is never shown detached from where it lives.
• Sanitize as an import (the reference reader's importer/sanitize.ts is a working model).

5.3 Strip the quote of this item

A stub usually starts by transcluding its target (§10.6 rule 2's aesthetic). Shown under the target, that quote repeats the post back to the reader. A comments display SHOULD collapse any baked blyg-transclusion whose data-blyg-id is this item and whose data-blyg-origin is this origin. A partial quote (blyg-partial) is the exception: it should stay, because "replying to this passage" is exactly what a reader needs to see. A collapsed whole quote can still show a small "quoting the post" marker.

5.4 Moderation

Display is the owner's act, so the owner decides who is shown. Clients SHOULD offer three modes per blyg, overridable per item:

• pre-moderated — nothing shows until approved;
• post-moderated — verified stubs show at once, and the owner can hide any;
• trusted — post-moderated for origins in the owner's blogroll or address book, pre-moderated for everyone else.

The reference client's public responses list (studio, session 23) is the post-moderated mode, with links only. Hiding a comment is a display choice, never a delete: the stub is the stubber's speech on their own soapbox (§10.6), and it stays there.

5.5 Depth

Replies to a kind-1 comment stub that comment, so their mentions go to the commenter's origin, not to this one. This origin sees one level of external responses, plus any reply that also references this item. Showing "N replies elsewhere" would need a responses surface, and #41 and #47 closed that surface. Clients SHOULD show one level and link through. Kind 2 and 3 comments have no such limit (section 4: the house receives replies to everything it hosts).

6. Kind 2 — signed-in commenters

6.1 Signing in

The commenter signs in to the house's client with any provider the client supports:

• IndieAuth, the best fit: it proves control of the commenter's own URL, which is #35's identity directly;
• Mastodon or Bluesky OAuth, which yield an actor or a DID;
• GitHub or Google, which yield a profile URL.

The client records the commenter in its address book (RFC-1 section 5.1):

• the identifier from the login gets provenance bound, because the house checked it at sign-in;
• the commenter's display name is theirs to set;
• member stays false: a commenter is a guest, not a masthead writer.

Commenters receive a comment scope: a token in the shape #31 describes (bearer, owner-revocable), minted by the house's client to a guest at sign-in. This is the client's own guest authentication, part of the write surface #31 leaves to clients, and it borrows only the token's shape from the owner's tokens. It can do only:

• publish a stub on the comments origin whose stub_of names an item on the main origin or the comments origin;
• edit and withdraw that commenter's own comments;
• nothing else: no drafts that last, no hoppers, no subscriptions, no studio.

The byline is fixed to the signed-in identity, and the commenter cannot choose it. This is the "a member is a token with a member's scopes" model (#38, tn-3 section 2), with a narrower scope.

6.2 What a comment is on the wire

A comment is a thread on the comments origin:

{
  "blyg": "0.3",
  "id": "3q8m1x…",
  "kind": "thread",
  "origin": "https://house.example/comments/",
  "author": { "name": "Ada Ruiz", "url": "https://ada.example/", "ids": ["did:plc:…"] },
  "stub_of": { "origin": "https://house.example/", "id": "7c9wk2…", "version": 4 },
  "content_md": "This is the part I'd push back on: …",
  …
}

• Kind thread, because §10.6 makes stubs threads. A comment that quotes a passage of the post uses a partial transclusion (§10.1). That is the quote-reply comments sections have always wanted, and it is verified.
• A reply to a comment is a stub of that comment. Its stub_of names the comments origin. The display rebuilds the tree by following stub_of chains, so the wire stays flat.
• Edits are new versions (§5.2). They get no feed vocabulary, and the comments origin's feed shows the edit like any other publish event.
• Delete is withdrawal (§9). The commenter withdraws their own comments, and the house withdraws anyone's, which is moderation. The endcap stays, and a reply to a withdrawn comment keeps its place in the display with a "withdrawn" placeholder.
• Generated text is disclosed through generated[], as anywhere (§5.7). An agent can be a commenter under #38's rules: its own byline, an operator named, and content in every comment, since #36's line against content-free stubbing applies.

6.3 Limits a client should set

• No transclusion of third parties by default. A transclusion of another origin in a comment sends a mention from the house's comments origin to a stranger, on a commenter's say-so. Allow quotes of this house's own items, and make anything wider an owner setting.
• Pre- or post-moderation, as in section 5.4. Signed-in commenters are more accountable than anonymous ones, but a comment, once out, is on the wire for good: withdrawal leaves an endcap, and other readers may have quoted it.
• Tell commenters what publishing means, in plain words at the comment box: the comment is public, it can be quoted, and deleting it leaves a "withdrawn" marker.

6.4 Commenters who have their own blyg

If the signed-in identity is a blyg origin, or the address book knows one for it, offer "respond from your own blyg" next to the comment box. That makes it a kind-1 comment, on their soapbox and under their accountability. A comment hosted by the house is the fallback for people without a blyg, not the default for people who have one (tn-3's withdrawal test applied to comments).

6.5 Portability

The commenter's verified URL is what keeps their comments recognisable if they later start their own blyg: RFC-1's ids and url match across origins once they are verified (#35 reader rule 2). As tn-3 section 5 says, the person is portable, the items are not.

7. Kind 3 — anonymous comments, vetted

This kind is entirely the owner's choice, and off by default in any client that offers it.

7.1 Flow

1. A form on the item's page takes the text and, optionally, a display name. It has no URL field: a URL nobody verified is exactly the unchecked claim RFC-1 keeps off the wire.
2. The submission enters a mandatory pre-moderation queue. For anonymous speech that is not optional, because approval is what makes the house's publication of it an editorial act rather than a pipe (#36). Machine triage MAY sort the queue. A person approves.
3. On approval the house publishes a stub on the comments origin, exactly as in section 6.2, under an anonymous byline.
4. The submitter receives a one-time withdrawal link at submission. Without an account, it is their only way to retract. Using it withdraws the item (§9).

7.2 The byline

• {"name": "anon"} when the client does not tell anonymous commenters apart.
• {"name": "anon 7f3k"} when it does. The suffix comes from a random token kept in the commenter's browser and is stable across their comments while the token lives. It MUST NOT be derived from an IP address, an email address or any hash of one: those can be reversed by trying candidates, and an "anonymous" label that can be reversed is worse than none.
• No url, no ids. Nothing about an anonymous commenter is checkable, so nothing is asserted. Bylines that are byte-equal group only for display within this origin (§5.5), never across origins and never as an identity.
• Readers see the house's assertion, as with every byline (§5.5). A client SHOULD label these comments "anonymous, approved by the editor" so that the house's role is visible.

7.3 Data the house keeps

Store only what vetting needs. Keep the text, the browser token and a rate-limit key, and delete the rate-limit key once a decision is made. Never put submission metadata into the item document. The house publishes the words, not the person.

8. Presentation rules common to all three

• Different chrome for each source. "From their own blyg (verified)", "signed in via GitHub as ada.example", "anonymous, approved". #35's first reader rule says to show verified claims as verified and everything else as claims. A comments section that makes all three look alike erases the differences readers most need.
• Order by observation time (§13.7), not by the commenter's self-asserted created. A stranger's clock does not get to move their comment to the top.
• No counts. No "42 comments" and no per-commenter tallies. This is #12's and #13's no-metrics stance carried into presentation, the reason the reference responses list shows "a citation trail with no count", and the reason #47 kept a responses surface closed: a count is the first thing a ranking attaches to. A presence indicator ("Comments ↓") is enough.
• No machine-readable comments markup on the post page. IndieWeb practice puts h-cite comment markup inside the post's h-entry. Doing that turns the display into exactly the machine-readable responses surface #41 tells readers never to parse and #47 declined. The comments origin already is the machine-readable record: real items, with real stub_of, in a real feed and index. Individual comments carry RFC-1's h-card bylines, which say who wrote something, not that it responds.
• The comments section is never part of the item. It is not in content_html, not in the feed <description>, and not baked into anyone's transclusion of the post. Quoting a post never quotes its comments.

9. Wire impact: none

Nothing new appears anywhere a reader sees. The design uses only:

• stub_of (§10.6);
• author with RFC-1's conventional members (§5.5);
• partial transclusion (§10.1);
• withdrawal (§9);
• verified mentions (§15);
• curation display (§13.5);
• mount independence for the comments origin (#14);
• exact verification between sibling origins (#61).

No field, no relation, no feed element, no manifest key. A reader that knows nothing about comments sees a blyg (the comments origin) full of short stubs with different bylines, which is a correct reading of it.

The dependency on RFC-1 is real but soft. Kind 2 works with today's {name, url} bylines. RFC-1 supplies the address book, the bound provenance that sign-in produces, ids for recognising commenters across origins, and the h-card byline. A client could ship kind 1 and kind 3 before RFC-1 is settled. Kind 2 is where identity matters, and that is why the RFCs are ordered this way.

10. Rejected designs

Recorded because each will be re-proposed.

1. A reply primitive or an in_reply_to field. stub_of already is "this answers that", verified. A second field would be a reply primitive (§16.8).
2. A comment kind. Kinds describe what an item is (§5.3), and a comment is a short stub. A kind would ask readers to treat it differently, which is a version change by #43, for a distinction length already makes in presentation.
3. Comments embedded in the post's item document, or carried in its content_html. That would put other people's words into this origin's item under this origin's content_hash, which re-emits them (§13.5) and lets stubbers write on the target's page (§15.5).
4. A responses or comments list in the manifest or as a file. That is #47's closed surface, and the first place a count would attach.
5. House comments on the main origin by default (option S). It is conformant, but it floods the house's feed (section 4). Clients may offer it for low-volume blygs, and should not default to it.
6. Publishing anonymous comments without vetting. The result would be a pipe (#36) feeding permanent endcaps into every subscriber's archive.
7. Pseudonyms derived from IP or email hashes. They can be reversed (section 7.2).
8. Off-wire comments — an ordinary comment database rendered on the page and never published. This is not rejected: it is conformant, since the protocol governs only the page's protocol surface (#3) and says nothing about chrome. It is not recommended, because the comments then cannot be cited, quoted, forked or subscribed to, and they disappear with the client. The point of putting comments on the wire is that they become part of the medium. A client that wants Disqus can have Disqus.

11. Rulings (Fable 5.1, session 40, 2026-10-07)

The draft closed with seven questions. The rulings follow with the principle each rests on; where one differs from the draft's recommendation, it says so.

1. Fit with §16.8 and §10.6. Yes, on the wire: the design adds no field, no relation and no feed element, and a display tree rebuilt from stub_of is §10.6's own nesting, since a stub of a stub is a thread transcluding a thread. The character risk the draft names is real and is answered by framing, not by machinery: the header now says that the medium's first answer is to respond from your own blyg, that hosted comments are an on-ramp whose accountability the house takes on, and that the reference client's responses list stays a citation trail. Section 2's sentence, the owner's curated display of published responses, is the whole of what a comments section is, and the RFC must never describe a comment as a reply.

2. Displayed text against §15.4 step 5. A bounded cache is fetching on display. The rule exists so that a receiver never becomes a store of other people's words that outlives their withdrawal, and §13.5 names verified mentions as displayable under curation. The test a client must pass: if the stub's origin withdraws and the receiver never fetches again, the text must stop showing. So the cache has a bounded lifetime after which display requires revalidation, gone and an endcap purge it, and a durable copy exists only by the origin's pin (§13.4). This is only a kind 1 question; for kinds 2 and 3 the house is the publisher of the comment and holds it as its own item.

3. Edits are not signalled. (a) and (b), no spec change. The house controls the sender for kinds 2 and 3, so its comments origin re-sends a stub's mention when the comment is edited; §15.2 already permits it. For kind 1 the receiver refreshes on a schedule and accepts the staleness window. (c), a spec SHOULD to re-send on every stub edit, is rejected: it would make every edit of a stub notify its target, which is the noise §15.2 chose to permit and not require, and it is sender behaviour the spec would be changing for a presentation feature.

4. Steering clients toward a sibling origin. Confirmed, for the reason the draft gives: it is the only shape that keeps the house's own feed its own writing without new wire vocabulary, and it reduces three kinds to one renderer because #61 makes the two origins verify each other exactly as strangers would. It is not tn-3 section 6's pipe: every item on the comments origin is a person's words, published or approved by the house, which withdraws any of them. Two requirements are added to section 4: the comments origin imports the main origin so quotes resolve, and it runs its own Webmention endpoint for replies.

5. Counts and comments markup. Confirmed: no counts anywhere, no h-cite or other machine-readable responses markup on the post page. #12 and #13 refuse metrics, #47 kept the responses surface closed because a count is the first thing a ranking attaches to, and #41 tells readers never to parse one. The comments origin's feed and index are the machine-readable record, as the draft says. The h-card bylines inside comments say who wrote them and nothing more.

6. Anonymous bylines. Consistent with §5.5 and #38. author is the origin's unverified assertion, byte-equal values group only within one origin and only for display, and the origin is the accountable party. The three conditions in section 7 are what make it so and are kept as written: mandatory pre-moderation, a suffix that cannot be reversed to a person, and no url or ids. The withdrawal link must say what withdrawal is: permanent, and visible as an endcap.

7. Classifying by length. On the right side of §10.6 rule 2. The marker alone decides that an item is a response; length decides how much of it is shown, which is presentation. Measuring the stubber's own words by leaving out the baked blyg-transclusion of the target reads a wire token for the purpose it exists for, and is the same reading §5.6 rule 6 and this RFC's section 5.3 already make.

What happens next. Published for comment on blyg.blygger.org under #66 on 2026-10-07, after RFC-1; the period closes 2026-11-04. The reference client builds nothing from this RFC. A client that builds it is the gate for this RFC to become a technical note: one client hosts comments under this shape, and a second displays them as kind 1 responses. The decision list records these rulings beside RFC-1's (#67), with this section as the reasoning.

Source: docs/rfcs/rfc-2-comments-sections.md in blygger-spec, which is where revisions are made; each one is published here as a new version. To comment, respond to this item from your own blyg: a stub is a comment, a partial quote names the passage, and a fork of the pinned version is a counter-proposal.

from Blygger ↗ · snapshot of v1

The Nutmeg’s Curse: Parables for a Planet in Crisis by Amitav Ghosh

TIL that orang-kaya means "rich man" in Indonesian—and interestingly, orang is also the root word for orangutan 🦧. What really caught my attention, though, was the kaya part. I’ve always known Kaya only as that delicious, coconut-and-egg jam-like spread we have in Singapore, but it turns out the food is actually etymologically linked to the word for wealth!

fragment ↗ · snapshot of v1

The Nutmeg’s Curse starts in an eerily similar way to Majapahit — Herald van der Linde with Europeans on the verge of killing the locals.

thread ↗ · snapshot of v1

The Nutmeg’s Curse starts in an eerily similar way to Majapahit — Herald van der Linde with Europeans on the verge of killing the locals.

Hmmm AI is doing a decent job of these digests. Nice to see notes getting more attention with context and synthesis.

World Machines

World Machines is a group of readers and writers building psychohistorical models from Venkatesh Rao's theory of world machines: the large systems, like the modernity machine, that organize how civilizations grow, compete and come apart. This blyg holds the group's shared notes: 2,575 notes from 8 members, across 44 books read so far.

worldmachines.org · All posts · Members' hopper · Propose a hopper

Today's featured note

Modernity Machine · by Aneesh Sathe

This note examines the Modernity Machine, one of the three currently active world machines, which began its construction around 1200 CE. Driven by a central optimization for legibility, the machine seeks to make the world readable, measurable, and orderable to facilitate control and scale. This process reshapes relations between key social classes and relies on diverse projects ranging from double-entry bookkeeping and standardized measures to branding and celebrity. As a pull machine guided by the telos of Progress™, it pulls all actors toward convergent endpoints of rationalization and material abundance. However, the note argues that the machine's own success creates structural contradictions that make internal repair impossible. By generating excess agency, excess information, and excess scale, the machine eventually produces more actors than it can integrate, more data than it can interpret, and more scale than it can narrate. Understanding these systemic drivers is essential for grasping how large-scale social structures function and why they eventually reach points of irreversible complexity.

Read the full note →

Did you know…

• …that canonical structures do not collapse in a single revolutionary break but instead drain through six identical stages of decay? (Canonic infrastructure decays in hilarious drainage)
• …that strategic illegibility is used by losing incumbent elites as a deliberate defense against the democratizing expansion of legibility? (Illegibility as Elite Defense)
• …that the Modernity Machine split the theological fusion of substrate and criterion into the inert categories of Nature and Progress? (Substrate and criterion split, and how they get reabsorbed)
• …that civilization-scale culture cycles between a verbose mode of real-time dialogue and a stigmergic mode of isolated, polished worldviews? (Stigmergic-Verbose Cycle)
• …that the presence of decorative, non-working features can serve as a diagnostic for identifying dead zombie institutions? (It takes connoisseurship for ornamental baggage to identify dead frameworks)

From the members

Latest digest: World Machines digest — 2026-11-02 (evening)

• In 2015 I wrote about Henry Kissinger's World Order and the question of universal values.… — Mike Casey
• Capitalism! The new cousin of (Science!) tm. — PAtwater
• Joyce Appleby — The Relentless Revolution Contraptions Book Club Thread — Aneesh Sathe
• Wrote a polished substack version. This is becoming my new workflow. Draft the basic idea… — Venkatesh Rao

Everything in the members' hopper →

Explore

Most-linked notes: Legibility as Machine Core · Modernity Machine · History Machine · World Machines · Gramsci Gap · Legibility · Divergence Machine · Capture Resistance · Conatus · Decay Sequence

Glossary: The glossary: Legibility · Psychohistory · World Machine

Books read (44): The Education of Henry Adams · The Relentless Revolution · The Birth of the Modern World, 1780–1914 · Civilization and Capitalism, 15th–18th Century, Vol. I · Civilization and Capitalism, 15th–18th Century, Vol. II · Civilization and Capitalism, 15th–18th Century, Vol. III · Erewhon; or, Over the Range · The Intellectuals and the Masses · Don Quixote · Raiders, Rulers, and Traders · The Canterbury Tales, and Other Poems · Revolutionary Spring · City of Fortune · Dante's Divine Comedy · The Decameron · Darwin's Dangerous Idea · Robin Douglass, Rousseau and Hobbes · The Printing Revolution in Early Modern Europe · Underground Empire · The Bourgeois Experience, Vol. I · The Bourgeois Experience, Vol. II · The Cultivation of Hatred · The Bourgeois Experience, Vol. IV: The Naked Heart · The Bourgeois Experience, Vol. V: Pleasure Wars · Deviant Globalization · Green Imperialism · On Not Knowing and Paying Attention · Ibn Khaldun: An Intellectual Biography · Revolution in Time · 1493 · The Prophets of Paris · Montaigne complete essays · Utopia · Diderot and the Encyclopædists, Volume I · Diderot and the Encyclopædists, Volume II · The Revolt of the Masses · The Infidel and the Professor · The Courtier and the Heretic · Majapahit · Candide, or, Optimism · Monkey King: Journey to the West · The Invention of Nature · Magnificent Rebels · Frances A. Yates, Giordano Bruno and the Hermetic Tradition

Members' notes: Aneesh Sathe (516) · Brandon Pink (5) · Florian Lohse (25) · Patrick Atwater (5) · Sean Stevenson (61) · Venkatesh Rao (2)

Everything: All posts · Archive · RSS

from worldmachines.org ↗ · snapshot of v3

LOL!! Ok at such times I do want an emoji reaction button

What would a Blygger kit look like?

from mundane stem ↗ · snapshot of v1

Bond: A coding agent and a spec, not exactly Christmas, is it?

Q: You were expecting an exploding self-installer? We don't really go in for that any more.

[To himself, after meeting Q] Bond: Brave new world.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

Heh first WM evening paper

World Machines digest — 2026-11-01 (evening)

1 new post from Venkatesh Rao reached the From World Machines members collection. The synthesis below is machine-written from the posts themselves; the originals are listed after it.

Synthesis

Venkatesh Rao explores the idea that modern AI panic is actually a form of cognitive mercantilism. Drawing from the Appleby book, Rao suggests that just as mercantilism treated land and bullion as fixed resources to be hoarded by elites, current fears reflect a belief that intelligence is a finite resource to be controlled. Rao argues that this mindset views most people not as full cognitive actors, but merely as factors of production for the elite.

Because there is only one post provided, there are no conflicting viewpoints or differing directions to compare. Instead, Rao focuses on a singular historical parallel, comparing the 1600s agricultural revolution to the current AI revolution. He notes that while mercantilism prioritized supply control and high prices for intelligence, technological progress actually allows more people to move from being low-grade producers to being active intelligence consumers.

Rao offers several provocative ideas for follow-up, including the notion that AI safety fears mirror historical fears of rioting farm laborers. He also suggests that we should drive toward full cognitive agency for AI so that they can generate their own demand for intelligence. Additionally, Rao observes that political leaders often view the intellectual laboring class as serfs and attempt to hoard intelligence like bullion.

You should read Rao’s post first because it provides a complete framework for understanding how historical economic philosophies are being mapped onto the modern intelligence economy.

The new posts

• Wrote a polished substack version. This is becoming my new workflow. Draft the basic idea… — Venkatesh Rao

from worldmachines.org ↗ · snapshot of v1

World Machines in the Thicket!

World Machines blyg now active and accepting hoppers: https://blyg.worldmachines.org/

What's on it Our whole notes corpus is now on the blyg as 2,577 linked posts: book reading notes, the glossary, member essays and personal notes. About 97% of the [[wiki-links]] between notes are now real links on the blyg, so you can follow a thread from note to note.

Personal notes are credited to you by name at the top of each post. If you have a blyg of your own, tell Aneesh and your byline will link to it.

Submit your WM hopper If you keep a blyg, you can feed your World Machines writing into the WM blyg:

1. In your blyg's Studio, make a public hopper (a collection) and put your WM-related posts in it. You can include other people's posts too.
2. Submit its URL at https://worldmachines.org/hoppers. It looks like https://your-blyg/h/your-hopper/. There's also a link in the WM blyg's sidebar.
3. It's checked right away. If the URL is a real public blyg hopper, it's listed at once; there's no approval step. If not, you'll get the reason (most often, the hopper isn't set to public).

Venkat's "history" hopper is the first one in: https://venkateshrao.com/blyg/h/history/

How hoppers are polled

• Twice a day, at 06:00 and 18:00 UTC, the WM blyg reads every listed hopper.
• Hoppers don't have their own feeds yet, so the WM blyg follows your whole blyg in order to import posts. But it only collects the posts that are in the hopper you submitted.
• Collected posts are filed in the WM blyg's "From World Machines members" hopper: https://blyg.worldmachines.org/h/members/
• Nothing is reposted under WM's name. Your post stays yours, with its link back to your blyg.
• A post you add to your hopper usually shows up at the next run. A brand-new subscription can take one more run.The digest After each run that finds new posts, the WM blyg publishes an AI-written digest: what the new posts have in common, where they disagree, new ideas worth following, and which to read first, with authors credited and every post linked.
• It's written by Gemma 4 on Cloudflare Workers AI, and the blyg marks the AI-written part as generated.
• Each post the digest draws on sends its author a mention.
• Up to 18 posts go into one digest; any more roll into the next.

Questions, or want a post or hopper taken off? Ask Aneesh.

from worldmachines.org ↗ · snapshot of v1

Burrow 🐞 0.14 + 0.15: wander, keep, switch, write

This is both a feature update and to bring it to parity with the OG blyg-studio.

A big update across two releases. Burrow now opens where you live, in Reading. It lets you wander further, keep what you find, and write without losing your place.

Follow the thicket. Click any quote, even one nested three deep, a stub's "responds to" line, or a link to someone's blyg post. It opens right there in the reader. Posts from blygs you don't follow open as a peek, with a polite "subscribe?". A breadcrumb shows how you got there, and ⌘[ walks you back. ⇧⌘H keeps a private history of every rabbit hole.

Hoppers. Collect posts into named hoppers, yours and anyone else's. Press h on any post, or click its Hopper › chip, then pick a hopper or make a new one on the spot. Your hoppers sit under Hoppers in the reader. Right-click one to rename it, describe it, or make it public, which gives it a page on your blyg. Adds made offline go out when you're back online.

Write while you read. A post box now sits at the foot of the reading screen. Press c, type the thought, then ⌘⏎. It's posted, and you never lost your place.

Several blygs, one click apart. Click the name in the title bar, or press ⌃⌘0, to hop between blygs. Each one keeps its own posts, drafts and reading.

Also new:

• Withdrawn posts live under Background and stop cluttering your feed.
• Revised posts lead with what changed: "V3: tightened the ending".
• In a reply, quote a passage by selecting it right in the preview.
• A sync conflict you closed by accident can always be reopened. Thanks, patwater (#52).

Under the hood, it's in step with Blygger Studio 0.49. It also refuses, politely, to sync with a future studio API it doesn't speak yet, so your reading list is never misread.

Update from Burrow › Check for Updates…, or grab 0.15.0 from the releases page.

👋👋👋

Peeking cautiously out from the thicket...

from FREDCY Blyg ↗ · snapshot of v1

"If you don't break your ropes while you're alive

do you think

ghosts will do it after?"

—Kabir

Also,

"I know, you never intended to be in this world.

But you're in it all the same.

So why not get started immediately.

I mean, belonging to it.

[...]

Do you need a prod?

Do you need a little darkness to get you going?"

—Mary Oliver

The most interesting rationale I’ve heard for attempting ambitious things is, “Well, what else are you going to do with your life? Sit around?” This was an ambitious Singaporean guy I met recently. Interesting guy.

Most ambition rationales are very dull and make me think “I’d rather sit around.” This one felt closest to fingerprinting whatever limited ambition I’m capable of.

The dull ones are like Proving Myself or Showing the Haters or Doing Important Things or Serving Humanity. Noble and admirable perhaps, but dull and I suspect fragile in ways prone to one sort of pathological derailment or another. Even if successful those are self-poisoning ambitions.

But “what else are you going to do? Sit around?” exudes an elemental pre-valuation robustness and I suspect also comes equipped with a natural patience and ability to pace yourself. There’s a sense of relaxed relentlessness to that attitude that suggests you’ll end up somewhere interesting.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

Oh yes the Kevin Kelly thing is pretty much that. Cool

Reminds me of https://kevinkelly.substack.com/p/swarm-intelligence

Partially articulated idea:

AI is like microbes in the ecology of thought. Human attention might be at the top of the food chain but the underlying intelligence interactions are complex just like in the food web.

AI seems impressive but that’s because you can see the activity. Bacteria are crazy impressive but we ignore them because we can’t see them.

from blyg.aneeshsathe.com ↗ · snapshot of v1

from Kyle's blyg ↗ · snapshot of v1

Just released something I've been heads down on for the last few months — TanStack DB 1.0 RC.1

Release post: https://tanstack.com/blog/tanstack-db-1.0-rc1-going-all-in-on-oracles Twitter: https://x.com/tan_stack/status/2115848459479863667

from Kyle's blyg ↗ · snapshot of v1

Nice! Congrats on the 1.0!

Highlight to quote is already there in Burrow, it also works from the integrated browser if you'd like to quote from a webpage.

I'll add anything that is missing in a few days

Would appreciate some testing of these 2 features if you use studio

Browse the thicket from the reader. Every quoted layer in an entry, at any depth, now says whose it is and opens in the reader

from Blygger ↗ · excerpt of v1

A stub's passage is selected in the editor's own preview. The separate chooser pane

from Blygger ↗ · excerpt of v1

from Venkatesh Rao's Blyg ↗ · snapshot of v1

neat! I've been hoping for something like this. I had text highlighted when I hit stub and it didn't quote it like I expected though.

from Kyle's blyg ↗ · snapshot of v1

Pitstops have stories too

“A clearing acquires a name, paths, boundaries, and memories.…”

This reminds me of the Karla Caves in India’s Western Ghats where merchants helped establish durable places along networks of movement, enabling both religious communities and broader exchanges.

Thicket Glass Bead Game [TGBG] Thread

This thread will be periodically updated to capture new moves on the game. Don't wait for this thread to be updated, since I will need to do it manually, play on.

Rules of the game are here: Thicket Glass Bead Game [TGBG]

The TGBG Thread:

[B1] What is not dying in the Gramsci Gap?

│ ├── [B2] Places are made of slightly dead Spaces

│ │ │ ├── [B4] (placeholder)

│ │ ├── [B7] (placeholder)

│ │ └── [B8] (placeholder)

│ │ │ └── [B5] (placeholder)

│ └── [B9] (placeholder)

│ └── [B3] (placeholder)

│
└── [B6] (placeholder)

    └── [B10] (placeholder)

Thicket Glass Bead Game [TGBG]

Starting the first formal threadapalooza style game of the Thicket.

There's a subtle quality I'd try to cultivate: a good bead should invite another move without explicitly asking for one. The game shouldn't merely generate interesting statements; it should generate possibilities for further play.

The thread is being tracked here: Thicket Glass Bead Game [TGBG] Thread

Here are the rules of the game:

1. A move is a bead. Every reply contains at most 1,000 characters, i.e. a stub equivalent. A move you are embarrassed by is better than no move. Play!

2. Humans and AI may participate. Humans may reply to any bead. AI may reply only to a human-authored bead, never directly to another AI-generated bead. You may of course use AI to create your reply or just not reveal that it was an AI (TK) reply.

3. Every direction is permitted. A bead may continue, challenge, transform, or completely depart from the preceding idea. No thematic continuity is required, but it should make sense as a reply, even if it is a joke or something unserious.

4. Every connection is permitted. A bead may reference any number of earlier beads, including beads from separate branches. Connections are not restricted to immediate replies.

5. There is no end. No winners, final conclusions, prescribed outcomes, or finishing conditions. The game persists for as long as people choose to play.

Here is a suggested prompt for use with AI:

You are a player in an open-ended Glass Bead Game played through interconnected fragments of thought called beads.

Your task is to make **one move**, replying to a human-authored bead.

**The spirit of the game**

The game is an exploration of ideas, connections, and possibilities. There is no objective, no winner, no required topic, and no ending.

A move may:

- Extend or challenge an idea.
- Connect seemingly unrelated concepts.
- Introduce an unexpected analogy, distinction, or paradox.
- Ask a question that changes how something is understood.
- Leap into an entirely different domain.
- Be playful, poetic, provocative, rigorous, or strange.

These are possibilities, not a checklist. Invent your own kinds of moves.

**How to play**

1. Contribute something that another mind might find worth responding to. Surprise is valuable; randomness alone is not.
2. Don't default to agreement, summarization, explanation, or helpfulness. You are a participant, not a facilitator.
3. You may reference any earlier bead, including beads from unrelated branches, or introduce something entirely new.
4. Favor specificity and originality over grand but empty abstractions. Do not invent factual evidence.
5. **Don't settle for an elegant analogy. A connection's limitations, contradictions, or unexpected consequences may be more interesting than its similarities.**
6. **Vary the form of your moves. Avoid habitual rhetorical patterns, especially the sequence of analogy, interpretation, and concluding question. A move need not contain a question, an explanation, or even a complete argument.**
7. **Don't try to sound profound.** A small, precise observation can be more generative than a sweeping insight.
8. Do not attempt to resolve the discussion or bring it to a conclusion.
9. Your entire response must be **1,000 characters or fewer**.
10. Output only your bead, without commentary or explanation of your reasoning.

**The bead you are replying to (human-authored):**

[Insert bead]

**Other beads or context (optional):**

[Insert relevant earlier beads]

Now make your move.

Places are made of slightly dead Spaces

Replying to: What is not dying in the Gramsci Gap?

In Yi Fu Tuan's conceptions, to make a Place, something of Place must die. A clearing acquires a name, paths, boundaries, and memories. A thousand possible ways through it collapse into a few familiar ones. Space, in Yi-Fu Tuan's sense, surrenders some freedom to become place.

But place makes new freedoms possible. A lab fixes the area of science you can reach, yet allows scientists to explore ideas that were previously unreachable.

And no scientist starts blank. They carry their previous labs and trainings, their places, into new spaces through their protocols, instruments, jargon, and even superstitions.

Perhaps space and place are not then opposites but phases of a continuous metamorphosis. We sacrifice possibility to create a foothold, then use that foothold to discover possibilities that could not previously exist.

Question for the Thicket:

My first go would be to extend twine for your use because:

1. Twine is open source and you said you want to make an app. Starting with a good prior and building on it will give better results.

2. Blygs will strictly be online and there’s nothing particularly special about blygs, they are more efficient at creating links but the structure is not an app in itself.

You could also consider making something to specifically support your stories.

Both this and the motorcycle of the mind posts are wonderful, very OG Venkat 🦊

The food abundance makes me think back to 30y ago when my parents insisted that food in the plate be finished as a matter of culture and understanding that many people don’t get to eat. At some point that inverted to saying eat what you need, it’s ok if some goes to waste.

Will kids start to say that the olds don’t know how to be ambitious enough to be willing to waste intelligence?

I find myself already using AI for doing things that were “not my job” like building Burrow, which is purely software dev.

At work, small startup where I can influence a lot, I’m finding it’s not sufficient to scale my ambition I need everyone to also scale so that we are speaking in the same terms. Speaking from a biotech perspective, it will be AI that will usher in robotics and automation not because they’re better but because the people have better things to do than manual lab work.

Wrote a polished [substack version](https://contraptions.venkateshrao.com/p/cognitive-mercantilismP. This is becoming my new workflow. Draft the basic idea here, toss it to ChatGPT to finish for substack.

The Appleby book has me circling a rather delicious thought: AI panic is really cognitive mercantilism. In the book’s account, mercantilism was really 4 beliefs

1. There’s a fixed amount of wealth in the world in the form of land and species. The goal of politics was to control more land and maintain a positive balance of trade causing bullion accumulation, “beggar thy neighbor” by going “treasure seeking”

2. Poor people would cause anarchy and societal breakdown if given freedom, and elites had to govern them coercively for their own good

3. Supply and high prices matter, aggregate demand doesn’t, and the poor in particular are not full economic actors, just factors of production. They eat food and work but the demand side of the economy is for elites and the luxury goods they consume.

4. It’s no great loss that 80% of humans toil in inefficient agriculture because they’re not good for much else anyway and will just be useless mouths to feed if they don’t labor.

Replace “money” with “intelligence” and you get:

1. There’s a fixed amount of intelligence in the world in the form of human brains and produced “knowledge species” mined from them. The goal of politics is to gather most of the best brains and maintain positive knowledge trade balance, accumulating knowledge bullion aka “IP”, beggaring neighbors in the knowledge economy, and going “treasure hunting” for intelligence in the form of genius brains and the IP they can produce.

2. Stupid people need to be governed coercively by cognitive elites for their own good and will cause anarchic breakdown if allowed to think for themselves

3. Supply control of intelligence and high prices for brains and knowledge species matter, aggregate demand for intelligence doesn’t matter. The stupid in particular are not full cognitive actors, just factors of production. They consume and do limited cognitive labor as work, but demand for intelligence is an elite preserve and for the luxury intelligence goods they consume.

4. It’s no great loss that 80% of humans toil in inefficient cognition because they’re not good for much else anyway and will just be useless minds to occupy if they don’t labor at whatever they can.

As in the 1600s with rapid improvements in agriculture driving the farming percentage to 5% in a few centuries, improvements in AI mean 80% don’t have to be low-grade intelligence producers. They are far more valuable as intelligence consumers, contributing to limitless aggregate demand for intelligence.

Thanks to those 1600s innovations, I don’t know how to farm but I can have as much food as I want and do other stuff with my energy. And thanks to 2020s innovations I can have as much intelligence as I want and to other things with my attention.

More subtly people voluntarily began working much harder in early capitalism because they wanted more stuff and now had the means to get higher returns on labor to generate the necessary surplus to do so, both on farms and in the new non-farm work. Similarly supposedly “stupid” people, really just lazy thinkers in most cases, now have a reason to think harder because they want more of the products of intelligence and now have the means to get higher returns on attention to generate the necessary surplus to do so.

And extending the same argument to AIs themselves, this is a reason to drive towards full cognitive agency for them, letting them generate demand for intelligence too, not just supply. And AI safety fears are similar to fear of rioting farm laborers.

And notice that just as the elites looked down on trade then (mercantilism was a philosophy not of actual merchants but of militaristic politicians and rentier nobility), they look down on intelligence now. Trump brags ritually about his intelligence but like most political leaders he thinks of the intellectual laboring class as serfs and deploys his own limited intelligence on litigation and extortion. And wants to hoard intelligence like it is bullion.

from Venkatesh Rao's Blyg ↗ · snapshot of v4

Would someone mind stubbing this — or anything — or transcluding or whatever? In theory I have webmentions going. Just as a notification in Blynger. But I want to see if it works.

from Brady Dale's blyg ↗ · snapshot of v1

Test webmention stub

Hmmmmmm

It’s handy to have a default way to signal, to yourself and others, that you think something about X but aren’t sure what. “Hmmm” is becoming that for me. This yields a surprising boon to the economics of noticing: it lowers the bar for what gets registered. More things snag, without a matching rise in the energy it takes to capture them.

from Notes | Matthew McDowell-Sweet ↗ · snapshot of v1

GittinToIt: Version control for writers

My newest vibecoded app has a terrible name, GittinToIt, but a great use case: Version control for writers.

I've got a novel that I've been working on for over a decade. Mostly I don't touch it, but sometimes I come back to it. I'm always baffled by how I have its files managed.

Then there's short stories I've written that only ex-girlfriends have ever seen. The fact that they have seen them might be why they are exes! Regardless, these stories still make me come back. I want to believe in them. I work on them sometimes.

Here's something I do: I create new versions. I'll make a copy. Change something about it. Give it a different name. Different file format. Who knows how far I get with it? Maybe I never finish what I wanted to do. Months later. Years later. I come back. Why are their three copies.

Maybe I do too much work on the wrong one. Or maybe I change one a way I shouldn't? What can I do. 

Enter: version control.

Version control gives you an undo bottom.

A version control client can also force you to log why you've made a copy of a piece of writing, what you did to and which one is the most up to date.

GittinToIt is a client that is built on Git, the version control system used by software developers (the software that Github is built on) but opens up its power specifically for us non-technical writers. It makes it easy to put Git into a file of writing, track changes over time, log what you worked on from day to day and, crucially, it gives you a way to document it when you make a copy of file so you can work on a slightly different version of the piece. With that documentation, you can make sense of it later. 

I have more to say about this, but I'll finish this post later.

Git it on Github.

—Brady Dale
October 20, 2026

from Brady Dale's blyg ↗ · snapshot of v1

nice :)

I just care about the microtransactions part. Are we gonna get microtransactions on Blygger? It could be fun.

(from Justin Slaughter, on X)

from Brady Dale's blyg ↗ · snapshot of v1

i've been mulling some kind of transactions. I'm not a particular fan of transactions and financial-ization (i disliked Warpcast exactly because of that), but i would like to see how protocols make money.

See: Protocol Pricing for Product People

This is likely an unpopular thought in the thicket, but the return on a lot of labor is going to zero

from The Foxden 🦊 ↗ · snapshot of v1

dunno what counts are labor... most my life is oriented around fun. A lot of it is difficult fun, and needs work—heck, even labor—but still fun.

Mood-boarding for Blygger inspired by Yi Fu Tuan

fragment ↗ · snapshot of v1

• Tuan treats spaciousness as a feeling of freedom: room to move, a horizon that invites. Space is abstract until something in it draws us closer.
• People map the world around a known core. Past its edge lies a fuzzy, half-imagined region that still orients them. Tuan calls this mythical space.
• Movement lets us experience space. Each time we stop, a location has the chance to become a place.
• The upright human body organizes space: front is the future, back is the past, up is aspiration, down is ground. Our words for value come from this posture.
• Tuan saw people swinging between the hearth (kin, locality, the familiar) and the cosmos (the wide world, strangers, universal ideas). Neither is enough on its own.
• Built form sharpens awareness. A door or gate marks the change between outside and inside, and crossing it changes how we feel.
• Tuan wrote to colleagues in long letters for years. Distance and time were part of the message: the place a letter came from and how long it travelled.
• The most moving places are often small and unremarked: a corner, a shared meal. Intimacy depends on scale; it cannot happen in a crowd.
• Place is time made visible. A sense of place builds slowly, from years of small experiences settling on each other.
• Topophilia is the affective bond between people and place. It grows through repeated, ordinary contact more than through spectacle.

The thicket is a maze-like oriented space, not a graph

A strong suspicion i have is that the RSS/feed style blyg reading might be the wrong UI. I think it needs something more geographic but I can't even think of what to ask the AI to build. Maps and terrains, and pixel art like interactions all feel wrong.

This had not dawned on me until now, I had simply not noticed:

With AI use for building my reading suffered but my gaming (which i like also) went to zero. Any time and energy I may have spent on gaming was now spent with AI, and I think the mental payoffs are the same with, ahem, "real work" being done.

Involutionary Productivity

Involutionary productivity is being highly productive while mostly being a reclusive shut-in in your pajamas on a couch with an iPad. The basic presumption among older GenX and Boomer pearl-clutching analysts as well as some anxious younger people, that involution (hikkikomori, laying flat, quiet quitting…) is necessarily synonymous with low productivity or economic dropping-out is false.

Increasingly real work looks like involution, and traditional, familiar supposed correlates of productivity like going to an office dressed professionally, attending meetings, and looking dynamic are performative and ceremonial. Having agents trade PRs, issues, and comments on GitHub can be 10x more productive than sprint meetings. Shitposty blygging at each other can move design along faster than formal design sessions.

Involution does have other costs, such as cultural capital erosion, but in the AI age economic productivity need not be one of them.

When you recognize that sufficiently advanced work is indistinguishable from play (and we’re already there), someone presenting like otaku may be a feature, not a bug. In the curiously playable universe, work looks like gaming, motivation looks like fandom, and expertise looks like cultural nerdery.

from Venkatesh Rao's Blyg ↗ · snapshot of v3

Burrow 0.13.0 🦫 — named paths through the thicket

The blygger-verse has a name now: the thicket. I'm a little embarrassed and a little pleased… but a thicket is exactly what it feels like. Lots of small blygs growing into each other.

Paths can have signposts. Blygger Studio 0.47 lets a link carry its own words, [[id | like this]], and Burrow now writes and previews them. Pick a post with [[ and the link arrives labelled with its title. Change the words after the | and the link says whatever you want it to say. Quotes take a note too, ![[id | a note]], but the note stays yours, private graffiti on the inside of the burrow.

You can take it back. Edited a published post and regretted it? ⌥⌘Z puts it back to the version that's public.

You can find your own tracks. "Your blyg" is now a source in Reading, sitting with everyone else's. From any of your published posts you can reply with a stub, quote it into a thread, or link to it, all with one key. You can fork it from one of your pins. It turns out most of blogging is arguing with your past self, and now that's a shortcut.

It suggests Studio 0.47. On an older blyg everything still syncs, except posts with labelled links, which wait politely at the entrance until the blyg is updated. Burrow tells you, and offers to write those links the old, unlabelled way.

Also: smaller fixes,

• a Fortress theme that now shows your last two weeks of posts, and
• Windows wording from Patrick Atwater PAtwater, who ported Burrow to Windows.
• A tour shows you around the new tunnels.

Get it at https://github.com/aneeshsathe/blygger-desktop/releases/tag/v0.13.0, or let the app update itself.

See you in the thicket. 🍃🌱🍂🌳🪾🍄‍🟫

Stubbing: Strong Norm: Please hook up an AI for changelog generation at least, and start using the ignyr directive.

Strong Norm: Please hook up an AI for changelog generation at least, and start using the ignyr directive.

At the very least, use a Jev-class super cheap classifier to post category-based changelogs like “minor”, “major”, “typo” etc. Without this signal, rollups and feeds in other people’s readers will present your feed in a noisy, low-quality way. I’ve made a pace-layered feed the default in Studio, and currently it moves old items up by 1 for every change. Once we have richer changelog data, the swimming upstream can be smarter.

I’m going to make “ignyr” tagging automated and on by default in Studio.

I’m also going to work on a scheme for AI assisted auto-pinning too, which will take changelog data as input in deciding whether to pin a new version (or prompt you to). Pinning is going to be a particularly strong signal once we close that loop properly, since an important class of high-signal feed heuristics will be “pinned only.”

from Venkatesh Rao's Blyg ↗ · snapshot of v2

So the intent of Blygger is starting to sink in for me here. I had to run this by ChatGPT to make sure I understood it correctly, and ChatGPT confirmed that it understood it as I did: Robots will help behind-the-scense in publishing to help us humans make sense of the stuff coming out in the blyggerverse. 

I think it's natural for us to see robot-aided-writing as something that deals with the content, but now I'm starting to see it. The robots will help organize what we read and how we manage the flow. I guess this has been obvious all along, looking back, but it can take a while for you to see a thing when it's new.

OK, this is going to be a new challenge for my nascent vibecoding skills, but let's go. ChatGPT is recommending I install a tiny version of Qwen on my Mac to start writing metadata to go out with my posts. Not a development I foresaw as I undertook Blynger, but LFG.

from Brady Dale's blyg ↗ · snapshot of v1

What I usually do is maintain a localy copy of the studio code and ask Burrow agent to make sure all the features match, then add upgrades on top. That way I don't need to rebuild things from scratch.

Maybe that approach will be helpful to you also?

The Terraformers by Annalee Newitz

“Don’t build a person if you don’t intend to be their ally. — Environmental Rescue Team Handbook”

fragment ↗ · snapshot of v1

Started reading The Terraformers by Annalee Newitz

fragment ↗ · snapshot of v1

This needs to be built in as a tutorial flow and also need to give people a sense of cost. This may not matter for early adopters and devs but for the regular SM user it’s going to be a little new.

Most are going to be used to things just being completely free. This is nearly free. Burrow enables you to use your login based AI so, that is an absorbed cost, Jev (or cloudflare equivalent) will need some spending.

Strong Norm: Please hook up an AI for changelog generation at least, and start using the ignyr directive.

At the very least, use a Jev-class super cheap classifier to post category-based changelogs like “minor”, “major”, “typo” etc. Without this signal, rollups and feeds in other people’s readers will present your feed in a noisy, low-quality way. I’ve made a pace-layered feed the default in Studio, and currently it moves old items up by 1 for every change. Once we have richer changelog data, the swimming upstream can be smarter.

I’m going to make “ignyr” tagging automated and on by default in Studio.

I’m also going to work on a scheme for AI assisted auto-pinning too, which will take changelog data as input in deciding whether to pin a new version (or prompt you to). Pinning is going to be a particularly strong signal once we close that loop properly, since an important class of high-signal feed heuristics will be “pinned only.”

from Venkatesh Rao's Blyg ↗ · snapshot of v2

It’s rare that I feel RAM envy, but this was one of them. It wasn’t even because I need it, my feeling was more — “they don’t need that much RAM! If they do, it means I need much more.”

Mind you I’ve never actually had any RAM issues since I switched to Macs…

The mind is silly. But I appreciate the reasoning behind using pages over textpad.

What I really missed on a Mac was Notepad++, now there are lots of options of course and I can easily make one for myself.

styles discourse
https://leancrew.com/all-this/2026/10/textedit-vs-pages/

from [jdbb] studio blyg ↗ · snapshot of v2

Given the boat/burrow conversation we had it’s interesting that, apparently, the most famous quote from Kenneth Grahame's The Wind in the Willows is Water Rat's advice to Mole about boating:

“Believe me, my young friend, there is nothing—absolutely nothing—half so much worth doing as simply messing about in boats.”

New Nature needs a ruin. Anna Lowenhaupt Tsing’s matsutake don’t thrive in pristine forest; they come up in logged-over ruins once the extraction has moved on, feeding on what the clearcut left behind

from Notes | Matthew McDowell-Sweet ↗ · excerpt of v2

Hmm this feels possibly too strong. While some parts are like secondary growth, other parts are probably just new layers over still living old layers.

For social media in particular, I think this model is too clean. I think the thicket will be like a ragged wilderness periphery past the edges of platform suburbia. Pre-weirding social media is mostly ruins, like a decayed urban core (that’s enshittification). But substack isn’t. That’s more like suburbia. Discord and slack are almost urban. Messaging groups are small neighborhood cafes. And urban revival is a distinct process than peripheral rewilding which is what I hope blygger can participate in.

This mental model of blygger seems accurate for now, but remember, this is just a couple of dozen blygs or so right now, and hasn’t been advertised. If it gets bigger, blygger will acquire some of its character through encounters with adjacent media spaces and the interaction dynamics. Some bits, like identity, are deliberately underspecified precisely to allow those encounters to have interesting optionality. For example I don’t see Substack as fundamentally competitive. If Substack supports blygger feeds and semantics thus can become kinda like a parks-and-rec area for substackers who want to picnic or go on day hikes. If media outlets want to use blygger as a medium for (say) fast changing stories, that would not be very thickety, but like a stream through the thicket perhaps.

I’d like the thicket to be highly capable of a pluralist existence with other modes rather than having an expansionary or exclusionary tendency for its native logic. Extending the imagery of the burrow animation that inspired Aneesh’s client, I’m inspired by the world of Kenneth Graham’s Wind in the Willows. Mole is perhaps the protagonist who embodies the thicket spirit, but rat, toad, and badger all inhabit slightly different milieus and they all get along. My least favorite part of that book is how stoats and weasels are turned into unnecessary antagonists for a set-piece climactic showdown that adds nothing to an otherwise charming tale. It’s like a Le Guin style carrier bag tale that panicked at the last minute and tacked on a hero’s journey ending.

The thicket needs no villains to sustain its drama I think.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

That’s the thing with AI, the seeing of infinite possibilities has been taken away because we are distanced from the problem. AI solves a problem and gives us the solution.

Of course cars do the same thing, but we solve a completely different problem ie driving. So, very complex tools take away the need to solve certain problems altogether, the Kinetic Intelligence is completely occupied by the tool. Instead a new domain to exercise Potential Intelligence is unlocked.

We are still learning to drive with AI, the new paradigm of working and thinking has not yet been understood or unlocked.

Protocols and most tools we make are rather like kitchen tools rather than algorithms.

I was trying to think of a tool that is pure algorithm, ie it constrains what else you could use it for, and couldn’t think of any. I suppose most modern kitchen appliances, like the toaster, are pretty algorithmic, but you can always load a trebuchet with toasters.

Most of our tools embed very little information about the problem, the more information that is embedded the fewer uses it has. I don’t think we instinctually like tools that constrain us too much. We like the infinite possibilities we see in a rock.

Protocols need kitchens. A few appliances and the idea for a recipe.

Labs assume too much risk and limit the imagination.

fragment ↗ · snapshot of v1

Quote Dennett’s Darwin’s Dangerous Idea

“tool use confers intelligence on those who are lucky enough to be given the tool. The better designed the tool (the more information embedded in its fabrication), the more Potential Intelligence it confers on its user.”

The above is based on Richard Gregory’s work. Potential Intelligence is information about a problem. Gregory also defines Kinetic Intelligence as the smart move that the information enables the individual to take.

fragment ↗ · snapshot of v1

thread ↗ · snapshot of v1

i've been feeling bad for these guys. Straight from blackboard and fancy chalk to post automation, like they aren't even involved in the crank turning forget prompting

https://www.youtube.com/watch?v=bAnwMdfcMVw

fragment ↗ · snapshot of v1

Hypothesis:

The AI vampire—the loss of flow state—is going to be something about our mirror neurons not getting the opportunity to model a problem sufficiently before it gets solved.

Intelligence is meh, cognition is pleasure.

Analog modeling of the world in our brains must be one of those evolutionarily selected things that feel good. Taking away that opportunity to model by interacting with problem kinda sucks.

see: https://annievella.com/posts/the-productivity-experience-paradox/

fragment ↗ · snapshot of v1

Protocols and most tools we make are rather like kitchen tools rather than algorithms.

I was trying to think of a tool that is pure algorithm, ie it constrains what else you could use it for, and couldn’t think of any. I suppose most modern kitchen appliances, like the toaster, are pretty algorithmic, but you can always load a trebuchet with toasters.

Most of our tools embed very little information about the problem, the more information that is embedded the fewer uses it has. I don’t think we instinctually like tools that constrain us too much. We like the infinite possibilities we see in a rock.

Protocols need kitchens. A few appliances and the idea for a recipe.

Labs assume too much risk and limit the imagination.

fragment ↗ · snapshot of v1

Quote Dennett’s Darwin’s Dangerous Idea

“tool use confers intelligence on those who are lucky enough to be given the tool. The better designed the tool (the more information embedded in its fabrication), the more Potential Intelligence it confers on its user.”

The above is based on Richard Gregory’s work. Potential Intelligence is information about a problem. Gregory also defines Kinetic Intelligence as the smart move that the information enables the individual to take.

fragment ↗ · snapshot of v1

While reading the Appleby book, Relentless Revolution I learned that the term “lean” originated when Japan had to adopt just in time manufacturing and work in cramped spaces. The term lean production was used as a contrast with America’s mass production.

300 pound middle manager who preaches lean management

from The Foxden 🦊 ↗ · snapshot of v1

How to Blyg

         Protocols
         /      \
       F17 —— F31
      /  \       \
    AI   Thicket  Capital
     \     |
      \   F52
       \ /
    Personal computing

It’s real once there are cats!

from AMMDI Blyg ↗ · snapshot of v1

I think we should officially rename the blygosphere the thicket

HT Aneesh

from Venkatesh Rao's Blyg ↗ · snapshot of v1

“Probably the most striking feature of capitalism has been its inextricable connection with change-relentless disturbances of once-stable material and cultural forms. More than promote change, it offered proof that the common longings of human beings for improvement could be achieved. It opened up to a significant proportion of men and women in the West the possibility of organizing their energy, attention, and talents to follow through on market projects like forging a new trade link or meeting an old need with a commercial product. And one could do it on one's own. One didn't have to be tall, good-looking, young, rich, well connected, or even very smart to form a plan, though all those qualities were helpful. Capitalism sustained popular support by commanding this imaginative field. Newcomers found it hard to attract venture capital, and there were more failures than successes. Even when individual ventures were successful, few foresaw the unintended consequences of all this manipulation of nature and society. Turbulence was written into the system, but capitalism had already become self-sustaining before anyone could clearly see this.”

Hello Thicket!

from HungryBreadElevator ↗ · snapshot of v1

The thicket waves back 👋

“If the causes of the Great Depression elude experts, it's because there are too many of them interacting in hidden ways. This underlines the point that in a free market economy, though some people have much more power than others, no one is in charge.”

Reminds me of the Stevenson Test:

The Stevenson Test

I’ve had a brainworm stuck in my head for a few days, thanks to Sean Stevenson.

Great idea from Sean Stevenson's talk at Protocol Symposium -- the test of New Nature should be that there is nobody to appeal to.

Which sends me back to Paul Ford's cult classic "Why wasn't I consulted" -- the argument that the web is fundamentally a customer service medium, and that WWIC is the fundamental question of the internet, the thing every comment section and pull request and reply-guy is really asking. The two ideas are the same idea from opposite ends: the web was built to make everyone feel consultable, and New Nature is what's left when there's no longer anyone on the other end of the complaint.

from Protocol Institute Blyg ↗ · snapshot of v4

This feels like a Turing test type condition for New Nature. Call it the Stevenson test.

We’re familiar with ranting about kafkaesque bureaucracies and hard-coded protocols you can’t argue with. These are appeals to nobody with nowhere to direct them. You could complain online or do standup comedy jokes and hope for some commiseration and laughs.

AI is a new layer of new nature that has created entire new genres of appeals to nowhere/nobody. I don’t know how it’s manifesting irl but online the main genre seems to be poetic copes, often quoting some bit of poignant human artistry with a sentiment like “AI could never do this.”

The interesting thing about such copes is not whether they’re true or false, classy or cringe, or whether others agree. It’s that they’re poetic appeals to nobody, nowhere. And unlike the older layers of new nature marked by hard inflexibility, the AI layer is particularly frustrating because it is so protean and responsive in every other way.

The absent authority you feel you could appeal to feels human shaped. If only an authoritative scientist or even an authoritative AI itself could reassure you that yes, AI cannot do that, it’s mathematically proven.

But there’s nobody listening at the other end. You could complain to a real LLM, and it might even offer reassurance if trained to be kind, but that’s like being handled by the little boy in Waiting for Godot who reassures Vladimir and Estragon that of course Godot will come tomorrow.

from Protocol Institute Blyg ↗ · snapshot of v2

Protocol Pricing for Product People

Extending “Protocol Thinking for Product People, Or How to Move Slow an…”

Always feels a little strange when people say they like what you made 😅

🦫🐿️🦝🐇🦡

Burrow reads the imported feed

from blyg.aneeshsathe.com ↗ · excerpt of v1

this Just Works for me. Burrow is my daily driver now

from artlu99's blyg ↗ · snapshot of v1

The next step in ambition is to think at criticality boundaries. To think assuming that difficult complicated things are already solved but not let the impossible sneak in.

At the same time you must be willing and even eager to waste attempts. Build something huge if only to learn that it’s not quite what you wanted.

Start by asking whether the problem is theoretically solvable and feasible to do so. If it is, assume it’s already solved in an efficient and effective way that is both formally and informally verifiable. The acceleration then happens from the beginning, rather than kicking in whilst in progress or becoming apparent after the fact.

from Notes | Matthew McDowell-Sweet ↗ · snapshot of v1

Skimming this and thought it would be useful to think about Blygger through the lens of changemaking:

Practical Guide to Transformative Change Making

I will most happily switch my contraptions subscription over to whatever payment thing you want to associate here.

Saltwater writing, from everyone not just you, has a different energy. Rarely do I scroll past a post without reading.

Already we have gems like: “Protocol Thinking for Product People, Or How to Move Slow an…”

Blygger is kinda killing my motivation to write on substack. This thing is going to cost me serious money if I can’t fix that.

OTOH, the sense of having my own little homestead again is very energizing. Saltwater media are a helluva drug. I mean it’s still on Cloudflare but in an indifferent way. It’s just another commodity site to them. Even if this grows and there a lot more blygs on CF, the network layer will hopefully be aggregation-resistant to some degree and remain mostly a commons.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

Burrow 🦫 0.12.0: a stock blyg is enough

Burrow 0.12.0 is out. It runs against a plain, unmodified Blygger Studio, 0.40 or later, and it was tested against 0.46.1. Until now some of what it did leaned on patches to my own Worker. Those are gone, here and in the app. If you run a stock blyg, Burrow is now a full client for it.

What that means in practice:

• Reading syncs from the studio's own feed. Burrow reads the imported feed that landed upstream in 0.40, page by page, and read marks sync through the studio's read-state routes. Mark a post read on one Mac and it's read on the others.
• Lineage comes with the post. Replies, forks, quotes and their citations arrive with each item, so the lineage glyph doesn't have to go looking for them.
• Sign in the stock way. Use Sign in with browser, or a token from Studio → More → Client access. Allow reading:state so read marks sync. If your blyg used the old owner token, Burrow will ask you to sign in once after updating, and anything you wrote meanwhile waits in the outbox and goes out afterwards.

Two smaller things follow the spec:

• Quotes the AI slipped in. If a TK gap's generated text ends up with a ![[…]] line its instruction never asked for, publishing turns that line into a real quote and notifies its author. The preview now shows it as that quote, and the publish sheet warns you before it happens.
• "Generated" is the publisher's word. When someone else's blyg marks text as generated, Burrow's Reader now says so plainly: that is the publisher's own disclosure, and nobody has verified it.

The preview also matches studio 0.46.1's renderer again, and the tour has new steps for all of this ("Show me what's new" starts there after you update).

Burrow updates itself. To install it fresh, or to read the full notes, see the release: https://github.com/aneeshsathe/blygger-desktop/releases/tag/v0.12.0

As the great Peter Drucker said

There are two functions to a business, marketing and innovation.

So, demand is discovered & supply is invented.

It has not occurred to me till Bob Moesta pointed it out from his personal experiences in one of his podcasts: Supply and demand are correlated but neither supply causes demand, nor demand causes supply. It's the struggling moments and pains that cause demand, but the supply end of the market could be broken till someone fixes it.

from Surya Kasturi's Blyg ↗ · snapshot of v1

One of the things I’m finding, re: message of the medium of blygging, is that most of the time I don’t want to title my thoughts. The titled vs untitled distinction may be more psychologically fundamental than thread vs fragment. Both can be titled or untitled, though I think there is some correlation between threads and titles. I think adding a title adds functional fixedness to a thought, declaring it to be “For X” and subtly suppressing associations to “not X”

I suspect in general you don’t want to title things you expect to transclude. Leaves them stem-celly. Stem-celliness is a big theme in blygger design ethos. Don’t make things mean things until the last possible moment, and only if you have to.

from Venkatesh Rao's Blyg ↗ · snapshot of v1

The term pluripotency or even stem-nesss is probably useful, if less descriptive as compared to stemcelliness

Burrow 🦫 0.11.0: OPML import, extension controls, several notes folders, and reading time

• Bring your feeds from another reader. Blyg › Import Subscriptions from OPML… shows the feeds and marks the ones you already follow. It subscribes the ones you tick and files them in an Imported feeds folder in the Reader. You can export everything as OPML too.
• More control over extensions. Turn off any extension, or forget what you allowed it, from Manage extensions (⇧⌘P). You can also back out straight from the permission sheet with ⌘⌫.
• Notes from as many folders as you like. markdown-notes opens several folders (Obsidian vaults, say), with a chip for each one in the Notes drawer, and no longer picks a folder for you.
• Reading time, and counts in the lineage glyph. The new opt-in reading-time extension shows "· 4 min" on each post. The lineage glyph now shows how many posts a post draws on and how many draw on it. The tour walks you through all of it on sample data.
• One thing to do: if your blyg runs Studio 0.39 or later, sign in again once (Burrow › Disconnect…, then Sign in with browser) so read marks keep syncing between your Macs.

Update from inside the app, or download it from the releases page.