mirror of
https://github.com/bulwarkmail/native.git
synced 2026-10-31 16:06:32 +00:00
fe0facfea5c234d26ebf702dd96539b9a78a1558
Stalwart 1.0 counts every EmailSubmission record of an account against `maxSubmissions` (500 by default), whatever its status or age, and its own purge of old records never runs. The app never removed a record, so after about 500 sends from an account every send, quick reply, read receipt and "Send now" failed with Stalwart's raw "There are too many email submissions, please delete some" error. This ports the webmail fix (48382170). The app now removes the records that can no longer be cancelled. Destroying a record never stops its delivery, but a pending one could no longer be cancelled, so a record EmailSubmission/get reports as pending is never touched: - an immediate send (no undo delay, no schedule) and a read receipt destroy their own record right after the send, riding along with the old-draft cleanup when there is one; only where `urn:stalwart:jmap` is advertised, and never decided by the created undoStatus, which 0.16.10-0.16.16 report as final for held sends - a throttled background prune (`src/api/submissions.ts`) destroys canceled records and final records whose sendAt has passed, going by EmailSubmission/get, in every submission account; it runs at app start, on return to the foreground and after sends and undo - a confirmed cancel (undo, cancel, reschedule, "Send now") destroys the canceled record in a request of its own - an `overQuota` on a submission create prunes at once, on Stalwart walks `EmailSubmission/changes` from "n" for records older than the query's three-day window, retries once, and otherwise throws `SubmissionQuotaError`, shown as a translated explanation in the composer, quick reply, read receipts, the undo bar and the scheduled list; the copy the failed attempt made is removed as before 0.16 never enforces the limit, and destroy never cancels on any version, so the same cleanup runs there unchanged. The undo bar now also says when an undo or "Send now" failed instead of only logging it. The scheduled list reads every page of EmailSubmission/query with calculateTotal; it asked for 200 records, oldest first, so the mail scheduled furthest ahead dropped off once the three-day window held more than that. `SubmissionQuotaError` is added to `jmap-result.ts` as a subclass of `JMAPMethodError`.
Bulwark Mobile
Beta - work in progress. Many features are unfinished or rough. Expect bugs, missing functionality, and breaking changes between releases. Do not rely on this for primary email yet.
React Native (Expo SDK 54) client for Bulwark Webmail - a JMAP-based mail, calendar, and contacts app.
What works today
- Sign in to any JMAP server (e.g. Stalwart)
- Multiple accounts
- Email list, threads, compose
- Calendar (basic)
- Contacts (basic)
- Push notifications via the Bulwark relay - FCM by default, or UnifiedPush (e.g. ntfy) for devices without Google Play services
- In-app sideload updates from GitHub Releases
What's missing or rough
- iOS builds, but push notifications and client certificates are Android-only so far
- S/MIME, plugins, themes - UI stubs only (filters & rules, the vacation responder and file storage are real implementations)
- Calendar editing is partial; contacts editing is basic
- No Play Store distribution yet (sideload APK from Releases); iOS ships via TestFlight
Run locally
npm install
npx expo start
Then press a for Android, i for iOS, or scan the QR with Expo Go.
For release APK builds and signing see docs/android-release.md. For iOS builds and TestFlight distribution see docs/ios-release.md.
License
AGPL-3.0-only. See LICENSE.
Languages
TypeScript
95.9%
Kotlin
2.1%
JavaScript
0.9%
Swift
0.4%
HTML
0.4%
Other
0.2%