Unseenet Working Group                                     A. Lorensen
UN-RFC: 0035                                              October 2026
Category: Standards Track
Status: Draft
Updates: 0000, 0008, 0011, 0012, 0017, 0027, 0029, 0031

                       Unseenet: Pages and Sites

Abstract¶

This document lets a channel group be shown as a site: a small set of static pages of Markdown with images, found by a path such as index or projects/ovos, which readers browse in their client. Each page is a signed article; a new version replaces the old one, and the current version of every page is part of the group's state, so nodes keep it however rarely the site changes. An identity may have a personal site in the key-bound group site@<fingerprint>. Pages use the safe Markdown of UN-RFC 0031 and the attachments of UN-RFC 0027: no HTML, no scripts and nothing fetched from outside the network. Sites are small by design, and node operators choose whether they carry them.

1. Motivation¶

Before the web, a BBS had bulletins, a Unix account had a .plan, Usenet groups had FAQs posted again and again, and Gopher had menus of plain documents. Today Gemini keeps that idea alive. People still want a place to say who they are, describe a project or keep a guide that is not a post in a stream (unseenet #212).

Anyone can already put a static web site on an onion service, but then they must keep a server running, and the site is gone when it is off. Unseenet can do three things such a site cannot:

The pages are replicated. They stay readable when the author's machine is off, on every node that carries the group.
The pages are signed. Nobody but the owner and the people the owner lists can change them, and every reader can check it.
The pages are found from a key or a name. A reader who knows andreas@lorensen (UN-RFC 0019) finds the site with no directory.

Pages are not the web. This document deliberately leaves out HTML, scripts, forms, styles, remote content and anything else that makes a page a program. A site is a handful of documents to read.

2. Terms¶

Site: a channel group with "view": "pages" (section 3).
Path: the name of a page within a site (section 4.1).
Page article: an article with a Page header (section 4.2).
Version: the value of a page article's Page-Version header.
Current version: for one path, the page article that counts (section 5.1). It is either a page or a removal.
Page in force: a path whose current version is a page and that is among the site's max_pages (section 5.2).
Home page: the page shown when a reader opens the site, by default the path index.
Personal site: the key-bound group site@<fp> (section 7).

3. The Pages View¶

UN-RFC 0008 section 3.1 is extended: view may be pages.

A group may have "view": "pages" only if its type is channel (UN-RFC 0004 section 2), and only if it is not closed. A node MUST reject a manifest with "view": "pages" for any other group. Who may write pages is who may post in a channel: the owner, moderators and listed posters.

A site's manifest MAY contain:

Field	Type	Default	Meaning
`max_pages`	integer	`32`	How many pages may be in force (1-128)
`home`	string	`"index"`	The path of the home page (section 4.1)

A value outside these ranges makes the manifest invalid (UN-RFC 0004 section 4, step 3).

Articles in a site that are not page articles are ordinary articles. Clients showing the pages view MUST NOT show them as pages; they MAY offer them in the threads view as usual. An owner who wants comments on a site uses UN-RFC 0030 as in any channel.

4. Page Articles¶

4.1 Paths¶

A path is 1 to 8 segments separated by /. A segment is 1 to 64 characters of a-z, 0-9, -, _ and ., and is not . or ... Paths are compared as octets; there is no case folding and no normalisation. Examples: index, about, projects/ovos, guides/getting-started.

4.2 Headers and Body¶

A page article is an article (UN-RFC 0002) in a site with:

Page: <path>;
Page-Version: <n>, a decimal integer from 1 to 2^53 - 1;
Subject: the page's title, at most 128 characters;
Content-Type: text/markdown; charset=utf-8; variant=unseenet (UN-RFC 0031 section 2), or text/plain;
no References: a page is not a reply, and a reply to a page is an ordinary article.

Its body is at most 65 536 octets. Markdown in a page uses the subset for posts (UN-RFC 0031 section 3.2), with the links of section 8, and images as blobs (UN-RFC 0027, UN-RFC 0031 section 3.5). The Blobs header lists them as for any article.

A removal is a page article with the header Page-Removed: yes, an empty body and no Blobs. It removes the path from the site.

4.3 Validity¶

A page article is valid when:

it is in a group whose current manifest has "view": "pages";
its author is the owner, a moderator or a listed poster in that manifest;
its path, version, subject and size follow sections 4.1 and 4.2;
it is not a cancel or other control article.

A node MUST reject a page article that is not valid. A page article whose author later loses their role stays stored, but no longer counts (section 5.1).

5. Which Pages Count¶

5.1 Current Versions¶

For each path, among the valid page articles whose author is owner, moderator or poster in the current manifest, and that have not been withdrawn with a valid cancel, the current version is the one with the highest Page-Version; of equal versions the one with the latest Date; of equal dates the one whose Message-ID is greatest in code point order.

A writing client therefore gives a new version the highest version it knows for the path plus one (section 9.2).

5.2 Pages in Force¶

Of the paths whose current version is a page, not a removal, the max_pages whose current versions have the latest Date (same order as above) are in force. The home page is in force if it exists, and then counts as one of them.

Every node and client that holds the same articles comes to the same result, as with pins (UN-RFC 0033 section 4.2).

6. Nodes¶

6.1 Group State¶

UN-RFC 0017 section 2 is extended. The state of a site also includes:

the current version of every page in force;
the current version of every path whose current version is a removal, as long as that removal is inside the group's window.

A node MUST NOT expire state articles. When a page article leaves the state, because a newer version replaced it, its path was removed or pushed out of max_pages, or its author lost their role, it expires normally (UN-RFC 0012) and may disappear at once if it is older than the window. Older versions are therefore not kept, and a site does not grow with each edit.

6.2 Accepting Old Pages¶

UN-RFC 0012 section 3 is amended: a node MUST NOT reject a page article for being older than the window if it would be the current version of a page in force. It forwards such an article to its peers as usual, so a new node receives the whole site.

6.3 NEWNEWS¶

UN-RFC 0017 section 3, step 1, is refined. A node lists a site's state in this order: manifests, pins and unpins, pinned articles, then the current versions of pages by ascending path.

6.4 Blobs¶

UN-RFC 0027 section 7.1 is amended: a node SHOULD keep a blob as long as the current version of a page in force references it, also beyond its own blob retention.

The blobs referenced by all pages in force of one site MUST NOT total more than 8 MiB. A node MUST reject a page article whose blobs would take the site above that, counted against the pages in force it holds when the article arrives. A node MAY set a lower limit, and MAY refuse blobs as UN-RFC 0027 section 7.3 allows; the page stays and its images are shown by their alt text.

6.5 Carrying Sites¶

Sites are optional for nodes, like pictures (UN-RFC 0022 section 10). A node operator MAY:

carry no sites at all;
carry personal sites but not others, or the reverse;
carry the text of sites but not their blobs (UN-RFC 0027 section 8.2).

A node that does not carry a site answers for it as for any group it does not carry. A node says whether it carries sites in its node information (UN-RFC 0011 section 4), in the policy field

Field	Type	Meaning
`sites`	string	`accept`: carries sites; `refuse`: does not

Sites are content that stays, and no node should keep content of that kind it has not chosen to. An implementation MUST therefore ship with sites set to refuse, as for avatars (UN-RFC 0022 section 10); the operator turns it on. A node that does not state sites is taken to refuse them. A node MAY refuse or remove the site of an identity it blocks (UN-RFC 0018 section 8.2).

6.6 Postage¶

A page article pays the postage of an article of its size (UN-RFC 0006), with the extra bits for blobs of UN-RFC 0027 section 4.5. Nothing else is charged: the limits of sections 3 and 6.4 keep a site small.

7. Personal Sites¶

7.1 The Site Group¶

An identity's personal site is the group it owns named site:

site@<fingerprint of the identity's key>

Like the profile (UN-RFC 0022 section 5.1) and the feed (UN-RFC 0034 section 5.1), its Group ID follows from the key, so anyone who knows a key, or a name that leads to it (UN-RFC 0019), can find the site.

Its manifest (UN-RFC 0004 section 3) has:

name: site;
type: channel. The owner MAY list posters, for example a key of their own on another device; they SHOULD NOT list other people;
view: pages;
expires: as for every key-bound group (section 7.3).

A node MUST reject a manifest for a group named site whose type is not channel or whose view is not pages.

7.2 Starting and Ending a Site¶

A personal site is public, and it ties everything in it to the identity. A client therefore:

MUST NOT create a personal site without the user asking for it;
MUST tell the user, as for a public profile (UN-RFC 0022 section 5.3), that what is published can be kept by others and cannot be recalled, also after a page is changed or removed.

The owner ends a site by removing the group (UN-RFC 0013) or by letting it expire.

7.3 Lifetime¶

Personal sites are key-bound groups (UN-RFC 0029). The owner's client renews site@<fp> together with the identity's other key-bound groups, and the site of a key that nobody uses any more disappears with them.

7.4 Other Sites¶

Any open channel can be a site: a project's (for example unseenet.site), an association's under a country hierarchy, or a guide that belongs to a group of its own. Such sites are ordinary groups; they follow their hierarchy's rules (UN-RFC 0018) and expire, if at all, as their manifests say.

8. Links¶

UN-RFC 0031 section 3.4 is extended for page articles.

Within the site: a link whose destination has no scheme is a path in the same site, relative to the directory of the current page as in a file system: on projects/ovos, skills is projects/skills and /about is about. .. goes one segment up and never above the site. An optional #fragment names a heading in the target page, as the client derives anchors from headings; a client that cannot show it opens the top of the page.
To a personal site: unseenet:<fingerprint>/<path> opens that page on the identity's personal site; unseenet:<fingerprint> alone keeps its meaning from UN-RFC 0022 (the identity).
To another site: unseenet:join?g=<group-id>&p=<path> extends the join link of UN-RFC 0004 with the path to open.

A link that leads to a page that is not in force, or a site the node does not carry, opens nothing and is shown as unavailable; it is not an error. Where a name certificate is valid for the fingerprint (UN-RFC 0019), clients SHOULD show the name rather than the fingerprint, but MUST let the reader see the fingerprint.

9. Clients¶

9.1 Reading¶

A client shows a site as its home page, with the title of the site (its manifest's title), the owner's name or fingerprint, and a way to reach every page in force: a list or a tree built from the paths, ordered by path. It MUST NOT show pages that are not in force.
Pages are rendered as posts are (UN-RFC 0031). A terminal client MAY show the Markdown source; it SHOULD then list the page's links, numbered, so they can be followed from the keyboard.
Following links within the network keeps a history the reader can go back and forward in.
Nothing in a page makes a client fetch anything from outside the network (UN-RFC 0031 section 3.1). Links to the web follow UN-RFC 0031 section 3.4 and the client's own rules; the bootable client never opens them.
A client SHOULD remember the highest version it has seen of each page of a site it reads. If a node then offers it a lower one, the client SHOULD say that a newer version exists but is not available, rather than show the older one as current (section 13).
Wherever a client shows an identity, it SHOULD offer the identity's personal site when the site group is current, as for feeds (UN-RFC 0034 section 5.4).

9.2 Writing¶

The client keeps the Markdown source the author wrote and offers a preview rendered as readers will see it.
A new version gets the highest Page-Version the client knows for the path plus one. Before publishing, the client SHOULD fetch the site's current state, so that an edit from another device is not silently overtaken.
The client SHOULD warn before a change would push a page out of max_pages, or take the site's blobs above the limit of section 6.4.
Images are prepared as UN-RFC 0027 section 9.1 requires.

10. Gateways¶

Gateways (UN-RFC 0023) do not carry page articles in this document. Mappings to other networks, such as Nostr long-form articles or Gemini capsules, need a document of their own.

11. Changes to Other Documents¶

UN-RFC 0008 section 3.1: view gains the value pages, for open channel groups only (section 3).
UN-RFC 0012 section 3: current versions of pages in force are accepted even when older than the window (section 6.2).
UN-RFC 0017 section 2 and section 3: a site's state includes its current pages (section 6.1), listed after pins (section 6.3).
UN-RFC 0027 section 7.1: blobs of pages in force are kept, up to 8 MiB per site (section 6.4).
UN-RFC 0011 section 4: the policy field sites (section 6.5).
UN-RFC 0029 section 2: the table of key-bound groups gains site@<fp>, personal site, this document section 7.1.
UN-RFC 0031 section 3.4: links within a site and to pages (section 8).
UN-RFC 0000 section 6: 0035 is added to the index.

12. Rationale¶

Why not HTML? HTML brings scripts, styles, forms, remote fonts and images, and all the ways a page can track or fool its reader. The Markdown of UN-RFC 0031 is already safe in every client and reads well as plain text in a terminal. Sites lose layout and gain the certainty that reading a page cannot hurt the reader.
Why channels only? A page is something its owner stands behind. Pages anybody may change are a wiki, which needs rules for conflicts, vandalism and history that this document does not attempt.
Why not closed groups? In a closed group nodes cannot read the Page header, so they cannot tell the current version from an old one. Members-only sites need the carried copies of UN-RFC 0033 section 6 or something like them, and a document of their own.
Why keep only the current version? History is what makes a site grow without end. Nodes keep what is current; readers and archives (UN-RFC 0012) may keep more.
Why a version number and not only the date? Clocks differ, and a page edited on two devices must still have one clear newest version. The date only breaks ties.
Why limits this low? 32 pages and 8 MiB is plenty for a person's or a project's site, and small enough that carrying a few thousand sites costs a node little. Larger collections belong in ordinary groups with attachments, which expire.
Why a key-bound personal site? So that it can be found from a key or a name with no directory, and disappears when the key is no longer used (UN-RFC 0029), as profiles and feeds do.
Why not put pages in the profile? A profile is small, lives in a manifest and cannot have images (UN-RFC 0027 section 7.1). Keeping sites apart also lets an operator carry profiles without sites.

13. Security and Privacy Considerations¶

A personal site is public and linked to the identity. Everything in it can be kept by anybody, also after it is changed or removed. Section 7.2 makes the client say so. Users who need to keep things apart SHOULD use a separate identity for a site.
Abuse. Static content that stays is more attractive for unlawful material than a discussion. The limits of sections 3 and 6.4, the operator's freedom to carry no sites, no site images or any single blob (section 6.5, UN-RFC 0027 section 7.3), and blocks within a hierarchy (UN-RFC 0018 section 8.2) apply. A site that breaks a node's rules can be dropped as any group can.
Stale pages. A node can serve an old version of a page, or none, but cannot forge one: every version is signed. Section 9.1 has the client remember the highest version it has seen, so a node that holds back a newer version is noticed by readers who have seen it.
Impersonation. Anybody can make a site that looks like somebody else's, but not site@<fp> for a key they do not hold. Clients SHOULD show a site by its owner's name (UN-RFC 0019) or fingerprint, never by its title alone.
Deceptive links and phishing. Pages have no forms and no scripts, and links show where they go (UN-RFC 0031 section 3.4). A page can still ask a reader to do something foolish in words; clients cannot prevent that.
Reading patterns. A reader's node can see which sites are read through it, as for any group. Over Tor it does not learn by whom.
Rendering cost. The 64 KiB limit and the rendering limits of UN-RFC 0031 section 7 keep a crafted page from hanging a client.
Scale. A personal site is one more key-bound group per identity, but it exists only when its owner asks for it (section 7.2), so it does not grow with the number of identities as profiles do. The upper bound per identity is one site of at most 128 pages of 64 KiB (8 MiB of text) and 8 MiB of blobs (sections 3, 4.2 and 6.4); with the default max_pages of 32 the text is at most 2 MiB. Old versions expire (section 6.1), so editing does not make a site grow. A node carries sites only when its operator turns them on, and may carry their text without their blobs (section 6.5), so at the design targets of UN-RFC 0001 section 1.2 a node pays only for the sites it has chosen. A new node gets a site through the ordinary state transfer of UN-RFC 0017 (sections 6.2 and 6.3), with no extra round trips.