| Filename | Latest commit message | Latest commit date |
|---|---|---|
f37587fb7e- Fixed Interface: a `$draft` revision MUST NOT move a slug, so the published entry keeps serving under it - Improved Interface: the slug index is written after the entry is acknowledged, by an atomic compare-and-set; a losing claim is refused - Added Interface: deleting a channel MUST drop its slug entries, since a recreated channel reuses ids |
||
| rfcs | ||
| schemas | ||
| 0000-template.md | ||
| README.md | ||
noolog RFCs
Standards for what a noolog channel carries beyond JMAP — the vendor
extensions a record may hang off Email, spelled out so that a second server
can carry the same records and a client can read them from either.
Why a separate repository
A channel record is a subset of a JMAP Email (RFC 8621). JMAP is the
standard; this repository holds what noolog adds to it, under the extension
mechanism JMAP provides (RFC 8620 §1.8): every addition is named by a
capability URL on a domain we own, and the properties it adds are ours to
spell. Keeping the additions here, apart from any one implementation, is what
makes them a standard rather than a server's habit.
RFCs
| Number | Title | Status |
|---|---|---|
| 0001 | Blog entry — the noolog:blog property |
Accepted |
Schemas
Machine-readable companions to the RFCs, in JSON Schema (draft 2020-12):
schemas/blog-entry.schema.json— RFC 0001
An RFC is normative; its schema is a convenience and is corrected to match the RFC when they disagree.
Writing one
Copy 0000-template.md to rfcs/NNNN-short-name.md,
taking the next free number. An RFC moves through Draft → Accepted →
Superseded; a change to an accepted RFC that would break an existing record
is a new RFC that supersedes it, not an edit.