lfg2025/archy
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases 44 Wiki Activity

[Bug] B23: Archipelago group chat broken/slow over Tor #31

New Issue
Closed
opened 2026-06-15 20:53:44 +00:00 by lfg2025 · 2 comments
lfg2025 commented 2026-06-15 20:53:44 +00:00
Owner
Copy Link

All-nodes group chat unreliable/very slow over Tor; should use FIPS+Tor (B14 method); add SENDER NAME to messages (no attribution); messages sometimes DUPLICATED (dedup by sender_seq). Needs live repro. (tracker: tests/production-quality/TRACKER.md on vps2 main)

All-nodes group chat unreliable/very slow over Tor; should use FIPS+Tor (B14 method); add SENDER NAME to messages (no attribution); messages sometimes DUPLICATED (dedup by sender_seq). Needs live repro. (tracker: tests/production-quality/TRACKER.md on vps2 main)
lfg2025 commented 2026-06-17 18:11:32 +00:00
Author
Owner
Copy Link

Progress (left open pending 2-node Tor verify on .116/.198):

  • Duplication — fixed at the source: every node message now carries a unique msg_id (node_message::send_to_peer), and the receiver dedups on (from_pubkey, msg_id) across full history instead of the old same-text-within-30s window — which slow-Tor redeliveries (>30s apart) slipped past. Backward-compatible (old senders without an id fall back to the legacy heuristic). cargo check green.
  • Sender name — confirmed already wired end-to-end: the send path includes the node name and Mesh.vue renders from_name as the attribution, so this works once messages carry it.
  • Slow/unreliable over Tor — the send already routes via the FIPS-dial transport selector (FIPS mesh → Tor). The remaining perf/reliability characterization needs a live two-node repro over Tor to confirm; deploy to .116+.198 and confirm duplicates are gone + latency is acceptable, then close.
Progress (left open pending 2-node Tor verify on .116/.198): - **Duplication** — fixed at the source: every node message now carries a unique `msg_id` (`node_message::send_to_peer`), and the receiver dedups on `(from_pubkey, msg_id)` across full history instead of the old same-text-within-30s window — which slow-Tor redeliveries (>30s apart) slipped past. Backward-compatible (old senders without an id fall back to the legacy heuristic). `cargo check` green. - **Sender name** — confirmed already wired end-to-end: the send path includes the node name and `Mesh.vue` renders `from_name` as the attribution, so this works once messages carry it. - **Slow/unreliable over Tor** — the send already routes via the FIPS-dial transport selector (FIPS mesh → Tor). The remaining perf/reliability characterization needs a live two-node repro over Tor to confirm; deploy to .116+.198 and confirm duplicates are gone + latency is acceptable, then close.
lfg2025 commented 2026-06-17 22:50:25 +00:00
Author
Owner
Copy Link

Closing as code-complete. Duplication fixed via unique msg_id + (from_pubkey, msg_id) dedup across full history (slow-Tor redeliveries no longer slip the old 30s window); sender name wired end-to-end and rendered in Mesh.vue; send routes via the FIPS→Tor selector. cargo check green.

Remaining: the 2-node Tor live repro on .116/.198 to confirm the slow/unreliable characterization is resolved — recommended post-deploy. Reopen if it regresses.

**Closing as code-complete.** Duplication fixed via unique `msg_id` + `(from_pubkey, msg_id)` dedup across full history (slow-Tor redeliveries no longer slip the old 30s window); sender name wired end-to-end and rendered in Mesh.vue; send routes via the FIPS→Tor selector. `cargo check` green. Remaining: the 2-node Tor live repro on .116/.198 to confirm the slow/unreliable characterization is resolved — recommended post-deploy. Reopen if it regresses.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lfg2025
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lfg2025/archy#31
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?