{"blyg":"0.3","id":"2mzqh4jt3ye14xm6sr5gf32cah","kind":"thread","version":1,"at":"2026-10-07T20:11:32Z","note":"RFC-2 open for comment until 2026-11-04.","pinned":true,"origin":"https://blyg.blygger.org/","author":{"name":"Venkatesh Rao","url":"https://blyg.blygger.org/"},"content_md":"\n# RFC-2 — Comments sections: a curated display of responses, every comment a real item\n\n**Request for comments · non-normative · OPEN FOR COMMENT until 2026-11-04 on\n[blyg.blygger.org](https://blyg.blygger.org/t/2mzqh4jt3ye14xm6sr5gf32cah/) (#66); without a blyg,\ncomment on [blygger-spec#15](https://github.com/blygger/blygger-spec/issues/15) · session 40, 2026-10-07.** Drafted by Opus 5.5 at Venkat\nRao's request; edited the same session by Fable 5.1, whose rulings on the seven open\nquestions are section 11. This proposes a **Recommendation for clients that want a\ncomments section**. Like a technical note, an RFC constrains nothing. Blygger Studio\nwill not implement it; its public responses list stays a citation trail. After the\ncomment period it is published as guidance for the clients that choose to build it.\n**It depends softly on RFC-1** (mentions across identifier schemes, section 9): kind 1\nand kind 3 need nothing from it, kind 2 takes its address book, provenance and\nbylines, which is why the RFCs are ordered this way. Written against protocol 0.3 as\npublished on 2026-10-07; no pre-1.0 version promises anything (#21).\n\nThe medium's first answer to \"how do I comment\" is **from your own blyg** (kind 1,\nsection 5). Hosted comments (kinds 2 and 3) are an on-ramp for people who have no\nblyg yet, and the house that hosts them takes on their accountability. The comment\nperiod of this RFC runs that way itself: comments on it are stubs on\n`blyg.blygger.org`'s RFC item (#66).\n\n## 1. The question\n\nComments are the most requested feature from people running blygs. Venkat named\nthree kinds:\n\n1. **Responses from other blygs** — Webmentions that fit a pattern, such as a stub\n with a short note, listed under the original item as comments.\n2. **Signed-in commenters** — people who sign in to *this* blyg with distinct\n identities and comment in an ordinary threaded comments section. Each comment\n goes out on the wire as an ordinary top-level item, so the thread is\n flattened to fit the spec.\n3. **Anonymous commenters** — if the owner chooses, a form whose submissions are\n vetted and then published as items under a byline such as `anon` or\n `anon 7f3k`.\n\nThis RFC recommends how a client builds all three, and argues that none of them\nneeds a wire change.\n\n## 2. The stance: no reply primitive, a comments section is presentation\n\nThe protocol has refused a reply primitive since #12 and says so at §16.8: \"a\nnetwork of soapboxes, not a conversation medium\". §10.6 adds that a stub is \"not a\nreply. There is no thread of replies, no conversation object\". A Recommendation for\ncomments sections has to leave that stance intact. It can, because the stance is\nabout **what the wire carries**, and a comments section is **what a page shows**.\n\nThe whole recommendation rests on one idea:\n\n> **A comments section is the owner's curated display of published responses.\n> Every comment is a real item at some origin. Each one is a stub of the item it\n> answers, under its writer's own byline. The tree is rebuilt from `stub_of` for\n> display and never exists on the wire.**\n\nEverything the design needs is already built:\n\n- `stub_of`, the response marker (§10.6);\n- verified mentions, which tell an origin it was answered (§15);\n- curation display, which lets a page show other people's content with attribution\n (§13.5); §13.5 already names verified mentions as displayable under that rule;\n- per-item `author`, which puts many writers on one origin (§5.5, `tn-3` shape B);\n- withdrawal, the only exit (§9).\n\nWhat the protocol does *not* give is a way for anyone to put words on a target's\npage (§15.5). Under this design they still cannot. **The owner** displays responses,\nas curation, and can stop displaying any of them.\n\n## 3. One display path for all three kinds\n\nThe three kinds differ in who publishes the comment and where. The comments section\ndoes not have to care, because each kind ends up the same way:\n\n| Kind | Who publishes the comment | At which origin | How the original's page learns of it |\n|---|---|---|---|\n| 1. Response from a blyg | the responder | their own | a verified `stub` mention (§15.4) |\n| 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 |\n| 3. Anonymous, vetted | the house, under an `anon` byline | the comments origin | same as kind 1 |\n\nSo a client builds **one** renderer: the verified stubs of this item, with the stubs\nof those stubs nested beneath them. Kinds 2 and 3 are a publishing tool that the\nhouse runs on behalf of people who have no blyg.\n\n## 4. Where house-published comments live: a comments origin\n\nKinds 2 and 3 are published by the house. There are two places they can go.\n\n**Option S — the same origin as the posts.** This is conformant, but every comment\nis a publish event. §7 puts one feed entry per publish event, and §6.2 lists every\nitem ever published. Subscribers to the house's essays would get every\n\"great post!\" in their reading list, every edit to a comment would resurface it, and\nevery moderation withdrawal would leave a `withdrawn` entry in the feed. For a\nblyg with a handful of comments a month that cost may be acceptable. For a busy one\nit turns the house's soapbox into its own comment stream.\n\n**Option C — a sibling comments origin. Recommended.** The house runs a second blyg\nnext to the first, for example `https://house.example/comments/` (path-mounted, #14)\nor `https://comments.house.example/`. All comments the house publishes go there.\nEach one is a stub whose `stub_of` names the post on the main origin.\n\nWhy C:\n\n- **The main feed stays the house's own writing.** Readers who want the\n conversation subscribe to the comments origin. Its blogroll entry, or a link on\n every post, makes it one click away.\n- **It reduces kinds 2 and 3 to kind 1.** A stub from the comments origin to the\n main origin is a cross-origin reference. It sends a real mention, and the main\n origin verifies it exactly as it would a stranger's. Since #61 a document under\n `/comments/` cannot verify in the name of `/`, so the two origins cannot speak for\n each other even on one host. One renderer handles everything.\n- **The house collects every reply to the comments it hosts.** A reply to a hosted\n comment, from anyone, is a stub of an item on the comments origin, so the\n mention arrives there.\n- **Accountability is legible.** By `tn-3`'s test, the comments origin is a masthead:\n the house withdraws anything on it and answers for everything on it, which is\n what moderation is. Its manifest `author` names the house, for example\n `{ \"name\": \"House comments\", \"url\": \"https://house.example/\" }`.\n\nThe cost is a second origin with its own deployment, its own archive, its own\nWebmention endpoint (replies to hosted comments arrive there) and its own\npermanence (withdrawal endcaps are served forever). A client that offers comments\nshould run both origins from one install, so the owner deploys one thing. The\ncomments origin must also **import the main origin** as a subscription, because a\npartial transclusion in a comment resolves only against a local or imported item\n(§10.2); one install can share the store, but the resolution rule is the same.\n\n## 5. Kind 1 — responses from other blygs as comments\n\n### 5.1 What counts\n\n- **Relation `stub` only.** Being stubbed is being answered. Being *transcluded* is\n being quoted inside someone's own piece, and being *forked* is being descended\n from. Both are worth showing, but separately, for example as \"quoted in\" and\n \"forked as\" lists. Presenting them as comments would misstate what their authors did.\n- **Comment versus response.** A short stub reads as a comment and a long one reads\n as an essay. A client MAY show the full text of short stubs inline and only an\n excerpt plus a link for long ones. Measure the stubber's own words, leaving out\n the baked quote of this item (section 5.3). The threshold is presentation and the\n client's choice. §10.6 rule 2 tells readers to rely on the marker and never on\n body inspection. This does not break that rule: the marker alone decides *that*\n something is a response, and length decides only *how much of it is shown*\n (section 11, Q7).\n\n### 5.2 Showing the text, and keeping it honest\n\n§15.4 step 5 says a verified mention stores **no content**: \"what it points at is\nfetched from its origin when displayed, or not at all.\" A comments section that shows\ntext is therefore displaying another origin's content. The rules for that are\n§13.5's, and §13.5 names mentions explicitly:\n\n- **Fetch on display, cache briefly, refresh.** The receiver re-fetches the\n stub's live item document when showing it, through an ordinary HTTP cache. Edits\n are not reliably signalled: under §15.2, a stub whose target version did not change\n is not re-sent, so a refresh schedule is the only way to keep displayed text\n current (section 11, Q2–Q3).\n- **Gone means gone.** If the stub is withdrawn, re-fetched as an endcap, or the\n mention re-verifies as `gone`, it leaves the display. §13.4's retention rule applies\n as it does to any displayed import: show a pinned version only if the origin pins\n it, otherwise show nothing.\n- **Attribution every time.** Show the stubber's byline as their origin asserts it\n (§5.5 pass-through). Under RFC-1 it is an h-card, together with their origin and a\n link to the stub's page. A comment is never shown detached from where it lives.\n- **Sanitize as an import** (the reference reader's `importer/sanitize.ts` is a\n working model).\n\n### 5.3 Strip the quote of this item\n\nA stub usually starts by transcluding its target (§10.6 rule 2's aesthetic). Shown\nunder the target, that quote repeats the post back to the reader. A comments display\nSHOULD collapse any baked `blyg-transclusion` whose `data-blyg-id` is this item and\nwhose `data-blyg-origin` is this origin. A **partial** quote (`blyg-partial`) is the\nexception: it should stay, because \"replying to this passage\" is exactly what a\nreader needs to see. A collapsed whole quote can still show a small \"quoting the post\"\nmarker.\n\n### 5.4 Moderation\n\nDisplay is the owner's act, so the owner decides who is shown. Clients SHOULD offer\nthree modes per blyg, overridable per item:\n\n- **pre-moderated** — nothing shows until approved;\n- **post-moderated** — verified stubs show at once, and the owner can hide any;\n- **trusted** — post-moderated for origins in the owner's blogroll or address book,\n pre-moderated for everyone else.\n\nThe reference client's public responses list (studio, session 23) is the\npost-moderated mode, with links only. Hiding a comment is a display choice, never\na delete: the stub is the stubber's speech on their own soapbox (§10.6), and it stays\nthere.\n\n### 5.5 Depth\n\nReplies to a kind-1 comment stub *that comment*, so their mentions go to the\ncommenter's origin, not to this one. This origin sees one level of external\nresponses, plus any reply that also references this item. Showing \"N replies\nelsewhere\" would need a responses surface, and #41 and #47 closed that surface.\nClients SHOULD show one level and link through. Kind 2 and 3 comments have no such\nlimit (section 4: the house receives replies to everything it hosts).\n\n## 6. Kind 2 — signed-in commenters\n\n### 6.1 Signing in\n\nThe commenter signs in to the house's client with any provider the client\nsupports:\n- **IndieAuth**, the best fit: it proves control of the commenter's own URL, which\n is #35's identity directly;\n- **Mastodon or Bluesky OAuth**, which yield an actor or a DID;\n- **GitHub or Google**, which yield a profile URL.\n\nThe client records the commenter in its address book (RFC-1 section 5.1):\n- the identifier from the login gets provenance `bound`, because the house checked it\n at sign-in;\n- the commenter's display name is theirs to set;\n- `member` stays false: a commenter is a guest, not a masthead writer.\n\nCommenters receive a **comment scope**: a token in the shape #31 describes (bearer,\nowner-revocable), minted by the house's client to a guest at sign-in. This is the\nclient's own guest authentication, part of the write surface #31 leaves to clients,\nand it borrows only the token's shape from the owner's tokens. It can do only:\n\n- publish a stub on the comments origin whose `stub_of` names an item on the main\n origin or the comments origin;\n- edit and withdraw that commenter's own comments;\n- nothing else: no drafts that last, no hoppers, no subscriptions, no studio.\n\nThe byline is fixed to the signed-in identity, and the commenter cannot choose it.\nThis is the \"a member is a token with a member's scopes\" model (#38, `tn-3` section 2),\nwith a narrower scope.\n\n### 6.2 What a comment is on the wire\n\nA comment is a thread on the comments origin:\n\n```json\n{\n \"blyg\": \"0.3\",\n \"id\": \"3q8m1x…\",\n \"kind\": \"thread\",\n \"origin\": \"https://house.example/comments/\",\n \"author\": { \"name\": \"Ada Ruiz\", \"url\": \"https://ada.example/\", \"ids\": [\"did:plc:…\"] },\n \"stub_of\": { \"origin\": \"https://house.example/\", \"id\": \"7c9wk2…\", \"version\": 4 },\n \"content_md\": \"This is the part I'd push back on: …\",\n …\n}\n```\n\n- **Kind `thread`, because §10.6 makes stubs threads.** A comment that quotes a\n passage of the post uses a partial transclusion (§10.1). That is the\n quote-reply comments sections have always wanted, and it is verified.\n- **A reply to a comment** is a stub of that comment. Its `stub_of` names the\n comments origin. The display rebuilds the tree by following `stub_of` chains, so\n the wire stays flat.\n- **Edits** are new versions (§5.2). They get no feed vocabulary, and the comments\n origin's feed shows the edit like any other publish event.\n- **Delete** is withdrawal (§9). The commenter withdraws their own comments, and the\n house withdraws anyone's, which is moderation. The endcap stays, and a reply to a\n withdrawn comment keeps its place in the display with a \"withdrawn\" placeholder.\n- **Generated text** is disclosed through `generated[]`, as anywhere (§5.7). An agent\n can be a commenter under #38's rules: its own byline, an `operator` named, and\n content in every comment, since #36's line against content-free stubbing applies.\n\n### 6.3 Limits a client should set\n\n- **No transclusion of third parties by default.** A transclusion of another origin\n in a comment sends a mention from the house's comments origin to a stranger, on a\n commenter's say-so. Allow quotes of this house's own items, and make anything wider\n an owner setting.\n- **Pre- or post-moderation, as in section 5.4.** Signed-in commenters are more\n accountable than anonymous ones, but a comment, once out, is on the wire for good:\n withdrawal leaves an endcap, and other readers may have quoted it.\n- **Tell commenters what publishing means**, in plain words at the comment box:\n the comment is public, it can be quoted, and deleting it leaves a \"withdrawn\" marker.\n\n### 6.4 Commenters who have their own blyg\n\nIf the signed-in identity is a blyg origin, or the address book knows one for it,\noffer **\"respond from your own blyg\"** next to the comment box. That makes it a kind-1\ncomment, on their soapbox and under their accountability. A comment hosted by the\nhouse is the fallback for people without a blyg, not the default for people who\nhave one (`tn-3`'s withdrawal test applied to comments).\n\n### 6.5 Portability\n\nThe commenter's verified URL is what keeps their comments recognisable if they\nlater start their own blyg: RFC-1's `ids` and `url` match across origins once they\nare verified (#35 reader rule 2). As `tn-3` section 5 says, **the person is\nportable, the items are not.**\n\n## 7. Kind 3 — anonymous comments, vetted\n\nThis kind is entirely the owner's choice, and off by default in any client that\noffers it.\n\n### 7.1 Flow\n\n1. A form on the item's page takes the text and, optionally, a display name.\n It has no URL field: a URL nobody verified is exactly the unchecked claim RFC-1\n keeps off the wire.\n2. The submission enters a **mandatory pre-moderation queue**. For anonymous\n speech that is not optional, because approval is what makes the house's\n publication of it an editorial act rather than a pipe (#36). Machine triage MAY\n sort the queue. A person approves.\n3. On approval the house publishes a stub on the comments origin, exactly as in\n section 6.2, under an anonymous byline.\n4. The submitter receives a **one-time withdrawal link** at submission. Without an\n account, it is their only way to retract. Using it withdraws the item (§9).\n\n### 7.2 The byline\n\n- `{\"name\": \"anon\"}` when the client does not tell anonymous commenters apart.\n- `{\"name\": \"anon 7f3k\"}` when it does. The suffix comes from a **random token kept\n in the commenter's browser** and is stable across their comments while the token\n lives. It MUST NOT be derived from an IP address, an email address or any hash of\n one: those can be reversed by trying candidates, and an \"anonymous\" label that\n can be reversed is worse than none.\n- **No `url`, no `ids`.** Nothing about an anonymous commenter is checkable, so\n nothing is asserted. Bylines that are byte-equal group only for display within\n this origin (§5.5), never across origins and never as an identity.\n- Readers see the house's assertion, as with every byline (§5.5). A client SHOULD label\n these comments \"anonymous, approved by the editor\" so that the house's role is\n visible.\n\n### 7.3 Data the house keeps\n\nStore only what vetting needs. Keep the text, the browser token and a\nrate-limit key, and delete the rate-limit key once a decision is made. Never put\nsubmission metadata into the item document. The house publishes the words, not the\nperson.\n\n## 8. Presentation rules common to all three\n\n- **Different chrome for each source.** \"From their own blyg (verified)\", \"signed in\n via GitHub as ada.example\", \"anonymous, approved\". #35's first reader rule says to\n show verified claims as verified and everything else as claims. A comments section\n that makes all three look alike erases the differences readers most need.\n- **Order by observation time** (§13.7), not by the commenter's self-asserted\n `created`. A stranger's clock does not get to move their comment to the top.\n- **No counts.** No \"42 comments\" and no per-commenter tallies. This is #12's and\n #13's no-metrics stance carried into presentation, the reason the reference\n responses list shows \"a citation trail with no count\", and the reason #47 kept a\n responses surface closed: a count is the first thing a ranking attaches to. A\n presence indicator (\"Comments ↓\") is enough.\n- **No machine-readable comments markup on the post page.** IndieWeb practice puts\n `h-cite` comment markup inside the post's `h-entry`. Doing that turns the display\n into exactly the machine-readable responses surface #41 tells readers never to parse\n and #47 declined. The comments origin already *is* the machine-readable record:\n real items, with real `stub_of`, in a real feed and index. Individual comments\n carry RFC-1's h-card bylines, which say who wrote something, not that it\n responds.\n- **The comments section is never part of the item.** It is not in `content_html`,\n not in the feed ``, and not baked into anyone's transclusion of the\n post. Quoting a post never quotes its comments.\n\n## 9. Wire impact: none\n\nNothing new appears anywhere a reader sees. The design uses only:\n- `stub_of` (§10.6);\n- `author` with RFC-1's conventional members (§5.5);\n- partial transclusion (§10.1);\n- withdrawal (§9);\n- verified mentions (§15);\n- curation display (§13.5);\n- mount independence for the comments origin (#14);\n- exact verification between sibling origins (#61).\n\nNo field, no relation, no feed element, no manifest key. A reader that knows\nnothing about comments sees a blyg (the comments origin) full of short stubs with\ndifferent bylines, which is a correct reading of it.\n\n**The dependency on RFC-1 is real but soft.** Kind 2 works with today's `{name, url}`\nbylines. RFC-1 supplies the address book, the `bound` provenance that sign-in\nproduces, `ids` for recognising commenters across origins, and the h-card byline.\nA client could ship kind 1 and kind 3 before RFC-1 is settled. Kind 2 is where\nidentity matters, and that is why the RFCs are ordered this way.\n\n## 10. Rejected designs\n\nRecorded because each will be re-proposed.\n\n1. **A reply primitive or an `in_reply_to` field.** `stub_of` already is\n \"this answers that\", verified. A second field would be a reply primitive (§16.8).\n2. **A `comment` kind.** Kinds describe what an item is (§5.3), and a comment is a\n short stub. A kind would ask readers to treat it differently, which is a version\n change by #43, for a distinction length already makes in presentation.\n3. **Comments embedded in the post's item document**, or carried in its\n `content_html`. That would put other people's words into this origin's item\n under this origin's `content_hash`, which re-emits them (§13.5) and lets\n stubbers write on the target's page (§15.5).\n4. **A responses or comments list in the manifest or as a file.** That is #47's\n closed surface, and the first place a count would attach.\n5. **House comments on the main origin by default** (option S). It is conformant,\n but it floods the house's feed (section 4). Clients may offer it for low-volume\n blygs, and should not default to it.\n6. **Publishing anonymous comments without vetting.** The result would be a pipe\n (#36) feeding permanent endcaps into every subscriber's archive.\n7. **Pseudonyms derived from IP or email hashes.** They can be reversed (section 7.2).\n8. **Off-wire comments** — an ordinary comment database rendered on the page and\n never published. This is not rejected: it is conformant, since the protocol\n governs only the page's protocol surface (#3) and says nothing about chrome. It\n is not recommended, because the comments then cannot be cited, quoted, forked or\n subscribed to, and they disappear with the client. The point of putting comments\n on the wire is that they become part of the medium. A client that wants Disqus\n can have Disqus.\n\n## 11. Rulings (Fable 5.1, session 40, 2026-10-07)\n\nThe draft closed with seven questions. The rulings follow with the principle each\nrests on; where one differs from the draft's recommendation, it says so.\n\n**1. Fit with §16.8 and §10.6.** Yes, on the wire: the design adds no field, no\nrelation and no feed element, and a display tree rebuilt from `stub_of` is §10.6's\nown nesting, since a stub of a stub is a thread transcluding a thread. The character\nrisk the draft names is real and is answered by framing, not by machinery: the\nheader now says that the medium's first answer is to respond from your own blyg,\nthat hosted comments are an on-ramp whose accountability the house takes on, and\nthat the reference client's responses list stays a citation trail. Section 2's\nsentence, the owner's curated display of published responses, is the whole of\nwhat a comments section is, and the RFC must never describe a comment as a reply.\n\n**2. Displayed text against §15.4 step 5.** A bounded cache is fetching on display.\nThe rule exists so that a receiver never becomes a store of other people's words\nthat outlives their withdrawal, and §13.5 names verified mentions as displayable\nunder curation. The test a client must pass: if the stub's origin withdraws and\nthe receiver never fetches again, the text must stop showing. So the cache has a\nbounded lifetime after which display requires revalidation, `gone` and an endcap\npurge it, and a durable copy exists only by the origin's pin (§13.4). This is only\na kind 1 question; for kinds 2 and 3 the house is the publisher of the comment\nand holds it as its own item.\n\n**3. Edits are not signalled.** (a) and (b), no spec change. The house controls\nthe sender for kinds 2 and 3, so its comments origin re-sends a stub's mention when\nthe comment is edited; §15.2 already permits it. For kind 1 the receiver refreshes\non a schedule and accepts the staleness window. (c), a spec SHOULD to re-send on\nevery stub edit, is rejected: it would make every edit of a stub notify its target,\nwhich is the noise §15.2 chose to permit and not require, and it is sender\nbehaviour the spec would be changing for a presentation feature.\n\n**4. Steering clients toward a sibling origin.** Confirmed, for the reason the\ndraft gives: it is the only shape that keeps the house's own feed its own writing\nwithout new wire vocabulary, and it reduces three kinds to one renderer because\n#61 makes the two origins verify each other exactly as strangers would. It is not\n`tn-3` section 6's pipe: every item on the comments origin is a person's words,\npublished or approved by the house, which withdraws any of them. Two\nrequirements are added to section 4: the comments origin imports the main origin\nso quotes resolve, and it runs its own Webmention endpoint for replies.\n\n**5. Counts and comments markup.** Confirmed: no counts anywhere, no `h-cite` or\nother machine-readable responses markup on the post page. #12 and #13 refuse\nmetrics, #47 kept the responses surface closed because a count is the first thing\na ranking attaches to, and #41 tells readers never to parse one. The comments\norigin's feed and index are the machine-readable record, as the draft says. The\nh-card bylines inside comments say who wrote them and nothing more.\n\n**6. Anonymous bylines.** Consistent with §5.5 and #38. `author` is the origin's\nunverified assertion, byte-equal values group only within one origin and only\nfor display, and the origin is the accountable party. The three conditions in\nsection 7 are what make it so and are kept as written: mandatory pre-moderation,\na suffix that cannot be reversed to a person, and no `url` or `ids`. The\nwithdrawal link must say what withdrawal is: permanent, and visible as an endcap.\n\n**7. Classifying by length.** On the right side of §10.6 rule 2. The marker alone\ndecides that an item is a response; length decides how much of it is shown, which\nis presentation. Measuring the stubber's own words by leaving out the baked\n`blyg-transclusion` of the target reads a wire token for the purpose it exists\nfor, and is the same reading §5.6 rule 6 and this RFC's section 5.3 already make.\n\n**What happens next.** Published for comment on `blyg.blygger.org` under #66 on\n2026-10-07, after RFC-1; the period closes 2026-11-04. The reference client builds\nnothing from this RFC. A client that builds it is the gate for this RFC to\nbecome a technical note: one client hosts comments under this shape, and a\nsecond displays them as kind 1 responses. The decision list records these\nrulings beside RFC-1's (#67), with this section as the reasoning.\n\n\n\n*Source: [`docs/rfcs/rfc-2-comments-sections.md`](https://github.com/blygger/blygger-spec/blob/main/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.*\n\n","content_html":"

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

\n

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

\n

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

\n

1. The question

\n

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

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

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

\n

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

\n

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

\n

The whole recommendation rests on one idea:

\n
\n

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

\n
\n

Everything the design needs is already built:

\n\n

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

\n

3. One display path for all three kinds

\n

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

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
KindWho publishes the commentAt which originHow the original's page learns of it
1. Response from a blygthe respondertheir owna verified stub mention (§15.4)
2. Signed-in commenterthe house, under the commenter's bylinethe house's comments origin (section 4)a verified stub mention, same as kind 1
3. Anonymous, vettedthe house, under an anon bylinethe comments originsame as kind 1
\n

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

\n

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

\n

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

\n

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

\n

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

\n

Why C:

\n\n

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

\n

5. Kind 1 — responses from other blygs as comments

\n

5.1 What counts

\n\n

5.2 Showing the text, and keeping it honest

\n

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

\n\n

5.3 Strip the quote of this item

\n

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

\n

5.4 Moderation

\n

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

\n\n

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

\n

5.5 Depth

\n

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

\n

6. Kind 2 — signed-in commenters

\n

6.1 Signing in

\n

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

\n\n

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

\n\n

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

\n\n

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

\n

6.2 What a comment is on the wire

\n

A comment is a thread on the comments origin:

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

6.3 Limits a client should set

\n\n

6.4 Commenters who have their own blyg

\n

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

\n

6.5 Portability

\n

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

\n

7. Kind 3 — anonymous comments, vetted

\n

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

\n

7.1 Flow

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

7.2 The byline

\n\n

7.3 Data the house keeps

\n

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

\n

8. Presentation rules common to all three

\n\n

9. Wire impact: none

\n

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

\n\n

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

\n

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

\n

10. Rejected designs

\n

Recorded because each will be re-proposed.

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

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n
\n

\nSource: 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.\n

\n","content_hash":"sha256:3310cebed078157952b0d3e073105fe306cf618684d0ab05f31d9f59f94b56cc","transclusions":[],"generated":[{"sources":[],"model":"claude-opus-5-5+claude-fable-5-1"},{"sources":[],"model":"claude-opus-5-5"}]}