[santiagomed]

Summary

Brings the SDK's v1 behavior in line with the native clients in every binding (Rust, Python, JS/WASM, Go, JVM, .NET, C ABI). Every fix lands once in crates/core. The bindings gain the retry loop for the feature-switch read, three optional fields a v1 send needs when the caller holds no original event (see New optional fields), and their parallel tests. Nothing else in the public API changes.

• Signatures
  • Every signed action follows the send format: version 7 while a chat sends v0, and 10 while it sends v1. This covers key changes, group creates (their type and TTL are then signed), member adds, removals and leaves, deletes, read receipts, and admin, invite, join, TTL and screen-capture changes. A member add with a description still signs at 8 while sends are v0.
  • Removals and leaves no longer sign at 11, so 0.5.x readers verify them while sends are v0.
  • All signing goes through the one payload builder the verifier uses.
  • A group change that removes a title, description or avatar now verifies: the native clients sign it with null in the value's place.
  • An event whose signature carries no version, or one that isn't an integer, fails verification instead of verifying as 7.
  • Key versions of messages and key changes sign as integers at every version.
• Replies
  • A preview is valid only when the first 140 characters of its text, counted in UTF-16 code units, match the quoted text, and its entities are exactly the quoted message's (or its edit's).
  • Replies no longer embed key changes (raw_event_ckces), and decrypt never reads them from a reply.
• v1 sends
  • The encoded signature lists the signing keys the message relies on (message_signing_key_info_list): the sender's, plus the quoted message's and its edit's for a reply.
  • A reaction asks for a notification only in a one-to-one conversation; a reaction removal or an edit asks for none.
• Files: payment receipts take no position when attachments without an id are numbered.
• Feature switches
  • A failed startup read is retried in the background: 1 s, then doubling, at most 5 min apart, 10 times. The schedule lives in the core and every binding follows it.
  • The first answer that arrives sets the switches, so a chat reaches v1 once a retry succeeds.
  • set_feature_switches / chat_xdk_set_feature_switches accept a later answer after a failed one.
• Docs: each change is folded into the 0.7 migration guide for every binding and into why.md, with install pins moved to 0.7.2. API.md (including how to hash a file in each binding), CRYPTO.md, ARCHITECTURE.md, the READMEs, AGENTS.md (the bounded retry replaces the fetch-once rule) and the CHANGELOG are updated too. The guides now build a reply from explicit fields with reply_to_message_id.

Before / after

left = chat.prepare_group_leave(GroupLeaveParams("g100"))
[s["message_event_signature"]["signature_version"] for s in left["action_signatures"]]

# Before: the removal signs at 11 and the delete at 7, whatever the send format
# ['11', '7']

# After: every action follows the send format
# ['7', '7']    while the chat sends v0 (0.5.x readers verify both)
# ['10', '10']  once v1_send is on, as the native clients sign

# Feature switches, startup read fails once:
# Before: every switch off for the chat's lifetime, sends stay v0
# After:  retried 1 s later, the answer turns v1_send on for the chat

New optional fields

Each one is optional in every binding, and callers that don't set it build the same sends as before.

• reply_to_message_id on EncryptReplyParams (replyToMessageId in JS and on the JVM, ReplyToMessageID in Go, ReplyToMessageId in .NET). It names the quoted message by its signed message_id. X clients mark a v1 reply that embeds no message-key original and names no original invalid, so a reply built from the explicit preview fields needs it. With reply_to_event, the id comes from the event and the field overrides it.
• target_message_id on EncryptEditParams (targetMessageId in JS and on the JVM, TargetMessageID in Go, TargetMessageId in .NET). It names the edited message. With target_event, the id comes from the event and the field overrides it. Without target_event, the SDK has only the target's sequence id, so a v1 edit built from conversation_id and target_message_sequence_id needs it. A v0 edit names none, as in 0.5.x.
• plaintext_sha256 on the media attachment descriptor. It is the base64 SHA-256 of the file's plaintext bytes, which the message carries and signs. The message is built before encrypt_file sees the file, so the caller hashes the file. A value that is not the base64 of 32 bytes fails the send with an invalid-input error that names it. Decrypted media attachments return it as plaintext_sha256 (plaintextSha256 in JS), or null when the sender sent none. The JVM and .NET get an eight-argument media / Media factory, so existing calls keep compiling. Go gets AttachmentDescriptor.PlaintextSHA256.

Rust source change: AttachmentDescriptor::Media gains the plaintext_sha256: Option<String> field. Code that builds the variant with a struct literal must add plaintext_sha256: None, and a pattern that lists every field must add it or end in ... The CHANGELOG notes this.

Notes for review

• A removal at 7 or 10 does not sign the new key version its event names (11 did). The key change that carries the new key signs its version, and nothing reads a key from the removal.
• A v1 edit asks for no notification. The native clients notify on an edit only behind a switch of their own; if that switch is on by default, edits should notify instead.
• The committed Go prebuilts are rebuilt by the prebuilt sync workflow on push.

Testing

• make ci passes: fmt, clippy -D warnings, cargo-deny licenses, workspace tests and the bindings gate.

• The fuzz targets compile.

• Locally, the Python, JS/WASM, Go, JVM and C ABI suites pass, each with a new test that a leave signs at 7, then at 10 once v1 is on. The .NET suite (updated the same way) couldn't restore packages here, so CI runs it.

• The migration-guide snippet checks pass for all seven languages.

• The 0.5.0 / 0.5.2 compat check passes unchanged.

• New core tests:

  • known-answer payloads for every action at versions 7 and 10, plus key changes, group creates and member adds;
  • null removals, missing and non-integer versions, and integer key versions;
  • exact preview text and entities, including a surrogate pair at the 140-unit limit;
  • no embedded key changes, the signing-key list, notification flags and payment-receipt numbering;
  • the retry schedule, joining chats, dropped chats, late answers and answers that hold.

• The new fields have core tests for v0 and v1 sends, overrides of the derived ids, the decrypted hash, and invalid hashes in a message, a reply and a reply preview. There is a C ABI invalid-input case, and every binding has a round trip that reads each field back from the decrypted send.

• For that change, cargo test --workspace, clippy -D warnings, fmt, the Go and Python suites, and the Rust, Python, TypeScript, Go and C guide snippet checks pass locally. The JS, JVM and .NET suites run in CI.

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 3 committers have signed the CLA.

✅ santiagomed
❌ cursoragent
❌ github-actions[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

1 out of 2 committers have signed the CLA.
✅ (santiagomed)[https://github.com/santiagomed]
❌ @cursoragent
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}