This site is being rebuilt and some pages are out of date. For current details, write to reach@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

← Back to Platform

RFC 0062open2026-10-05

An RFC tool to write, read and review in, not a page that shows a document

The RFCs product gets the working surface a team expects from GitHub review, Google Docs and Linear docs. Reading has an outline, a comfortable measure and a full-screen mode; writing has a full-screen editor; any passage can carry a comment thread, found again in later versions by its exact text or shown as outdated. Then suggested edits, review states, an AI assistant on our own models that a person always accepts, and a GitHub review agent that reads and comments and does nothing else. Phase 1 ships the reading view, the editor and comments on a selection.

Problem

The RFCs product (RFC 0035, named for customers in RFC 0054) already keeps every version, runs the checks of iohr lab check on every save, threads comments, requests and records reviews, and names the people on a document (RFC 0041). It does not feel like a tool people would choose to write in. On 2026-10-05 the owner put it plainly: it has to look like it should, not like a toy.

What is missing, measured against the tools a reviewer already uses:

  • Reading. The text sits in a card between two side columns. There is no full-screen mode and no choice of width, and the outline shows only on very wide screens.
  • Commenting. A thread can hang only on a heading. In GitHub review, Google Docs and Notion a reviewer selects the words they mean and comments on those.
  • Writing. The editor has a preview and an outline, but it cannot take the whole screen, and long documents feel cramped.
  • Help. There is no assistant for drafting a section, rewriting a passage or asking the document a question, and nothing that reviews an RFC against the code and pull requests it names.

Proposal

1. Reading view (phase 1)

  • An outline beside the text from large screens up, with the current section marked as the reader scrolls.
  • Two widths: a reading measure of about 72 characters, and wide for tables and diagrams. The choice is remembered per browser.
  • Full screen: the document alone, with the outline, on f; Esc returns.
  • The review, comments, versions and checks panels stay where they are, and collapse into a drawer in full screen.

2. Comments on a selection (phase 1)

A reader selects text in the rendered document and comments on it. The thread stores the passage the way a W3C Web Annotation TextQuoteSelector does: the exact text (1 to 1000 characters), up to 64 characters before and after it, and its offset in the rendered text of the version it was made on. anchor still names the heading the passage falls under, so every reader that knows only headings still files the thread correctly.

  • The passage is highlighted in the text; selecting a highlight opens its thread, and a thread scrolls to its passage.
  • In a later version the passage is found again by its exact text, the nearest match to its neighbours winning. When the text is gone, the thread says outdated and shows the quote, as GitHub does for a line that changed. It is never moved to a guess.
  • Replies, resolve and reopen work as they do today. Quotes are stored in labs.comments (quote_exact, quote_prefix, quote_suffix, quote_start), exported with the comment (ExportSubject) and erased with it (EraseSubject).

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

3. The editor in full screen (phase 1)

The existing editor (CodeMirror, live preview, outline, checks) can take the whole screen, with the preview beside it or hidden. Saving keeps its rule: every save names the version it was based on, and a stale save is refused, never overwrites (RFC 0035).

4. Versions and diff (phase 1 where the data allows)

Every version's full text is kept. Two versions are fetched (GetDocument with version) and compared in the browser, side by side or inline.

5. Suggested edits and review states (phase 2)

  • A reviewer can propose replacement text for a selected passage. An author accepts it, which saves a new version, or rejects it. Both are recorded on the thread.
  • A document moves through draft, in review and approved. Reviewers are requested and each answers approve, request changes or comment, as in a GitHub pull request review. The review records already exist; this makes them the document's visible state.

6. The assistant (phase 2)

The assistant drafts a section from a heading and notes, rewrites a selected passage on request, and answers questions about the document. Its rules:

  • The person is told they are working with AI, on every surface where it acts (AI Act Art. 50).
  • It runs on our self-hosted models (the llm service). RFC text is customer data. It goes to a third-party model only if the account has chosen a provider covered by a data processing agreement, and never by default.
  • Its output is a suggestion, marked AI-drafted, that a person accepts or discards. It never saves a version by itself.
  • Every call is audited by who, what and outcome, never by the text.

7. The GitHub review agent (phase 3)

An account can connect a GitHub App to review its RFCs against the code: it reads the RFC, the pull requests and files the RFC names, and posts a review as comments on the RFC and, when asked, on the pull request.

  • Least privilege: repository contents read-only, and pull request review comments. No push, merge, issue or settings permission.
  • Credentials by reference through connections (RFC 0044), never stored in a file or shown.
  • Off by default per account. Every run is audited, and its review is labelled as written by an AI agent.

Controls

  • Access is unchanged: authenticates; reads and writes follow the existing roles of RFC 0035 and RFC 0041. New routes, if any, name their JWT requirement.
  • Audit keeps who, what and outcome for every comment, suggestion, assistant call and agent run, never the text.
  • The assistant and the agent follow the AI rules above: Art. 50 disclosure, our own models by default, suggestions only, least privilege.

Alternatives considered

  • Positions only (line and column). Every edit breaks them. A text quote survives edits that leave the passage alone, and says honestly when it does not.
  • A third-party editor such as Notion or Google Docs. The text would leave our systems, and the checks, versions and reviews that make an RFC an RFC would sit outside the platform.
  • A WYSIWYG editor in place of markdown. The documents are markdown in git for teams that use iohr lab check. Live preview beside the source keeps one truth and costs less.

Status log

  • 2026-10-05: opened. Phase 1 started: comments on a selected passage (the Quote message on Comment and AddCommentRequest in both the RFCs and the labs protos, migration 20261005201119_labs_comment_quotes.sql), the reading view and the editor in full screen.
  • 2026-10-07: the reading view's layout redone after the owner's review: contents, text and the rail are one grid sized by the room it has and centred with a cap; the contents have their own column (two-line headings, the section being read marked) or a Contents menu above the text; the toolbar sits on the document. People show as names, the reader as "Name (you)" and agents as "name (agent)" with their own mark. Renderer, anchoring and data model unchanged.
  • 2026-10-07: Checked: phase 1 (#365) and the RFCs home (#487) are live; the reading view layout (#536) is merged, not rolled. Open.

This document mentions

Mentioned in

← Back to Platform