Write down everything ihasmail does #140

New Issue

Open

opened 2026-08-31 06:02:35 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-31 06:02:35 +00:00

Owner

Adds FEATURES.md — the full inventory of what ihasmail does, written from the code rather than from the site copy — and links it from the README's doc table beside ROADMAP and KNOWN-ISSUES.

The feature list lived in three places that each answered a different question. The site sells it, the docs teach the parts that surprise people, and the README summarises both in a paragraph. Nothing said, in one place and at full detail, what is actually built, so evaluating ihasmail meant reading the source — and a feature that quietly stopped working had nowhere to be contradicted.

What is in it

Capability matrix — every JMAP capability, what it powers, and what happens when it is missing, including the two that are advertised per-account rather than session-level (urn:stalwart:jmap and submission's futureRelease).
Mail — layout, the virtualised list, actions and undo, folders, labels, the search operators as the parser actually reads them (including which forms negate and how dates and sizes parse), reading and the sanitiser, remote images and the proxy, conversations, the invite/vCard/address cards, read receipts and why there is no "always", the composer, and undo send versus scheduled send.
Calendar — views, the three sidebar groups, editor fields, recurrence, categories, iTIP and free/busy, and a straight account of per-occurrence editing: the rejected/inherited/applied split and the id renumbering behind it.
Contacts, Files, Filters (the full test and action tables), Sharing, Settings (synced versus device keys, section by section), locale and dates, themes.
Live updates, Platform (PWA, mailto, deep links, the shortcut set), Security and privacy (session sealing, the device-trust table, headers, CSRF, rate limits, the SSRF rules, self-service credentials and the 2FA position), Running it (immutable mode, the environment table, ops, the mock).
What it does not do, condensed, pointing at ROADMAP.md.

Where a behaviour is odd it says why, because the reason is usually the stateless constraint.

Noticed while writing it

docs/using.md on the site still says per-occurrence recurring overrides are unsupported and lists that under "What ihasmail does not do". dd8998f built single-occurrence edit and delete. FEATURES.md describes the current behaviour; the docs need the same edit, in the other repo.
web/src/views/settings/GeneralSettings.tsx:49 still leads with "Settings are stored in this browser", which predates settingsSync.

Documentation only — no code changes.

Merged 2026-08-30 as coffey-labs/ihasmail@c1c448b94d

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

Adds `FEATURES.md` — the full inventory of what ihasmail does, written from the code rather than from the site copy — and links it from the README's doc table beside ROADMAP and KNOWN-ISSUES. The feature list lived in three places that each answered a different question. The site sells it, the docs teach the parts that surprise people, and the README summarises both in a paragraph. Nothing said, in one place and at full detail, what is actually built, so evaluating ihasmail meant reading the source — and a feature that quietly stopped working had nowhere to be contradicted. ## What is in it - **Capability matrix** — every JMAP capability, what it powers, and what happens when it is missing, including the two that are advertised per-account rather than session-level (`urn:stalwart:jmap` and submission's `futureRelease`). - **Mail** — layout, the virtualised list, actions and undo, folders, labels, the search operators as the parser actually reads them (including which forms negate and how dates and sizes parse), reading and the sanitiser, remote images and the proxy, conversations, the invite/vCard/address cards, read receipts and why there is no "always", the composer, and undo send versus scheduled send. - **Calendar** — views, the three sidebar groups, editor fields, recurrence, categories, iTIP and free/busy, and a straight account of per-occurrence editing: the rejected/inherited/applied split and the id renumbering behind it. - **Contacts, Files, Filters** (the full test and action tables), **Sharing**, **Settings** (synced versus device keys, section by section), locale and dates, themes. - **Live updates**, **Platform** (PWA, mailto, deep links, the shortcut set), **Security and privacy** (session sealing, the device-trust table, headers, CSRF, rate limits, the SSRF rules, self-service credentials and the 2FA position), **Running it** (immutable mode, the environment table, ops, the mock). - **What it does not do**, condensed, pointing at ROADMAP.md. Where a behaviour is odd it says why, because the reason is usually the stateless constraint. ## Noticed while writing it - `docs/using.md` on the site still says per-occurrence recurring overrides are unsupported and lists that under "What ihasmail does not do". `dd8998f` built single-occurrence edit and delete. FEATURES.md describes the current behaviour; the docs need the same edit, in the other repo. - `web/src/views/settings/GeneralSettings.tsx:49` still leads with "Settings are stored in this browser", which predates `settingsSync`. Documentation only — no code changes. **Merged** 2026-08-30 as coffey-labs/ihasmail@c1c448b94d3d <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#140