OverviewFilesCommitsIssuesDocsReleasesPeers

pgh commits / 571e651

0.1.145: pgh names reanchor --force
A peer running code without an OP_REANCHOR_NAME branch consumes the op and advances past it. A new op TYPE does not degrade gracefully the way a new field does — the old peer cannot tell it ignored anything — and upgrading afterwards does not re-run history, so its view keeps the device anchor forever. Observed: after re-anchoring 13 claims on tabertron, stortron and ashatron (read-only participants in the same autobase, then on 0.2.55) still showed identityRoot d92e2f4e4cae… from identical history. Upgrading them to 0.2.56 did not fix it. --force re-emits the op regardless of what THIS peer's view shows. apply tests `claim.identityRoot === op.devicePubkey` against each peer's own view, so the fresh op re-applies where the anchor is still the device key and is skipped where it is already the root. Idempotent by construction — the property the verifier was designed around. Forge org #142. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
571e651c68286d3811c864f8db69d0c35392ef6f
by plankatron <fleeky@gmail.com> · 2026-08-25T18:26:37.000Z

Changed files (2) +10 -5

lib/commands/names.js +9 -4
……@@ -29,7 +29,8 @@ export const usage = `pgh names / claim / release — NameRegistry (sidecar-owne
2929 pgh names resolve <name>
3030 pgh names update <name> [--registry-key <hex>] [--server-key <hex>] [--description "..."]
3131 Re-point a name you own (rotate registry/server key)
32 pgh names reanchor <name> | --all Repair a claim anchored to a device key (org #142)
32 pgh names reanchor <name> | --all [--force]
33 Repair a claim anchored to a device key (org #142)
3334 pgh names info
3435 pgh names subscribe <registryKeyHex> Replicate another publisher's NameRegistry (read-only)
3536 pgh names subscriptions List own + subscribed name registries`
……@@ -166,19 +167,23 @@ export async function run (_client, args) {
166167
167168 if (sub === 'reanchor') {
168169 const all = hasFlag(args, '--all')
170 // Re-emit even where this peer already shows the claim re-anchored: a peer
171 // that applied the op without an OP_REANCHOR_NAME branch consumed it, and
172 // upgrading does not re-run history. The op is idempotent per-peer.
173 const force = hasFlag(args, '--force')
169174 const name = args[1] && args[1][0] !== '-' ? args[1] : null
170175 if (!name && !all) {
171 throw new Error('usage: pgh names reanchor <name> | pgh names reanchor --all')
176 throw new Error('usage: pgh names reanchor <name> | pgh names reanchor --all [--force]')
172177 }
173178 return withClient(async (c) => {
174179 const targets = name ? [name] : (await c.call('list-names', { own: true })).map(e => e.name)
175180 const out = []
176181 for (const n of targets) {
177182 try {
178 const res = await c.call('reanchor-name', { name: n })
183 const res = await c.call('reanchor-name', { name: n, force })
179184 out.push({
180185 name: n,
181 status: res.alreadyAnchored ? 'already anchored' : 're-anchored',
186 status: res.alreadyAnchored ? 'already anchored' : (res.forced ? 're-emitted (for peers behind)' : 're-anchored'),
182187 identityRoot: res.entry.publisher.identityRoot
183188 })
184189 } catch (err) {
package.json +1 -1
……@@ -1,6 +1,6 @@
11{
22 "name": "pgh",
3 "version": "0.1.144",
3 "version": "0.1.145",
44 "description": "pgh \u2014 P2P content-addressed package manager and app launcher",
55 "type": "module",
66 "main": "index.js",