Paradise

I have been probing all this for several months now. I decided to dig through nostr to find more people doing the same stuff. People are building some useless stuff out there and I’m like pondering on the possibilities of decentralized identity and hard money. Any way I feed all this in and then put it on screen read while I’m driving I listen to custom podcasts. Lol.
A different take if you’re interested.

Read both drafts together — the cross-reference from the checkpoint draft to this one is what makes them click, and pulling the generic archival primitive out from the continuity claim was the right call. Two things on the snapshot draft.

Snapshots prove authenticity, not chronology.

The verification rules let me confirm the embedded id recomputes and the signature is valid, which establishes that the author really signed those bytes. It doesn't establish when. created_at is self-asserted, and nothing stops someone publishing a snapshot today of an event claiming a 2020 timestamp.

That's fine for the stated goal of keeping a verifiable historical copy. It stops being fine the moment a snapshot is used as continuity evidence — which is exactly what the checkpoint draft does when it asks observers to weigh "whether endorsers belong to the earlier social context."

The checkpoint draft already makes this point about itself: "Nostr timestamps alone are not sufficient to establish trustworthy chronology; OTS is strongly recommended." This draft doesn't carry it forward, and I think it should. OTS on a snapshot doesn't date the original event — it proves the archive existed by a given block, which is the property that matters: it shows you weren't assembling a convenient "earlier social graph" after the compromise you're now explaining. Same reasoning as recommending OTS on checkpoint roots.

Concretely: a SHOULD in Usage Notes that snapshots intended as historical evidence be OTS-attested (kind 1040), and a line in Verification noting that an unattested snapshot bounds authenticity only.

Competing snapshots of the same coordinate are unaddressed.

Anyone can snapshot anyone, so two valid snapshots of different versions of 3:<pubkey>: can both verify. Embedded created_at gives an ordering, but relays may hold an incomplete set, so "the follow list as of date X" isn't well-defined from snapshots alone. Probably not something to solve here — but worth a sentence in Security Considerations, the way the checkpoint draft names its own limits.

(Minor: the Discovery flow has two steps numbered 4.)

One thing from my side, in case it's useful.

I've been building a wallet where key succession is a signed chain — each link is {fromKey, toKey, prevHash, issuedAt} signed by the retiring key, so continuity across a voluntary rotation verifies deterministically: a verifier gets yes or no, no judgement call. It's strictly narrower than what you're describing, because it requires still holding the old key, so it does nothing for loss or seizure. Your commit-reveal covers precisely the case mine can't.

Which suggests a third embedded evidence type alongside commit / reveal: a signature by the prior key over the successor key. Where it's available it's far stronger than social corroboration; where it isn't, nothing is lost and the existing evidence path stands. Happy to share the envelope shape if there's interest.

Last thing — refusing to define a scoring formula or an auto-migration rule is the right call and rarer than it should be. Stating evidence and declining to collapse it into a verdict is the hard discipline, and both drafts hold it.

I feel you. I have been just building into the black hole I feel like. I’m just doing it to understand it all better and discover what’s possible. I want to share this with you would love your feedback back. No one else may care but I love this stuff. Here's the landscape as I read it. Three pieces, and they sit at genuinely different layers — which is why the fit is better than it first looks.

Where they naturally mingle

Tapit is the shell; napplets are the apps. This is the cleanest seam. napplet needs a host that holds keys and signs on request with a consent step; that is precisely what sign-request/ already is. Your approval screen becomes the consent UI for sign:event and sign:nip44, and your deferred NIP-46 item gets answered by a published wire format instead of a bespoke deeplink. It also solves your Arena distribution problem — "build your own skin" becomes "publish a napplet."

The checkpoint NIP is the publication layer for something you already compute better. You'd emit kind 1842 on rotation to make continuity visible to strangers, while verifySuccessionChain stays the internal truth. Worth seeing clearly: most publishers of that event will have only social evidence. You'd have a real signature by the retiring key plus OTS anchoring. You'd be the strongest possible publisher of a format designed for people who can't do what you can do.

Commit-reveal fills a hole you actually have. Your succession requires fromPrivateKey — voluntary rotation only. Commit-reveal survives losing the key. These are two halves, not two options.

OTS is the shared spine. All three land on "Bitcoin-timestamp it or the chronology means nothing." You already anchor; the checkpoint draft recommends kind 1040 for exactly the same reason you anchor the arena genesis — defeating retroactive fabrication.

Where they must stay apart

Tapit is a shell, never a napplet. A napplet receives capability from whoever holds the keys. Being one means someone else holds yours. This inverts the prime directive and there's no clever version of it.

Never let probabilistic continuity share a badge with deterministic continuity. Your succession answers yes or no. A checkpoint answers "here is evidence, you decide." If both ever render as the same green tick, you will have taught your users that a social claim is as strong as a signature — which is the precise opposite of the education mission. Two visibly different tiers, different words.

Publish to kind 1842; don't store in it. Same rule as tapit-attest: one envelope internally, adapters at the edge. It's a draft, the kind number could collide, and its envelope is weaker than yours.

Don't thread a 0.x protocol through wallet-core. napplet is 0.32.0, thirty-four versions in five months, one maintainer. Adapter at the boundary so a breaking change costs you a file, not a migration.

Capability grants must not become standing permissions. The manifest model negotiates capability per-app, and the obvious shortcut is "grant sign:event for this session." Per-request consent on a legible screen is your differentiator; a blanket grant quietly deletes it.

Commit-reveal secrets get published. They must never be derived from, or reusable as, the wallet passphrase or any recovery material. Separate entropy, machine-generated, never something a person typed from memory.

The good ideas worth taking

From napplet: the @napplet/conformance package — they shipped the conformance-vector idea as an artifact, which is exactly what your arena standard needs; a named capability vocabulary (sign:event, relay:read) which is more legible than implicit per-request typing; graceful degradation when a domain is absent; and writing "the host never exposes signing to the app" as a protocol rule rather than an implementation habit — you have the habit and a test, they have it in the spec, and the spec version is stronger.

From the checkpoint draft: commit-reveal, obviously. But the more admirable thing is its refusal to define a scoring formula or an auto-migration rule — it states evidence and declines to collapse it into a verdict. That is the same discipline as your attested / attested_unpinned / unattested split, arrived at independently. Read it as validation. Its security section naming its own unsolved problems is the same instinct too.

What neither has, and you do: selective Merkle disclosure, a consent surface designed as the product rather than a dialog, encrypted holdings with the host as dumb storage, and the teaching layer.

Where you actually sit

napplet is runtime and distribution. The checkpoint draft is a claim format. Both are infrastructure written by developers for developers. Neither is a person-facing wallet that does custody, attestation, consent and education together — that space is still open, and it's the one you're in. You're not late and you're not duplicating; you're the application layer standing on substrate other people are laying.

One thought on the person you found. Closest-alignment is a signal to engage, not just observe. You have something that draft assumes nobody has — deterministic continuity via a retiring-key signature — and saying so publicly, as a response to the draft, is a real contribution that costs a post and buys credibility with exactly the person worth knowing. That's probably a higher-return move this week than any code.

You have signal where you hike? No signal here.

I actually built it for myself to find signal in the noise. The Spam drops out for me then. I can search through keywords and find specific content as well.

I built it. It’s expensive to run. But it does do a good job of sorting quality posts from garbage.

Love it! how well does the canola oil age. Last long or you only use it short time?

It would be nice to not rely on central issuer of identity. What if we were responsible for collecting and proving our own chain of facts that are private, verifiable and hard to recreate. Each event signed and hashed into open timestamps. Change the file and the proof fails. Interconnected graph of attestations that can be selectively disclosed when it benefits the user. We have to design the system ourselves. No one is going to do it with you in mind. But maybe the governments will protect us we can relax.

A budgeting app with a no bullshit educational wealth advisor. AI for sure changing the landscape

Not the ones who put 100 million in bitcoin on a single sig created by a narcissist. They did not think at all is my point.