fix(mesh): Meshtastic 3ccc pkc_capable pill + Sideband image interop + critical CBOR wire-bloat fix
Merges in the meshtastic agent's now-finished work alongside this session's
continuation: stock-peer (3ccc) PKI-capability is now stamped through
get_contacts -> refresh_contacts -> MeshPeer.pkc_capable, so a directed DM to/from
a PKC-capable stock Meshtastic peer correctly shows the E2E pill on the Sent row,
not just received messages. Confirmed live: .198 sees "Meshtastic 3ccc" with
pkc_capable=true.
Also fixes two real interop/correctness bugs found while live-testing the
Reticulum <-> Sideband link:
- Receive: the daemon only ever read LXMF's plain-text content, silently
dropping native FIELD_IMAGE/FIELD_FILE_ATTACHMENTS fields — a stock
Sideband/NomadNet photo vanished into a blank-space message. Now decoded
into the same ContentInline typed envelope our own attachments use.
- Send: images to a non-archy (stock) peer now use native LXMF FIELD_IMAGE
instead of our own opaque CBOR wire format, which Sideband can't decode.
- Root cause of a garbled MC-chunk-fragment bug: TypedEnvelope.v/.sig (the
OUTER wrapper every message type uses) serialized raw bytes as a CBOR
array-of-integers instead of a native byte string, bloating every
message on the wire ~2-3.5x — enough to push even a tiny ReadReceipt
over the 140-byte single-frame chunking threshold. Root-caused by
reading ciborium's deserializer source directly (deserialize_bytes only
works within its internal scratch buffer; deserialize_byte_buf streams
unbounded).
Frontend: consolidated the attach/record buttons into a single animated "+"
menu (was overflowing the compose row).
857/857 tests pass. Verified live across all 5 deploy-roster nodes.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
f54c853128
commit
0eb5c258f5
@@ -691,7 +691,20 @@ impl MeshtasticDevice {
|
||||
}
|
||||
}
|
||||
}
|
||||
Ok(self.contacts.values().cloned().collect())
|
||||
// Stamp E2E capability per contact from `peer_pubkeys` (the real
|
||||
// Curve25519 keys learned from NodeInfo / inbound PKC packets), keyed by
|
||||
// node-num — which is exactly the contacts map key. This lets the send
|
||||
// path mark a Sent DM to ANY PKC-capable peer (e.g. a stock device that
|
||||
// shared its key) as E2E, not just archipelago peers.
|
||||
Ok(self
|
||||
.contacts
|
||||
.iter()
|
||||
.map(|(num, c)| {
|
||||
let mut c = c.clone();
|
||||
c.pkc_capable = self.peer_is_pkc_capable(*num);
|
||||
c
|
||||
})
|
||||
.collect())
|
||||
}
|
||||
|
||||
pub async fn reset_contact_path(&mut self, _pubkey: &[u8; 32]) -> Result<()> {
|
||||
@@ -740,10 +753,9 @@ impl MeshtasticDevice {
|
||||
/// Whether we've learned `node_num`'s real PKI (Curve25519) key — from a
|
||||
/// NodeInfo `public_key` or an inbound PKC DM — meaning the firmware can
|
||||
/// deliver DMs to/from it end-to-end encrypted instead of falling back to
|
||||
/// the channel PSK. Driver-internal for now; lets a future mesh-tab badge
|
||||
/// distinguish a true E2E DM from a channel-encrypted one without changing
|
||||
/// the shared device interface (which would break meshcore hot-swap).
|
||||
#[allow(dead_code)] // seam: consumed when the mesh-tab E2E badge lands
|
||||
/// the channel PSK. Consumed by `get_contacts` to stamp `ParsedContact
|
||||
/// .pkc_capable`, so the send path can mark a Sent DM to any PKC-capable
|
||||
/// peer as E2E (not just archipelago peers).
|
||||
pub fn peer_is_pkc_capable(&self, node_num: u32) -> bool {
|
||||
self.peer_pubkeys
|
||||
.get(&node_num)
|
||||
@@ -921,6 +933,8 @@ impl MeshtasticDevice {
|
||||
contact_type: 1,
|
||||
path_len: 0xff,
|
||||
flags: 0,
|
||||
// Stamped fresh from `peer_pubkeys` in `get_contacts`.
|
||||
pkc_capable: false,
|
||||
},
|
||||
);
|
||||
}
|
||||
@@ -1008,6 +1022,8 @@ fn packet_to_inbound_frame(
|
||||
contact_type: 1,
|
||||
path_len: 0xff,
|
||||
flags: 0,
|
||||
// Stamped fresh from `peer_pubkeys` in `get_contacts`.
|
||||
pkc_capable: false,
|
||||
});
|
||||
|
||||
// Channel broadcast (e.g. the default public LongFast channel, or any other
|
||||
|
||||
Reference in New Issue
Block a user