docs(ghostkey): bring the page in line with what actually shipped - #101
Merged
Conversation
Four claims on /ghostkey were describing an older state of the system. **The developer section was a version behind.** It said an app "sends a `SignMessage` request", which requires knowing a fingerprint before you can do anything. `SignWithDefault` is now the call to lead with -- no fingerprint, and it prompts and replays if the app holds no grant. `HasIdentity` is mentioned too: it answers "does this user have a Ghost Key" without prompting, which is what lets an app decide whether to offer a purchase path before putting a dialog in front of someone. **Bundled issuance was described as on the roadmap** with "the missing piece is bundled issuance". It is parked, not pending, and the page now says why rather than leaving a reader to infer it is imminent: Ghost Keys are principally a CAPTCHA replacement for one-off actions and already do that job, so per-action unlinkability is an improvement rather than a prerequisite. **ZK was described as "the direction we expect Ghost Keys to move in".** Also parked. Replaced with what is actually known, since it has been prototyped and measured: ~400-byte proofs, ~84 ms to verify in a contract, and the real obstacle being structural rather than speed -- contract state is re-validated on every load, so verification must happen at admission, which a contract cannot do alone. **Backup advice predated the vault doing anything about it.** The vault now marks an identity un-backed-up and shows a one-click download that clears only on explicit confirmation, so the page frames backing up as the point rather than an afterthought, and says plainly that some nodes reclaim idle storage. Deliberately unchanged: the two news posts, which are dated announcements rather than documentation, and the delegate diagram, whose `SignMessage` label still depicts a real request -- rewriting positioned SVG text for a nuance a diagram cannot carry is not worth the layout risk.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four claims on
/ghostkeywere describing an older state of the system. Found while sweeping for staleness after this week's delegate changes.The developer section was a version behind. It said an app "sends a
SignMessagerequest" — which requires knowing a fingerprint before you can do anything, and is the same version-behind problem the skill and the ghostkeys README had. This is the most-read of the three. Now leads withSignWithDefault(no fingerprint, prompts and replays if the app holds no grant) and mentionsHasIdentity, which answers "does this user have a Ghost Key" without prompting — the thing that lets an app decide whether to offer a purchase path before putting a dialog in front of someone.Bundled issuance was on the roadmap. The page said "the missing piece is bundled issuance", which reads as imminent. It is parked. The page now says why rather than leaving a reader to guess: Ghost Keys are principally a CAPTCHA replacement for one-off actions and already do that job, so per-action unlinkability is an improvement, not a prerequisite.
ZK was "the direction we expect Ghost Keys to move in". Also parked, and we now know considerably more than when that was written. Replaced with the measurements: ~400-byte proofs, ~84 ms to verify inside a contract, and the real obstacle being structural rather than speed — contract state is re-validated on every load, so verification has to happen once at admission, which a contract cannot do alone.
Backup advice predated the vault doing anything about it. It recommended downloading a backup as an aside. The vault now marks an identity un-backed-up and shows a one-click download that clears only on explicit confirmation, so the page frames it as the point of the exercise and says plainly that some nodes reclaim idle storage.
Deliberately unchanged
SignMessagelabel still depicts a real request; rewriting positioned SVG text for a nuance a diagram cannot carry isn't worth the layout risk.Docs only.
[AI-assisted - Claude]