Phase B — The device roster: a slot is held by enrolment, per organisation #4
Loading…
Add table
Add a link
Reference in a new issue
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?
Part 2 of 3 of the sessions/device-roster plan (14 Sep 2026). Follows #2.
Model
localStorage, random, no hardware data). Each vault keeps today's keychain id as its install id; identity sessions stay keyed on it, so nothing live moves.enrol:true); background refreshes do not. A full organisation refuses the device (DEVICE_LIMIT) but keeps the membership; the device syncs that organisation once someone removes another device there, or adds this one explicitly. Incumbents are never evicted.POST /api/account/devices(add self),DELETE /api/account/devices/:id(remove; closes that device's sockets for this organisation with 4003),PATCH …/:id {label}. Handshake refuses a device not on the roster with 4003.Checkpoint
roster.test.ts: third device refused at enrolment while the two enrolled stay OPEN connected or not; remove frees, re-add works; same device in two organisations has one row in each; empty id refused;enrol:falsenever enrols; limit shrink keeps incumbents; DELETE closes only that device's sockets for that account; export/import round-tripsdevice.test.ts(one device id across two vaults, two install ids;localStoragefailure falls back),cloud-session.test.ts(reached-but-refused keeps the membership), connections only for enrolled membershipsisEnrolled;enrol:falseignored; remove without closing sockets; device id read from the keychain first; refused membership droppedLanded as
b53a851and deployed 14 September 2026: eu1 applied migration 7 (device-roster); identity unchanged; plugin installed into both local vaults. Checked: roster.test (6), accounts device-limit tests rewritten for the roster, plugin device/cloud-session/membership-shape tests, full multi-vault e2e green (53) with the new roster scenario on case2, 7 mutation checks each fail when inverted, docs updated incl. competition-relay 'How they count a device' and positioning parity. Open: the live check on the user's machine (one device with two vaults; third device refused at the limit, appears after a remove) — needs both vaults reloaded onto the new build; until then the shard refuses their pre-roster sockets at the 30 s backoff, which heals on reload.Live, 14 Sep: after reloading both vaults the roster on eu1 shows one device (Desktop (macOS)) on the user's organisation with Mind Palace and Test Vault 2 listed under it — one slot for two vaults, as designed. Google sign-in from the page confirmed working after
6732f0b(a pre-existing page race found on the way, not part of this phase). Still open: the third-device refuse/remove/add check on real hardware; the same loop is exercised end to end by the roster e2e test and by roster.test.