[boboliu-1010]

Summary

• fetch participant public keys through GET /2/users/:id/public_keys instead of the batch endpoint
• preserve the owning user_id on each returned key
• identify the specific user when a key lookup fails and avoid returning partial results
• add regression coverage for the per-user routes and failure behavior

Why

Some production X apps can access the per-user public-key endpoint but receive client-not-enrolled from GET /2/users/public_keys?ids=..., even when the batch contains a single user. That prevents xurl chat read from loading signing keys and verifying messages.

Using the per-user route trades one batch request for one request per participant, but works across apps that are not enrolled for the batch endpoint and preserves the same result shape for callers.

Verification

• go test ./api
• go test ./...
• go vet ./...

Fixes #94

[vkurilyak]

Big fan of xurl, thanks for building and maintaining it.

Confirming the same behavior on a matching setup, and +1 for the per-user route.

Environment: macOS arm64, xurl v1.3.1, OAuth 2.0 user context, X app on Pay-per-use, chat keys restored via Juicebox. xurl whoami and xurl chat conversations work.

Repro before the fix:

• xurl chat read @handle --no-mark-read logs could not fetch public keys ... client-not-enrolled and cannot decrypt messages.
• GET /2/users/public_keys?ids=<single id> returns client-not-enrolled for this app, even with one id in the batch.
• GET /2/users/<id>/public_keys returns valid keys for both my account and the counterparty with the same app and token.

Verified this PR branch locally: built with CGO_ENABLED=1, go test ./api passes, and chat read now decrypts and verifies live 1:1 threads, including a conversation that includes a KeyChange event. Five consecutive reads on the same thread decrypted correctly. Thanks for the fix.

[boboliu-1010]

Thanks for the detailed independent verification — especially testing a live thread with a KeyChange event and repeated reads. That confirms the per-user route fixes the issue in another production setup. No additional changes are planned from my side; this is ready for maintainer review.

[menhguin]

Independently verified this PR at fe2bcb4b05c4009d0bd2f813126c0a9bc145db9e on macOS arm64, with CGO_ENABLED=1 and Go 1.27.1.

The official v1.3.4 binary still reproduces #94: with the same explicitly selected app and OAuth 2.0 user, each participant's /2/users/<id>/public_keys succeeds, while /2/users/public_keys?ids=... returns client-not-enrolled. Native Chat then cannot verify/decrypt the conversation.

With this PR:

• go test ./api, go test ./..., and go vet ./... pass.
• Two consecutive live chat read --json --no-mark-read -n 100 calls return identical output: 98 events, including 77 message events, all 77 signature-verified, with no decryption warnings.
• All 77 messages match our existing per-user-endpoint + official Python Chat XDK reader on the text/edit/reaction fields compared.
• chat download successfully decrypts an encrypted image attachment; the resulting JPEG decodes with the dimensions advertised by the attachment metadata.

No message sending, read receipts, key rotation, or weakened signature verification was needed. These are bounded-read/media tests, not a claim of exhaustive history coverage.

This is a working fix for an existing released-client failure. Could a maintainer review it for inclusion in a release? Thanks for the focused patch.

Separate, non-blocking follow-up: the failing released chat read --json prints null and exits 0 while logging per-event verification errors. Machine-readable incomplete/error status or a nonzero exit would help automation avoid treating that failure as an empty inbox; this PR need not expand scope to address it.