From 52299ce8ef87fac33037da5aec90e584df11943f Mon Sep 17 00:00:00 2001 From: John Coffey Date: Thu, 27 Aug 2026 10:18:49 -0700 Subject: [PATCH 1/2] Attach a file that is already in Files Attaching meant uploading, even when the file was sitting in the account already -- picking it off disk again to send the server a copy of what it was holding. The composer can now attach from Files. A blob the account can already see needs no upload at all: an attachment carrying a `blobId` is what a forward produces, so the send path has always known what to do with one. Attaching a large file the server is already storing now costs nothing and takes no time. A file in an account somebody *shared* is different, because blobs belong to the account they were uploaded to and a draft in yours cannot reference one in theirs. Those are fetched and uploaded to your account, and the picker says so before you attach rather than leaving someone wondering why one file was instant and another was not. The picker borrows the Files store, so it browses what Files browses, shared accounts included, and puts the file manager back where it was on the way out -- a detour through somebody's shared folder to find an attachment should not leave Files somewhere else afterwards. Verified against the mock, and worth recording how, because the first attempt measured nothing: `client.upload` uses XMLHttpRequest, since it reports progress, so a counter wrapped around `fetch` sees no uploads whether or not any happen and agrees with you either way. Counted at XHR instead: attaching one's own file issues no upload, and attaching a shared one issues exactly one, to the reader's own account. --- web/src/store/compose.ts | 52 ++++++++++ web/src/views/compose/Composer.tsx | 9 +- web/src/views/compose/FilePicker.tsx | 138 +++++++++++++++++++++++++++ 3 files changed, 198 insertions(+), 1 deletion(-) create mode 100644 web/src/views/compose/FilePicker.tsx diff --git a/web/src/store/compose.ts b/web/src/store/compose.ts index a5cc58a..8330874 100644 --- a/web/src/store/compose.ts +++ b/web/src/store/compose.ts @@ -25,6 +25,15 @@ export interface ComposeAttachment { abort?: AbortController; } +/** A file in Files, enough of it to attach. */ +export interface AttachableFile { + accountId: Id; + name: string; + type: string | null; + size: number | null; + blobId: Id; +} + export type Priority = "high" | "normal" | "low"; export interface Draft { @@ -76,6 +85,8 @@ interface ComposeState { close(key: string, opts?: { discard?: boolean }): Promise; focus(key: string): void; addFiles(key: string, files: File[]): void; + /** Attach files already in Files, by reference where the account allows it. */ + addFromFiles(key: string, nodes: AttachableFile[]): Promise; removeAttachment(key: string, attId: string): void; saveDraft(key: string, opts?: { silent?: boolean }): Promise; send(key: string): Promise; @@ -361,6 +372,47 @@ export const useCompose = create((set, get) => ({ } }, + /* + * Attach something already in Files. + * + * A blob the account can already see needs no upload: an attachment carrying + * a `blobId` is exactly what a forward produces, so the send path already + * knows what to do with one. Attaching a 20 MB file the server is holding + * anyway then costs nothing and takes no time. + * + * A file in an account somebody *shared* is a different matter. Blobs belong + * to the account they were uploaded to, so a draft in your account cannot + * reference one in theirs; it is fetched and uploaded to yours. Slower, and + * unavoidable, but it happens without the reader having to know any of this. + */ + async addFromFiles(key, nodes) { + const accountId = useMail.getState().accountId; + if (!accountId || !nodes.length) return; + const max = client.maxSizeUpload; + const atts: ComposeAttachment[] = nodes.map((n) => ({ + id: uid("a"), + name: n.name, + type: n.type || "application/octet-stream", + size: n.size ?? 0, + blobId: n.accountId === accountId ? n.blobId : null, + progress: n.accountId === accountId ? 100 : 0, + error: (n.size ?? 0) > max ? `Larger than ${Math.round(max / 1048576)} MB limit` : null, + })); + get().update(key, { attachments: [...(get().drafts.find((d) => d.key === key)?.attachments ?? []), ...atts] }); + + for (const [i, a] of atts.entries()) { + if (a.error || a.blobId) continue; + const node = nodes[i]!; + try { + const blob = await client.fetchBlob(node.accountId, node.blobId, a.type); + const up = await client.upload(accountId, blob, { type: a.type }); + patchAtt(key, a.id, { blobId: up.blobId, progress: 100, size: up.size || a.size }, set); + } catch (err) { + patchAtt(key, a.id, { error: (err as Error).message || "Could not attach" }, set); + } + } + }, + removeAttachment(key, attId) { const d = get().drafts.find((x) => x.key === key); const a = d?.attachments.find((x) => x.id === attId); diff --git a/web/src/views/compose/Composer.tsx b/web/src/views/compose/Composer.tsx index 4126d9d..bb368a3 100644 --- a/web/src/views/compose/Composer.tsx +++ b/web/src/views/compose/Composer.tsx @@ -1,5 +1,5 @@ import { useCallback, useEffect, useMemo, useRef, useState } from "react"; -import { AlertTriangle, ChevronDown, FileText, Maximize2, Minimize2, Minus, MoreVertical, Paperclip, Send, Trash2, X, Type, Clock, CheckCheck, ChevronsDown } from "lucide-react"; +import { AlertTriangle, ChevronDown, FileText, FolderOpen, Maximize2, Minimize2, Minus, MoreVertical, Paperclip, Send, Trash2, X, Type, Clock, CheckCheck, ChevronsDown } from "lucide-react"; import { useCompose, type Draft } from "@/store/compose"; import { useMail } from "@/store/mail"; import { useSettings } from "@/store/settings"; @@ -12,6 +12,8 @@ import { formatSize, formatRelative } from "@/lib/format"; import { htmlToText, textToHtml } from "@/lib/text"; import { isValidEmail } from "@/lib/address"; import { attachmentIcon } from "../mail/MessageView"; +import { FilePicker } from "./FilePicker"; +import { useFiles } from "@/store/files"; import { keyboard } from "@/lib/keyboard"; import { useIsMobile } from "@/ui/misc"; import { toast } from "@/ui/toast"; @@ -25,6 +27,9 @@ export function Composer({ draft }: { draft: Draft }) { const send = useCompose((s) => s.send); const saveDraft = useCompose((s) => s.saveDraft); const addFiles = useCompose((s) => s.addFiles); + const addFromFiles = useCompose((s) => s.addFromFiles); + const filesAvailable = useFiles((s) => s.available); + const [pickerOpen, setPickerOpen] = useState(false); const removeAttachment = useCompose((s) => s.removeAttachment); const setIdentity = useCompose((s) => s.setIdentity); const insertTemplate = useCompose((s) => s.insertTemplate); @@ -239,11 +244,13 @@ export function Composer({ draft }: { draft: Draft }) { } label={`Undo window: ${settings.undoSendSeconds}s`} onClick={() => updateSettings({ undoSendSeconds: settings.undoSendSeconds >= 30 ? 0 : settings.undoSendSeconds + 5 })} /> {canSchedule && { sendMenu.close(); setScheduleOpen(true); }} />} + {pickerOpen && void addFromFiles(key, picked)} onClose={() => setPickerOpen(false)} />} {canSchedule && scheduleOpen && ( setScheduleOpen(false)} onPick={scheduleFor} /> )} + {filesAvailable && } { const files = Array.from(e.target.files ?? []); if (files.length) addFiles(key, files); e.target.value = ""; }} /> {d.format === "html" && } {settings.templates.length > 0 && } diff --git a/web/src/views/compose/FilePicker.tsx b/web/src/views/compose/FilePicker.tsx new file mode 100644 index 0000000..c1d96d3 --- /dev/null +++ b/web/src/views/compose/FilePicker.tsx @@ -0,0 +1,138 @@ +import { useEffect, useState } from "react"; +import { ChevronRight, File as FileIcon, Folder, HardDrive, Users } from "lucide-react"; +import { Dialog } from "@/ui/dialog"; +import { Spinner } from "@/ui/misc"; +import { useFiles } from "@/store/files"; +import type { AttachableFile } from "@/store/compose"; +import type { FileNode } from "@/jmap/types"; +import { formatSize } from "@/lib/format"; + +/** + * Pick something already in Files to attach. + * + * Browsing is the store's, so this shows the same folders the Files view does, + * shared accounts included -- a file somebody shared with you is a file you can + * send on, and having to download it first only to upload it again would be + * the sort of detour the rest of this avoids. + * + * It borrows the Files store rather than keeping its own copy, which means + * opening the picker moves where Files is browsing. Closing it puts that back: + * a detour through somebody's shared folder to find an attachment should not + * leave the file manager somewhere else afterwards. + */ +export function FilePicker({ onPick, onClose }: { onPick: (files: AttachableFile[]) => void; onClose: () => void }) { + const files = useFiles(); + const [cur, setCur] = useState(null); + const [picked, setPicked] = useState>({}); + const [returnTo] = useState(() => files.accountId); + + useEffect(() => { + void files.loadChildren(cur); + // eslint-disable-next-line react-hooks/exhaustive-deps + }, [cur, files.accountId]); + + const close = () => { + if (files.accountId !== returnTo) files.openAccount(returnTo); + onClose(); + }; + + const openAccount = (accountId: string | null) => { + files.openAccount(accountId); + setCur(null); + setPicked({}); + }; + + const nodes = (files.children[cur ?? "root"] ?? []).map((id) => files.nodes[id]).filter((n): n is FileNode => Boolean(n)); + const path = files.pathTo(cur); + const chosen = Object.values(picked); + const viewingShare = files.accountId !== files.ownAccountId; + + return ( + + + + + } + > + {files.sharedAccounts.length > 0 && ( +
+ + {files.sharedAccounts.map((a) => ( + + ))} +
+ )} + +
+ + {path.map((n) => ( + + + + + ))} +
+ + {files.loading && !nodes.length ? ( + + ) : !nodes.length ? ( +

This folder is empty.

+ ) : ( + nodes.map((n) => + n.nodeType === "directory" ? ( + + ) : ( + + ), + ) + )} + + {viewingShare && chosen.length > 0 && ( + // Blobs belong to the account holding them, so one from a share has to + // be copied into yours before a draft can reference it. Worth saying, + // because it is the difference between instant and a wait. +

Shared files are copied to your account when attached.

+ )} + + ); +} From 1e2db9557734ddada41000b8acc7a1ea74928c4c Mon Sep 17 00:00:00 2001 From: John Coffey Date: Thu, 27 Aug 2026 10:28:05 -0700 Subject: [PATCH 2/2] Stop offering to share mail folders, and let a share be removed Sharing a mail folder does nothing. `Mailbox/set` takes the `shareWith` map, `Mailbox/get` reads it back, and the folder never appears for the account it was shared with -- confirmed on the live 0.16.19 with a folder shared read-only to another account on the same server, which never saw it. Stalwart's sharing documentation lists calendars, address books and file storage; mail folders are not among them. Nothing anywhere reports a failure, so a client that trusts what it reads back shows the share as live for ever, which is what happened. The entry point is withdrawn. Address book sharing goes with it on a report that it behaved the same way -- not reproduced, and contradicted by Stalwart's own docs, so that one is expected back; it is out because offering a share nobody can verify was worse than the gap. Files and calendars are untouched. Removing a share was impossible, for a reason worth writing down. The dialog rendered the list of who a thing was shared with *inside* the branch that runs when the directory has principals to offer. A server with `allowDirectoryQueries` off returns none -- that is the default, and it is how these shares came to be made in the first place -- so the dialog showed one line of hint and nothing else. The share was there, and there was no way to see it, let alone remove it. The list is now rendered whatever the directory says; only the control for adding somebody new depends on having somebody to add. So the withdrawn entry points do not strand what they created: a folder or book already shared still offers "Stop sharing", which is the one thing you want when the share is invisible everywhere else. The API was never the problem, which is worth recording since it was the first guess: `shareWith: null` is accepted and clears the map, tested against the live server on the stuck folder, which is now unshared. --- KNOWN-ISSUES.md | 2 ++ ROADMAP.md | 1 + web/src/views/contacts/ContactsView.tsx | 9 +++++++- web/src/views/mail/MailboxTree.tsx | 9 +++++++- web/src/views/settings/FoldersSettings.tsx | 4 ++-- web/src/views/settings/ShareDialog.tsx | 24 ++++++++++++++-------- 6 files changed, 37 insertions(+), 12 deletions(-) diff --git a/KNOWN-ISSUES.md b/KNOWN-ISSUES.md index 7231267..7d5880d 100644 --- a/KNOWN-ISSUES.md +++ b/KNOWN-ISSUES.md @@ -22,6 +22,8 @@ works the same way — and dropped where 0.15 was the whole subject. Support for [`stalwart-0.15-support`](https://github.com/LINUXexpert-org/ihasmail/releases/tag/stalwart-0.15-support). - **Delete all spam destroys, and does not pass through Deleted Items** — this is the point of the feature and the thing worth checking on a real server, since a folder that empties into another folder has solved nothing. `Email/set destroy`, walked a page at a time so it survives `maxObjectsInSet` the way emptying Deleted Items already had to. **Confirmed live on 0.16.19 (2026-08-26)**: Junk Mail emptied and Deleted Items stayed empty afterwards. There is no undo, which is why all three entry points share one dialog that says so. Only Deleted Items and Junk Mail can be emptied this way, enforced in the store rather than only hidden in the menus. +- **Sharing a mail folder is accepted and does nothing.** `Mailbox/set` with a `shareWith` map is applied, `Mailbox/get` reads it back, and the folder never appears for the account it was shared with — **confirmed live on 0.16.19 (2026-08-27)** with a folder shared read-only to another account on the same server, which never saw it. Stalwart's own sharing documentation lists calendars, address books and file storage; mail folders are not among them. Nothing reports a failure at any point, which is the whole problem: the share is stored, so a client that trusts what it reads back shows it as live for ever. The entry point is withdrawn. A folder that is *already* shared still offers **Stop sharing**, because a share nobody can see is exactly the one you want to be able to clear, and there is no other way to. File sharing is unaffected and works end to end. +- **Address book sharing is withdrawn without being disproved.** It was taken out alongside mail folders on 2026-08-27, on a report that it behaved the same way, and that report has not been reproduced: there was no shared address book left on the account by the time anyone looked. Stalwart documents address books as shareable, so the expectation is that this one *does* work and the entry point should come back — it is out because offering a share nobody can verify was worse than the gap. Testing it needs two accounts and someone to confirm the book arrives. **Stop sharing** remains for a book already shared. - **Read receipts are built here, not by the server** — JMAP has an extension for them, [RFC 9007](https://www.rfc-editor.org/rfc/rfc9007.html)'s `MDN/send`, and Stalwart does not implement it: `urn:ietf:params:jmap:mdn` is not among its capabilities. So ihasmail assembles the `multipart/report` itself and sends it the long way round — raw MIME uploaded as a blob, `Email/import`, then `EmailSubmission` — which is also why the receipt lands in Sent, where it honestly belongs. Non-ASCII parts are base64 rather than `8bit`, so nothing depends on 8BITMIME surviving every hop. There is deliberately no "always send" setting: a receipt confirms to whoever asked that the address is live and when it was read, to an address of the sender's choosing, so each one is a decision. Verified against the mock end to end (upload, import, submit, `$mdnsent`), and **confirmed live on 0.16.19 (2026-08-26)**: a receipt asked for by a real sender was assembled, uploaded, imported and submitted, landed in Sent, and set `$mdnsent` so a second look does not offer to send another. - **Where 0.16 advertises `urn:stalwart:jmap`** — not where a JMAP client would look, and this now decides whether a sign-in is allowed at all. Stalwart builds the session-level `capabilities` from a fixed list (`Session::new`, plus WebSocket) that has never contained this capability, in any 0.16.x from 0.16.0 to 0.16.19. It hands it out per-account instead, so it appears in `primaryAccounts` and in each account's `accountCapabilities`. ihasmail tested for it in `capabilities` alone, which made every real 0.16 server read as older than 0.16 — and that one check drove three things: self-service credentials fell back to `POST /api/account/auth`, which 0.16 removed, so password changes, 2FA and app passwords all failed with "this mail server does not offer self-service credential management"; About reported the wrong generation; and Files took the older code path. It now looks in all three places, and is covered by tests on each. Worth restating plainly, because the stakes went up when 0.15 support was dropped: there is no longer a fallback path for this check to be wrong *into*. Getting it wrong now refuses every sign-in against a perfectly good server — a loud failure rather than a quiet misrouting, which is the trade the removal was making. - **HTML signatures** — Stalwart caps a signature at 2047 **bytes** (`value.len() < 2048` on a Rust string, so UTF-8 bytes, not characters). ihasmail compacts pasted HTML, moves images to Files and, if still too large, keeps the full signature in Files behind a short marker; other clients see a text fallback. Confirmed live on 0.15.5 (2026-08-24): oversized, non-ASCII and inline-image signatures all save, and a test message arrived intact at Gmail with the logo inline. diff --git a/ROADMAP.md b/ROADMAP.md index 68a2758..8e78213 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -6,6 +6,7 @@ rest is here because the answer is "no", not "not yet". See [KNOWN-ISSUES.md](KNOWN-ISSUES.md) for what is built but worth knowing about. +- **Sharing a mail folder.** Stalwart stores the share and never delivers it; see [KNOWN-ISSUES.md](KNOWN-ISSUES.md). Withdrawn until the server does something with it. **Address book sharing** is withdrawn with it on a report that has not been reproduced, and is expected back — Stalwart documents it as supported. Sharing files and calendars is unaffected. - Snooze (nothing in JMAP or Stalwart supports it, and ihasmail never stores a password, so nothing could act on a mailbox while you are away) - Translations (strings are English-only for now) - **Two-factor sign-in.** Today an account with 2FA must use an app password (see [Quick start](README.md#quick-start-docker)), and Settings › Security offers no way to switch 2FA *on* — only off, for an account that already has it. Supporting a TOTP code directly means implementing OAuth: Stalwart offers the authorization-code and device flows and no password grant, so ihasmail would hand sign-in to Stalwart's own login and come back with a token. That is a better security posture than the sealed password it holds now — a refresh token rather than a credential — but it replaces ihasmail's own sign-in page for those users and may need an OAuth client registered. Reported as [#75](https://github.com/LINUXexpert-org/ihasmail/issues/75) diff --git a/web/src/views/contacts/ContactsView.tsx b/web/src/views/contacts/ContactsView.tsx index 27c201b..fab0e24 100644 --- a/web/src/views/contacts/ContactsView.tsx +++ b/web/src/views/contacts/ContactsView.tsx @@ -105,7 +105,14 @@ export function ContactsView({ id }: { id?: string }) { {menuBook && ( <> } label="Rename" onClick={async () => { const n = await promptDialog({ title: "Rename address book", defaultValue: menuBook.name }); if (n?.trim()) void contacts.updateBook(menuBook.id, { name: n.trim() }).catch((err) => toast.error((err as Error).message)); }} /> - } label="Share…" onClick={() => setShare(menuBook)} /> + {/* Withdrawn alongside mail folder sharing, on a report that it + behaved the same way -- which was never reproduced, and which + Stalwart's own docs contradict, since address books are listed + as shareable. Expected back once two accounts have confirmed a + book actually arrives. Clearing one still works. */} + {Object.keys(menuBook.shareWith ?? {}).length > 0 && ( + } label="Stop sharing" onClick={() => setShare(menuBook)} /> + )} } label={menuBook.isDefault ? "Default book" : "Make default"} disabled={menuBook.isDefault} onClick={() => void contacts.updateBook(menuBook.id, { isDefault: true } as Partial).catch((err) => toast.error((err as Error).message))} /> } label="Delete" disabled={!menuBook.myRights.mayDelete} onClick={async () => { if (await confirmDialog({ title: `Delete “${menuBook.name}”?`, message: "All contacts in it will be deleted.", confirmLabel: "Delete", danger: true })) void contacts.destroyBook(menuBook.id).catch((err) => toast.error((err as Error).message)); }} /> diff --git a/web/src/views/mail/MailboxTree.tsx b/web/src/views/mail/MailboxTree.tsx index 28f1fd0..436f8ce 100644 --- a/web/src/views/mail/MailboxTree.tsx +++ b/web/src/views/mail/MailboxTree.tsx @@ -292,6 +292,7 @@ function FolderRow({ mailbox: m, label, depth, hasChildren, open, hiddenUnread, } function MailboxMenu({ mailbox: m, onClose, onCreateChild, onShare }: { mailbox: Mailbox; onClose: () => void; onCreateChild: () => void; onShare: () => void }) { + const shared = Object.keys(m.shareWith ?? {}).length > 0; const [, navigate] = useLocation(); const colors = useSettings((s) => s.settings.folderColors); const update = useSettings((s) => s.update); @@ -354,7 +355,13 @@ function MailboxMenu({ mailbox: m, onClose, onCreateChild, onShare }: { mailbox: } label="New subfolder" onClick={onCreateChild} disabled={!m.myRights.mayCreateChild} /> } label="Rename" onClick={() => void rename()} disabled={isSpecial || !m.myRights.mayRename} /> : } label={m.isSubscribed ? "Hide from list" : "Show in list"} onClick={() => void useMail.getState().updateMailbox(m.id, { isSubscribed: !m.isSubscribed })} disabled={m.role === "inbox"} /> - } label="Share…" onClick={onShare} /> + {/* Sharing a mail folder is withdrawn, not removed: Stalwart accepts and + stores the share, and it never reaches the other account -- its own + docs list calendars, address books and files as shareable and not mail + folders. Offering it produced shares that looked real and did nothing. + One that already exists can still be cleared here, which is the only + reason this entry survives at all. */} + {shared && } label="Stop sharing" onClick={onShare} />} Colour
diff --git a/web/src/views/settings/FoldersSettings.tsx b/web/src/views/settings/FoldersSettings.tsx index cc494e1..266a3a6 100644 --- a/web/src/views/settings/FoldersSettings.tsx +++ b/web/src/views/settings/FoldersSettings.tsx @@ -34,7 +34,7 @@ export function FoldersSettings() { return (

Folders

-

Create, rename, hide and share folders. {q && q.hardLimit ? `Storage: ${formatSize(q.used)} of ${formatSize(q.hardLimit)} used.` : ""}

+

Create, rename and hide folders. {q && q.hardLimit ? `Storage: ${formatSize(q.used)} of ${formatSize(q.hardLimit)} used.` : ""}

@@ -48,7 +48,7 @@ export function FoldersSettings() {
- + {Object.keys(m.shareWith ?? {}).length > 0 && }
diff --git a/web/src/views/settings/ShareDialog.tsx b/web/src/views/settings/ShareDialog.tsx index 036f0c6..e7738dd 100644 --- a/web/src/views/settings/ShareDialog.tsx +++ b/web/src/views/settings/ShareDialog.tsx @@ -104,9 +104,17 @@ export function ShareDialog({ kind, id, name, shareWith, onClose }: { kind: Kind return ( }> - {!principals.length ? ( -

No other users found in the directory, or sharing is not enabled on this server.

- ) : ( + {/* The list of who it is shared with is rendered whether or not anybody + can be *added*. It used to sit inside the branch below, so a server + with directory queries switched off -- which is the default, and which + returns no principals -- showed nothing but the hint, and an existing + share could not be seen, let alone removed. */} + {!principals.length && ( +

+ No other users found in the directory, so nobody new can be added. Sharing already in place is listed below and can still be removed. +

+ )} + {principals.length > 0 && ( <>
FolderMessagesUnread