MODE=native: Note-to-Self "Delete for Everyone" arrives as empty syncMessage{}

[topcoder1]

Problem

In MODE=native, when a user issues "Delete for Everyone" on a Note-to-Self message from a linked device, the syncMessage envelope arrives at /v1/receive as {} (empty object). The intended syncMessage.delete payload (or whatever signal-cli's protobuf carries for sync deletes) is dropped by the native-mode envelope serializer.

Other delete paths work correctly:

• 1:1 chat delete (other party deletes): arrives as dataMessage.remoteDelete ✅
• Group chat delete: arrives as dataMessage.remoteDelete ✅
• Note-to-Self delete: arrives as empty syncMessage: {} ❌

Repro

1. signal-cli-rest-api container in MODE=native, registered with primary account, linked to a desktop device
2. From Signal Desktop, in Note to Self: send any message, then "Delete for everyone" it
3. Poll /v1/receive/+<number>
4. Observed envelope: { envelope: { source, sourceNumber, sourceUuid, sourceDevice, timestamp, syncMessage: {} } } — note syncMessage: {}

Expected

syncMessage.delete = { timestamp: <original message ts> } or equivalent serialization that exposes the deleted message id, matching what MODE=json-rpc and the underlying signal-cli json-rpc daemon emit.

Why this matters

Downstream consumers (e.g., nanoclaw — see linked PR #51 root-cause analysis) cannot react to NTS deletes because they have nothing to act on. We worked around adjacent envelope-shape issues (sync editMessage timestamp fallback, see topcoder1/nanoclaw#51) but the empty-syncMessage NTS-delete case is upstream of any consumer-side fix.

Workaround consumers are using

We currently treat this as a known limitation and document it in our consumer (PR #51 — topcoder1/nanoclaw#51).