Repository navigation
G3 Community chat: Chat and People with Home #86
Description
Current design (Anders, 14 Oct, comment 6171916401): in 0.8.0 Community posts travel over the gossip topic through the seed's Community node, which only forwards (it stores and confirms nothing); direct Home-to-Home delivery stays. The Carrier relay (#345), DMs across networks and offline catch-up across networks move to 0.8.1. Items below that assume the relay or a storing seed node are 0.8.1.
Release: 0.8.0. Owner: Anders (@andersalm). OMP owns integration and release. Irzhy (@irzhywau) reviews selected risky areas on one frozen SHA; Sasha (@SashaMIT) owns PR #116 and phone acceptance.
Goal and ownership
A person opens Home, joins Community, finds another person, approves a contact through Inbox, and sends a direct message in the same Chat window. On return, the person sees the right conversation, history and delivery state.
Proof for Chat lives here. Code: PR #309, then the Community node follow-up (branch fix/139-community-node); relay #354; Community pin (branch feat/community-release-pin, which includes #334). #260 holds guest sign-up; #264 Leave/Rejoin. #323 holds the full retention and rejoin rules in After 0.8.0.
Runtime owns identity, authorization, routing, delivery evidence and lifecycle. Profiles sign authored messages. Every Home keeps its own copy and checks every post; in 0.8.0 the Community node only forwards (design note above). Chat requests scoped Runtime operations and presents clear controls. This follows PRINCIPLES.md, especially local ownership, stable identity, explicit authority and one canonical operation path.
Done means
Each exposed feature works from start to end, including recovery. Keep an unfinished feature hidden until its journey passes; hiding it leaves its task open. Source checks and green CI are separate from installed acceptance.
- Join: Create account is visible on the first screen. A new visitor signs in within 30 seconds and enters Community, with welcome text for a new account.
- One Community: fresh
install.shHomes, and people signed in to them from a browser, share the release-default Community and send/receive both ways. Runtime installs and verifies the signed network configuration through the canonical setup/update path. - Speed and initial history: messages appear for other people on the same Home within 1 second and between Homes within 3 seconds. Local history appears when Chat opens.
- Chat basics: desktop Enter sends and Shift+Enter adds a line. Phone Return retains the accepted newline behavior. Times and day separators use the local calendar. Direct conversations and Community have per-account unread badges; direct messages also notify.
- Connect: every participant name opens a Profile card with Message and Add contact. Message opens the exact direct conversation inside the same Chat window. Add contact from Community reaches the recipient's Inbox with a notification. Discovery starts off and, when enabled, shows people within a few seconds.
- The approved contact route,
POST /api/apps/chat-room/contacts/request, requires a valid Chat launch token and the sender's own Profile. The recipient decides in Inbox. Bounds: 16 requests per sender, 128 stored records, 512 KiB.
- The approved contact route,
- Direct messages: accepted contacts exchange signed 1:1 messages across Homes when both are online. Re-check on the candidate (see 0.8.0: Release 0.8.0 #93). Earlier proof (alpha.19, same network ~0.35 s; across networks is 0.8.1): G3 Community chat: Chat and People with Home #86 (comment)
- Authority: people approve their contacts and explicitly enable Discovery. Runtime verifies Profile authorship and destination authority. For 0.8.0 the only bootstrap is the seed host's separate Community node (item 9); participant Homes retain message ownership. The seed's install/release role (Seed: run the seed service under its own account without sudo or Docker #174) runs apart from it.
- Installed proof: on the signed candidate, Homes on the same network pass the complete journey. Repeat after restart and update, and record signup/message times.
- Availability (0.8.0): the release network lists one bootstrap peer, the Community node on the seed host. It runs as its own Runtime (own account, data root, port and resource limits), apart from the release and update service. Carrier connects Homes directly. While the node is unreachable: Homes already connected keep exchanging Community messages and catch-up; a Home that starts or restarts cannot join Community; Discovery and new contact requests stop; new direct messages show Sending, are retried for up to 24 hours and then show expired; nothing already received is lost; Chat states plainly that Community is unreachable. Canonical text:
docs/COLLABORATION_NETWORK_PROFILE.md"Availability". Any Home serving as bootstrap: Community works while any participant is online (open bootstrap and relay) #324. - Delivery across networks (Discovery off): 8 Homes, 56/56 pairs in 0.6-2.2 s. Proof: G3 Community chat: Chat and People with Home #86 (comment) item 1
- Restart: other Homes keep exchanging while one restarts; it returns to Live without reload. Proof: same comment, item 2
- Link recovery: seed link cut shows "Community unreachable" and returns to Live after restore without reload. Proof: same comment, item 3 (posts sent during the cut did not reach the cut Home)
Moved to 0.8.1
Per the 14 Oct design note: catch-up from the Community node for a Home that was away; Post when alone (the node keeps posts for later joiners); installed proof with Sasha's and Irzhy's Homes over the relay; relay fallback in Availability (#345). Scale (30 members, 7-day catch-up) is not a release gate.
Not in 0.8.0
Invite links and QR codes, an offline direct-message mailbox, user-created groups and reactions (#323, #342, #285).
Activity
andersalm commentedon Sep 29, 2026
Retained Chat test detail from the earlier product reviews:
Define and test pending, delivered, failed and expired message states. Explain presence separately from Home availability, and state what delivery is possible when the recipient stays offline beyond retention. Exercise restart, contact removal and relay/rendezvous loss. Keep sender retry evidence separate from offline store-and-forward delivery.
Community remains the onboarding space. User-created groups are later work. This adds detail to the existing messaging and offline criteria; it does not create another Chat workstream. The issue body now replaces the copied Chat briefing as the work record.
irzhywau commentedon Sep 29, 2026
Implementation plan (checklist)
Work branch:
feat/0.7.1-chat-people-on-invite, stacked on #117 (fix/chat-invite-in-home-0.7.1-models), which targetsfeat/0.7.1-models. All 0.7.1 work is in #123, which replaced #121. Follow-up work is in #139. #123 merges after #117. Anders reviews the Runtime and server changes. Sasha reviews the first-visit and Chat design.Decisions (2026-09-29)
Review decisions (Anders, 2026-09-29)
docs/COLLABORATION_NETWORK_PROFILE.mdchanges in the same PR.1. The three blockers
Create account on the first screen. The lock screen shows a "Create account" button when guest sign-up is on. It opens the existing guest passkey flow. (In Chat and People with Home: connect, approve contacts and recover (#86) #123. Waiting for review and the live check.)
0.7.0-devwithout this fix. The button is#home-unlock-create; the passkey circle is#home-unlock-person("Use passkey"). QA should target these after the fix is deployed.Welcome text fits the account. A new account sees "Save a Recovery Kit so you can get back into your account." The "updated kit" text is only for accounts whose kit predates their Profile. The server now tells Home which case applies. (In Chat and People with Home: connect, approve contacts and recover (#86) #123. Waiting for review and the live check.)
Discovery is fast and honest. Discovery shows "Connecting…" while it reaches the seed, retries within 15 seconds while it is on, and retries at once when the person turns it on or presses Refresh. Failed passes are logged so the seed shows the cause. People updates on its own when Discovery connects. (In Chat and People with Home: connect, approve contacts and recover (#86) #123. Waiting for review and the live check.)
Every Home joins Community automatically. The signed release carries the seed's signed network profile, the same way it carries the model catalog.
elastos setup(and soinstall.sh) installs it, and updates move it forward only along its signed chain. People can choose an isolated Home with an explicit setting. (In Chat and People with Home: connect, approve contacts and recover (#86) #123: setup and update install the pinned network,elastos setup --isolatedandinstall.sh --isolatedkeep a new Home isolated, and a Home publishes its network file atGET /.well-known/elastos/collaboration-network.json. Nothing changes until a release carries the pin.)docs/COLLABORATION_NETWORK_PROFILE.mdstates the new rule, in the same PR. (In Chat and People with Home: connect, approve contacts and recover (#86) #123.)generate-revisionorgenerate-initial, confirm its connect ticket lists only public addresses, and commit it with its pin incomponents.json. Not needed to merge Chat and People with Home: connect, approve contacts and recover (#86) #123: without the pin nothing changes.Discovery keeps working when one queued contact request or answer is refused (for example after the meeting-point Home restarts). (In Chat and People with Home: connect, approve contacts and recover (#86) #123.)
The meeting-point Home pins its Carrier address. Found in a two-Home test: without
carrier_bind_addr, a restart can move its port and every other Home loses the network (contacts one-sided, direct messages stuck on Sending).docs/TROUBLESHOOTING.mdrecords the diagnosis. The public Home needs its port pinned before its network file ships.A way to publish a second signed version of a network file when the meeting point's address changes:
elastos collaboration-config generate-revision. (In Chat and People with Home: connect, approve contacts and recover (#86) #123. Used on 2026-09-30 when a test Mac's address changed.)Build identity: the public Home reports no build or commit (QA-30). Anders decides whether Home should report one, so QA and the release test can name the exact build.
2. Connect in one or two clicks
invites/joinandinvites/claimanswer "Room join claims are unavailable through this legacy transport path". A second Home can join from the link only after this server work.3. Chat basics
Enter sends, and Shift+Enter makes a new line (with input methods).Covered by Model screens, chat Enter to send, centred windows and Reconnecting (desktop part of #116) #134 (Sasha). Model screens, chat Enter to send, centred windows and Reconnecting (desktop part of #116) #134 merges cleanly with Chat and People with Home: connect, approve contacts and recover (#86) #123 and does not overlap it.4. Delivery and catch-up — moved to #139
5. Small spam limits — moved to #139
Later (next release)
Encrypted mailbox, invite link and QR, user-created groups, attachments in direct messages, moderation beyond the block list.
Proof
just test: 4626 passed, 0 failed; entropy, alignment and Inbox smoke pass.)install.shHome joins Community with no setup step.irzhywau commentedon Sep 29, 2026
@andersalm what do you think about this plan for now? does it fit with your expectation?
andersalm commentedon Sep 29, 2026
@irzhywau Yes, the plan fits. My decisions:
docs/COLLABORATION_NETWORK_PROFILE.mdin the same PR.feat/0.7.1-models, one per checklist group, each with "Part of G3 Community chat: Chat and People with Home #86", blockers first. Mark a PR ready when its part works end to end. I review the Runtime and server parts; Sasha reviews the first visit and the Chat design.andersalm commentedon Sep 29, 2026
QA retest 2026-09-29 (public Home)
Verdict: STILL_REPRO on https://elastos.elacitylabs.com/home/
Steps
/home/as a new visitor (no session).Expected
Create account / Create guest and Use passkey are visible and clickable on the first screen (per Done means: new visitor sees Create account).
Actual
#home-unlock-primary(“Use passkey”) and#home-unlock-secondary(“Create guest account”), both 0×0 rects (display:block/visibility:visible/opacity:1).Build / identity
0.7.0-devvia/api/apps/home/summaryandruntime/ensure.x-elastos-build/ git-sha response header on/home/.Evidence
Local (box):
/workspace/elastos-qa/github-reset-20260929/retest-public/—RETEST.md,qa30-*.png,qa30-dom.json.Notion archive id: QA-30.
irzhywau commentedon Sep 30, 2026
@andersalm What do you mean here?
Especially the part: "until the server join step works."
andersalm commentedon Sep 30, 2026
@irzhywau By "the server join step" I mean the two endpoints that let a second Home join a room from an invite link:
invites/joinandinvites/claiminelastos-server/src/api/gateway_room.rs(lines 881 and 932 onfeat/0.7.1-models). They still answer "Room join claims are unavailable through this legacy transport path", as you noted on #117.So with #117 merged, Home would show "Create join link", but a second Home that opens the link could not join. That is a visible control that does not work, so it stays hidden: #117 stays a draft until those endpoints work, together with invite links and QR in 0.7.2.
One consequence: please rebase #123 onto
feat/0.7.1-modelsand target it there directly, as #121 did. Its three changes (Create account, welcome text, Discovery) touch no chat-room files and merge cleanly without #117, so they should not wait for it.andersalm commentedon Sep 30, 2026
@irzhywau heads-up to avoid double work: Sasha's #134 already contains "Enter sends, Shift+Enter starts a new line" (with input-method handling) for Chat. Please take that item off your checklist, and review the Chat part of #134 when it leaves draft.
irzhywau commentedon Sep 30, 2026
ok got it
84 remaining items
andersalm commentedon Oct 14, 2026
RC 0.8.0-alpha.16, Anders, 14 Oct: Mac and Jetson Homes in the release Community saw nothing of each other until People -> Discovery was turned on on both; then posts and Chat synced. The Linux acceptance (comment above) failed for the same reason. Community must work without the Discovery switch: fix options being compared now.
andersalm commentedon Oct 14, 2026
Cross-network test on the RC, 14 Oct: a Namespace box and Anders's Jetson (home NAT), Discovery on: People presence crossed in 3 s through the seed node, but Community posts did not arrive (box post stayed Sending for 3 min). Same-LAN Homes work. Posts go Home to Home directly, with no relay (#345 is 0.8.1), so Homes behind different routers cannot exchange posts in this RC.
andersalm commentedon Oct 14, 2026
Decision (Anders, 14 Oct): 0.8.0-alpha.17 restores Community posts and receipts over the gossip topic (as in alpha.15), keeping direct delivery; the seed node only forwards, never stores or confirms. Posts are signed but readable by the seed in transit until the relay (#345, 0.8.1) makes delivery end-to-end encrypted.
Acceptance: Homes on different networks with Discovery off on both.
andersalm commentedon Oct 15, 2026
RC 0.8.0-alpha.17 (source 37df2f6), Linux x86_64 Namespace box, Discovery off, 15 Oct: fresh install 1 min 20 s; sign-up and Community join pass. Posts are shown once, and 'Sending' clears only on another Home's signed receipt (alpha.17 Home "Test Update", not the seed). Delivery takes 33-89 s both ways (box post at 05:13:00Z got its receipt at 05:14:28Z; "hey" took 55 s), so the 10 s target fails. The post-while-Home-stopped check could not be run (no partner post).
Cause (gossip debug log on the box): the QUIC connection to the seed Community node d17d1552 times out every 35-55 s (
connection lost: timed out→ NeighborDown → redial → NeighborUp). Frames arrive only in the 1-2 s burst after each NeighborUp, so the receiver-side RetryRequired stall does not explain the delay.Seed:
elastos-community(alpha.15) uses its full 1-CPU quota (cgroup usage about 1.0 s/s, nr_throttled rising), runs one tokio worker, and has a full UDP receive queue on 77.42.19.31:4434 (Recv-Q 427 KB; RcvbufErrors rising). It drops packets, and the paths die. Fix: find what is using that CPU and raise the quota/workers, or upgrade the node to alpha.17. Neither has been tested.andersalm commentedon Oct 16, 2026
Installed alpha.19, two Linux Homes on two networks, seed Community node on alpha.19: Community posts with Discovery off A->B ~1.9 s, B->A ~2.4 s; Discovery on: People shows the other member across networks, contact request, Open Inbox and Accept work; same-network direct message ~0.35 s; message box back to one line; People -> Message reuses the Chat window. PASS. As documented in the [0.8.0] notes, direct messages across networks stay "Sending" until the relay (0.8.1); non-blocking: Retry gives no feedback and on one send the text stayed in the box.
andersalm commentedon Oct 16, 2026
Possible 0.8.0 blocker, under investigation: Anders's Jetson Home (alpha.19) stopped receiving Community at 00:28Z, right when another Home on the same network restarted for its update, and stayed "Community unreachable" for 55+ min; UDP to the seed works, the seed forwards nothing to the Jetson and the Jetson sends no rejoin; a page reload does not help. Hypothesis: a stuck neighbour connection blocks iroh-gossip (0.101) sends (net.rs:686). Reproducing on Linux boxes (two Homes on one network + one on another, restart one).
andersalm commentedon Oct 16, 2026
Remaining for 0.8.0 (15 Oct 22:45 COT; final candidate alpha.21 = alpha.20 + automatic Community recovery; plan #93 6207232773): full rerun on installed alpha.21: two networks with Discovery off, the restart-freeze scenario on Anders's Mac + Jetson, and a forced dead link recovering by itself without reload. Relay, storing node and cross-network direct messages are 0.8.1 per the 14 Oct design.
andersalm commentedon Oct 16, 2026
Automatic recovery proven on real Homes (source builds of the final head 55dcb79 and of 78b6e33; three Homes on two networks, real seed node, Discovery off): with one Home's UDP to the seed blocked for ~3 min it showed "Community unreachable", rejoined, rebuilt its gossip link and logged "Community link recovered" 7 s after the link returned, then received posts again without reload or restart. Restarts (SIGKILL/SIGTERM on both networks): posts flow all ways, no watchdog churn; 15 min of silence and a Discovery-on Home going offline: 0 rejoin/rebuild lines; the seed logs "watchdog is off: this Runtime is a Community bootstrap node". Evidence kept by OMP. Posts sent while a Home is cut off do not arrive later (no catch-up with Discovery off; 0.8.1 storing node).
andersalm commentedon Oct 16, 2026
Likely root cause of the Community freezes (16 Oct): Carrier builds iroh-gossip with the default membership config, active_view_capacity = 5 (iroh-gossip 0.101 hyparview.rs:202). The seed Community node is the hub for Homes behind NAT; with more than 5 Homes joined it keeps 5 active neighbours and evicts a random one whenever another Home (re)joins, and the evicted Home has no other neighbour, so it shows "Community unreachable". Seen twice when one Home restarted: the Jetson last night, and three Linux test Homes on separate boxes at 11:48Z today. Earlier tests never had more than 5 Homes. Also: the watchdog treats trickling frames as healthy and does not recover a Home with 0 peers. Fix in progress for alpha.22 (hub capacity on the bootstrap node; watchdog rule), with the replay-table fix #401.
andersalm commentedon Oct 16, 2026
Seed Community node upgraded 0.8.0-alpha.19 → 0.8.0-alpha.22 at 18:23Z 16 Oct (signed hashes verified; rollback files .before-1792175000). It now logs:
carrier: this node is a Community bootstrap node; gossip runs as the hub active_view=512. So the 5-neighbour limit (root cause, 6215286052) no longer applies at the hub; Homes keep the iroh defaults. Installed checks with 8 Homes across networks (joins, restarts, a cut link, 30 min of presence) are running now on alpha.22 (head QmXnA5ao7PMfwdj7pGaxpWs14gfgD15FtmhVQPj1EphFXm).andersalm commentedon Oct 16, 2026
alpha.22 installed checks: Community across networks PASS. Six (then eight) Homes on separate networks: every pair delivered in 0.6-2.9 s. With one Home restarted (twice), the others were unaffected and the restarted Home rejoined. Discovery on/off in every combination: 30/30 pairs. Evidence: rc-tests/runs/a22-community8-20261016T1825Z/runs/. The seed hub runs as the hub (6222024819).
For 0.8.1 (Community first run, with #92 6219855275 item 3): Homes with Discovery on showed "Earlier Community posts cannot be loaded right now." while three other Discovery-on Homes were online. Discovery visibility windows are ten minutes, and history needs both sides visible at once (window30.json), so earlier posts rarely load. A new Home with Discovery off sees "Turn on Discovery in People to load earlier Community posts." Anders: having to use Discovery for Community is confusing; Community should not need it.
andersalm commentedon Oct 16, 2026
alpha.22 Community with 8 Homes across networks + 1 Mac Home: all six items PASS (evidence rc-tests/runs/a22-community8-20261016T1825Z/runs/).
Remaining for first run: Community should work without Discovery: a new Home sees nobody and no earlier posts #410 (Community without Discovery), being built for alpha.23.
andersalm commentedon Oct 16, 2026
Added three ticked boxes proven by the alpha.22 8-Home run (#86 (comment)): delivery across networks with Discovery off, restart, link recovery. All other boxes stay open: history, contacts, Join/first run depend on #410 (alpha.23); alpha.22 evidence does not accept alpha.23.
andersalm commentedon Oct 19, 2026
Anders reports that Sasha's Community now works after the latest alpha, while Anders-to-Sasha DMs still fail through Retry. The actual DM HTTP result and reverse direction remain unmeasured.
Published alpha.23
bfefe92f619f48468b117dad957659862917e166sends DMs through a separate Carrier PeerDid invocation; invocation failures return Pending and Retry reuses the durable signed message (source). Community success therefore leaves this pair route and receiving contact admission to check; the general relay remains in #345.OMP owns the target trace: capture a current send/Retry HTTP status and safe delivery fields, both accepted-contact states, the sender's exact Carrier failure or the receiver's admission result, and whether Sasha sees the message. Preserve both Homes and keep raw logs, tokens and message bodies private.
andersalm commentedon Oct 19, 2026
Anders confirms that Mac–Jetson DMs deliver in both directions. The earlier People Online/Offline mismatch was resolved when he enabled Jetson Community visibility.
This is human installed evidence for that pair; the exact artifact and visibility-mode receipts remain uncaptured. The report does not establish that visibility controls DM delivery.
Anders-to-Sasha DM failure remains open. Its connection, receiver-admission and receipt-return paths still need target evidence.