Record the settings file as verified live #56

New Issue

Closed

opened 2026-08-26 15:51:21 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-26 15:51:21 +00:00

Owner

#55 shipped to the live 0.16.19 today. The README described the feature but not what had been checked against a real server — which is the distinction Known issues / pending QA exists to keep.

New entry covering where settings now live, why x:AccountSettings was not the answer, what deliberately stays device-local and why, the debounce, and the hidden folder — ending in what was actually verified:

Confirmed live on 0.16.19 (2026-08-26): settings set in Chrome came back on a fresh login in Firefox and in an incognito session, both of which start with an empty cache, so each read the account's file rather than anything local.

Both of those start from empty localStorage, so neither could have been reading a local cache. That is the whole claim, and it now holds.

Also updated the Files entry. That verification incidentally exercised part of the 0.16 Files path the section had flagged as still wanting checking on its own terms — finding and creating the folder, creating a node with nodeType, uploading and downloading its blob, and pointing an existing node at a new one. Rename, move, delete and the Files view itself are still unchecked there, and the entry now says so rather than letting the tick spread further than the evidence does.

Two limits are recorded rather than quietly omitted: conflicts are last-write-wins, and a change on one device does not reach another that already has ihasmail open until it signs in again.

Docs only — no code touched.

Merged 2026-08-26 as coffey-labs/ihasmail@d739ad625d

_{Rebuilt from: git history, session transcript.}

#55 shipped to the live 0.16.19 today. The README described the feature but not what had been checked against a real server — which is the distinction *Known issues / pending QA* exists to keep. **New entry** covering where settings now live, why `x:AccountSettings` was not the answer, what deliberately stays device-local and why, the debounce, and the hidden folder — ending in what was actually verified: > **Confirmed live on 0.16.19 (2026-08-26)**: settings set in Chrome came back on a fresh login in Firefox and in an incognito session, both of which start with an empty cache, so each read the account's file rather than anything local. Both of those start from empty `localStorage`, so neither could have been reading a local cache. That is the whole claim, and it now holds. **Also updated the Files entry.** That verification incidentally exercised part of the 0.16 Files path the section had flagged as still wanting checking on its own terms — finding and creating the folder, creating a node with `nodeType`, uploading and downloading its blob, and pointing an existing node at a new one. Rename, move, delete and the Files view itself are still unchecked there, and the entry now says so rather than letting the tick spread further than the evidence does. Two limits are recorded rather than quietly omitted: conflicts are last-write-wins, and a change on one device does not reach another that already has ihasmail open until it signs in again. Docs only — no code touched. **Merged** 2026-08-26 as coffey-labs/ihasmail@d739ad625d2a <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#56