Don't trust, verify.
Nothing here is vouched for — not by this page, and not by the marker on a card. Anyone can publish with the marker. Judge a card by what it carries: a real date, the collection it claims, a source you can check, and a key you can look up — click a publisher's name for their history on njump.me. This site has no accounts, no moderators, and no server: it renders whatever the relays hold, and the relays hold whatever people sign.
What nostr is
nostr is a way to publish that doesn't run through a company. There is no account: you hold a keypair. The secret half signs what you write, the public half is your name, and anyone can check that the two match. Nobody issues the key and nobody can revoke it — which also means nobody can hand it back to you if you lose it.
Signed messages get pushed to relays — small independent servers that store them and hand them back to whoever asks. A relay is a copy, not a home. If one drops what you wrote or refuses to carry it, the same signed message is still sitting on the others, and a reader can ask all of them at once. That is the whole protocol: signed messages, and servers that pass them along.
So this page has no accounts, no moderators, and no database. It opens a connection to a handful of public relays, asks for the cards, and draws what comes back — the counter at the top of the page is those connections answering. Every card was signed by whoever published it, not by whoever runs this site. The record lives out on the relays; if this page disappeared tomorrow, another one could read the same cards.
Longer introductions: nostr.how for the plain-language version, njump.me to look up any key or event, and the NIPs for the protocol itself.
Add to the record
1 · Get a nostr identity
A keypair is the whole signup: no email, no approval. Make one at
nstart.me.
Guard the secret key (nsec): it can't be reset, and it is
the identity.
This page reads it through a browser signer extension (NIP-07). Without one, this page is read-only.
2 · Add to it
Signed with your key: a stance or a margin note on any card, and cards of your own. add.html is the long form — revisions of another author's card, and its own sign-in options.
Dev · publish a card, build a reader
Publish a card
An entry is a kind 30828 addressable event (NIP-01) that labels itself as belonging here (NIP-32). 30828 is this convention's own kind — the cards rode NIP-54's wiki kind 30818 until 2026-07-29, when nostr's maintainer answered that a new number was the right shape (nips#2426). The tags did not change. A wiki client can't publish one: wikifreedia.xyz and wikistr.com write 30818s, which this page does not read at all — use add.html, or anything else that lets you set the kind and the tags yourself. A card this page can place on a rail carries:
kind: 30828 tags: d my-entry-slug (identity — one entry, editable by you; no date in it) title Short entry name (no leading year — the rail already shows the date) event_date 2026-07-20 (YYYY-MM-DD — where it sits on the rail) t wikitimechain (the discovery marker — every card carries it) L timeline.collection l <collection-slug> timeline.collection (which timeline) L timeline.date l 2026 timeline.date l 2026-07 timeline.date content: One factual sentence about what happened. Source: [label](https://link-to-primary-source)
Keep the content to verifiable facts with a primary source. The timeline shows
who published every card — your entry stands on your signature. There is no
registration step for a timeline: a collection is its slug, so publishing
the first card carrying a new timeline.collection value is all it
takes to start one, and it appears here beside the rest.
The label namespaces are timeline.*. The t marker is not
part of that naming — it names this timeline, not a version, and every card carries
it.
Build your own reader
This page is one client, not the record. One request boots another:
{"kinds":[30828],"#t":["wikitimechain"],"limit":500} — group what
comes back by its collection label, sort by event_date, draw. Exact
membership for one timeline is {"kinds":[30828],"#l":["<slug>"]}.
No manifest to fetch, no index to register with. Keep the newest event per
pubkey:d — that pair is a card's identity, and an author republishing one
replaces their own. The full tag scheme is in
NIP-DRAFT.md.
Show a document changing
If your timeline follows a document through versions, a card can carry the change
instead of describing it. Tag the version you revised with the fork
marker — ["a","30828:<pubkey>:<their-d>","","fork"], the empty
third slot is structural and the marker must be the fourth element — and mark
the text in djot: {-removed-}, {+added+}. A mark alone on its
own line becomes a gutter row; a mark inside a sentence stays inline. Readers get a
as passed / what changed switch on any card that carries both. No extra tag,
and it works in any timeline. Keep removals in their own paragraph block —
CONVENTION.md has the reason and the
rule about not diffing more finely than a reader can follow.
Dispute a card
Disagree with an entry? Publish your own kind-30828 with the same
d tag and your correction. Nothing is overwritten — both
versions appear side by side on the rail, each signed by its author, and readers
judge for themselves. Disputes are additions, not deletions.