[WIP] Improve group feature of Skychat, both on features and infrastructures - #3631
Conversation
…silently undid evictions
…alone, so an offline founder meant nobody could join
… second admin, and a stale read-modify-Put dropped replay watermarks
…ey, so a copy of the feed kept opening
… AES key to anyone who could read the file
…toggleable per group and choosable at create time
…outrun any per-PK gate, including ban
…move DmsgVisorRPCPort off a port the visor already binds
… wraps and age/volume rotation for groups
…nts were readable on encrypted groups
…d while every message beside them was sealed
mrpalide
changed the title
… it out from under membersMu, and -race found seven
…n item from the admission-control work Completes the one unchecked box in the group-admission feature set: a declined requester can DELIBERATELY re-request, without letting a refused key spam the approval queue by polling. A passive re-ask from a denied PK stays terminal (that is what defeats the poll-flood). "Ask again" is the explicit retry: it replaces the denied record with a fresh pending one after paying the SAME proof-of-work and rate-limit gates as a first request, so a declined key can queue no faster than a new one. Against an admin on an older build the flag is ignored and the denial is surfaced honestly. Core (pkg/skychat/group): - JoinRequestMsg.AskAgain wire flag, carried on BOTH the single-admin fast path and the multi-admin fan-out (the two send sites); - Manager.AskAgain(id) derives everything from the stored record (no invite re-paste) + a shared applyJoinResponse used by the retry loop too; - the admission handler honors AskAgain only past every cost gate. Surfaces (parity across all four): - Visor.GroupAskAgain + RPC (iface/server/client/mock; proxied via embedding); - native app HTTP POST /group/<id>/ask-again; - wasm skychatGroupAskAgain hook; - CLI `skywire cli skychat group ask-again <id>`; - HV UI: pending/declined room badges + inline "ask again" button + i18n. Tests: TestAdmission_AskAgainRequeuesAfterDecline + the passive-terminal test pass; full pkg/skychat/group green (ok, 77.6% coverage) over the pkg/skychat/group relocation. Remaining skycoin#3631 items (retention/TTL, metadata reduction) are deferred to the message-persistence + anti-abuse design track.
feat(skychat): group admission control + encryption hardening (continues #3631) + "ask again"
|
Landed on Your PR conflicted only because of the I finished the one remaining checked-but-open item — "ask again" after a decline — end to end (core + RPC + native app HTTP + wasm hook + CLI + HV UI badge/button), so a declined requester can deliberately re-queue while a passive re-ask stays terminal (no poll-flood). The two still-unchecked items — retention/TTL (disappearing messages) and metadata reduction — I deferred rather than block the merge; they fold into a message-persistence + anti-abuse design pass we're planning (bounded store + disk-fill protection). Happy to collaborate on those. This PR can be closed as landed. |
2 participants
Did you run
make format && make check? YesFixes: Part of #3559
Changes:
[ ] retention / disappearing messages — no TTL, no expiry; data accumulates forever and delete-for-everyone is cooperative[ ] metadata reduction — SenderPK and exact timestamps sit in the clear beside the ciphertext, and the federated topology exposes the subscription graphHow to test this PR:
Browser, against three real visors:
then, across the three UIs it prints:
B lands in A's approval queue; approve it and B gets the key with the
approval, not from the link.
should visibly cost a moment (proof-of-work) rather than being instant.
new messages; A's admin panel shows the key epoch advance. Older messages
stay readable for everyone still in.
same invite link — C should be able to admit it.
header should move from "encrypted · keys not exchanged yet" to
"forward secret · key " once both sides have spoken.