**Local Version History Comes to Continuum**
Andrew G. Stanton – July 7, 2026
One of the more interesting things about Nostr is that not all events behave the same way.
- Profiles (kind:0) are replaceable by design.
- Articles (kind:30023) are parameterized replaceable events identified by a d tag.
Traditional notes (kind:1) are different. They aren't replaceable at all.
Every edit is simply another event.
Continuum has started taking advantage of those differences.
Today I added local version history for:
Profiles
Articles
Continuum-authored notes
For profiles and articles, the relationship already exists within the protocol itself.
For notes, Continuum uses a local convention: edited notes preserve a shared d tag so they can be grouped together as revisions of the same piece of writing.
Other Nostr clients simply see independent kind:1 notes.
Continuum understands the relationship between them.
Every authored revision is preserved locally before the current state moves forward.
For notes and articles, previous revisions are available directly from the viewer through a collapsible Versions section.
For profiles, previous revisions can now be loaded directly into the dashboard itself, allowing older profile states to be viewed without leaving the page.
Nothing is overwritten.
Nothing is lost.
Under the hood, Continuum now maintains three distinct layers of memory:
nostr_events — current local state
nostr_events_history — local revision history
Git archives — long-term preservation and recovery
Most Nostr clients focus on the latest event.
Continuum is beginning to preserve the path that led there.
#Continuum #Nostr #LocalFirst #DigitalPreservation #RelationalMemory
Akamaister
npub19w…dguvd
2026-07-08 06:47:15 CEST
Author Public Key
npub19wvckp8z58lxs4djuz43pwujka6tthaq77yjd3axttsgppnj0ersgdguvdSeen on
wss://nos.lolPublished at
2026-07-08 06:47:15 CESTEvent JSON
{
"id": "d51d0d61a1e7431249834424b766659a7ea84b7b4b27c754e155943b31728a75",
"pubkey": "2b998b04e2a1fe6855b2e0ab10bb92b774b5dfa0f78926c7a65ae08086727e47",
"created_at": 1783486035,
"kind": 1,
"tags": [
[
"d",
"note-1783486035"
],
[
"published_at",
"1783486035"
],
[
"client",
"Continuum-Pro-localhost"
],
[
"t",
"continuum"
],
[
"t",
"nostr"
],
[
"t",
"localfirst"
],
[
"t",
"digitalpreservation"
],
[
"t",
"relationalmemory"
]
],
"content": "**Local Version History Comes to Continuum**\n\nAndrew G. Stanton – July 7, 2026\n\nOne of the more interesting things about Nostr is that not all events behave the same way.\n\n- Profiles (kind:0) are replaceable by design.\n\n- Articles (kind:30023) are parameterized replaceable events identified by a d tag.\n\nTraditional notes (kind:1) are different. They aren't replaceable at all.\n\nEvery edit is simply another event.\n\nContinuum has started taking advantage of those differences.\n\nToday I added local version history for:\n\nProfiles\nArticles\nContinuum-authored notes\n\nFor profiles and articles, the relationship already exists within the protocol itself.\n\nFor notes, Continuum uses a local convention: edited notes preserve a shared d tag so they can be grouped together as revisions of the same piece of writing.\n\nOther Nostr clients simply see independent kind:1 notes.\n\nContinuum understands the relationship between them.\n\nEvery authored revision is preserved locally before the current state moves forward.\n\nFor notes and articles, previous revisions are available directly from the viewer through a collapsible Versions section.\n\nFor profiles, previous revisions can now be loaded directly into the dashboard itself, allowing older profile states to be viewed without leaving the page.\n\nNothing is overwritten.\n\nNothing is lost.\n\nUnder the hood, Continuum now maintains three distinct layers of memory:\n\nnostr_events — current local state\nnostr_events_history — local revision history\nGit archives — long-term preservation and recovery\n\nMost Nostr clients focus on the latest event.\n\nContinuum is beginning to preserve the path that led there.\n\n#Continuum #Nostr #LocalFirst #DigitalPreservation #RelationalMemory",
"sig": "32c351a13ce4e7914fe7c724006f4250f8635b7eb83d05099a282f37c978b243d810ea8311fe705a59f4d0d6c50fd145ad2a154b1ca963454368414080db89ab"
}