@remit/data-ports 0.0.82 → 0.0.84

package/dist/folder-role.js

@@ -0,0 +1,276 @@
+import { AccountSettingName, CanonicalMailboxRole, FolderAppointmentSource, MailboxSpecialUse, } from "@remit/domain-enums";
+import { composeSettingName, SETTING_NAME_SEPARATOR, } from "./account-settings.js";
+import { resolveMailboxByLeafName, } from "./mailbox-name.js";
+/** The fixed anchor set, in the RFC's canonical display order. */
+export const CANONICAL_ROLES = Object.values(CanonicalMailboxRole);
+const isCanonicalRole = (value) => CANONICAL_ROLES.includes(value);
+/**
+ * The stored `AccountSetting` name holding one role's appointment. Composed
+ * here rather than at either reader, so the backend that writes it and the
+ * repository that reads it can never disagree about the key.
+ */
+export const composeFolderRoleAppointmentName = (accountId, role) => composeSettingName(AccountSettingName.FolderRoleAppointment, `${accountId}${SETTING_NAME_SEPARATOR}${role}`);
+/**
+ * The stored `AccountSetting` name holding the path one role's appointed
+ * mailbox had at the moment it was appointed. A sibling row rather than a field
+ * on the appointment, so "never read by resolution" is structural: the
+ * repository composes only the appointment name and cannot reach this one.
+ */
+export const composeFolderRoleAppointmentLabelName = (accountId, role) => composeSettingName(AccountSettingName.FolderRoleAppointmentLabel, `${accountId}${SETTING_NAME_SEPARATOR}${role}`);
+const parseFolderRoleTarget = (base, name) => {
+    const [candidate, ...rest] = name.split(SETTING_NAME_SEPARATOR);
+    if (candidate !== base)
+        return undefined;
+    const role = rest[rest.length - 1];
+    const accountId = rest.slice(0, -1).join(SETTING_NAME_SEPARATOR);
+    if (!accountId || !role || !isCanonicalRole(role))
+        return undefined;
+    return { accountId, role };
+};
+/**
+ * Split a stored appointment name back into its two-part target. Unlike the
+ * single-target composites (`MailboxRole#<id>`), this setting composes two ids
+ * after the base, so it parses the suffix itself rather than reusing
+ * `targetIdOf`.
+ */
+export const parseFolderRoleAppointmentName = (name) => parseFolderRoleTarget(AccountSettingName.FolderRoleAppointment, name);
+/**
+ * The label row's counterpart, so the config-wide settings batch can recover
+ * the recorded path for a role the same way it recovers the appointment.
+ */
+export const parseFolderRoleAppointmentLabelName = (name) => parseFolderRoleTarget(AccountSettingName.FolderRoleAppointmentLabel, name);
+/**
+ * RFC 6154 SPECIAL-USE flag per role. Inbox has no SPECIAL-USE flag (RFC 3501
+ * reserves the name itself); a role with no entry here is matched by name hint
+ * only.
+ */
+export const ROLE_SPECIAL_USE = {
+    [CanonicalMailboxRole.Drafts]: MailboxSpecialUse.Drafts,
+    [CanonicalMailboxRole.Sent]: MailboxSpecialUse.Sent,
+    [CanonicalMailboxRole.Archive]: MailboxSpecialUse.Archive,
+    [CanonicalMailboxRole.Junk]: MailboxSpecialUse.Junk,
+    [CanonicalMailboxRole.Trash]: MailboxSpecialUse.Trash,
+    [CanonicalMailboxRole.All]: MailboxSpecialUse.All,
+    [CanonicalMailboxRole.Flagged]: MailboxSpecialUse.Flagged,
+};
+/**
+ * Weak name hints, ordered best-first and lower case: the last resort for a
+ * provider that advertises no SPECIAL-USE and whose user has appointed
+ * nothing. Deliberately small — a guess that seeds a proposal, never a
+ * substitute for server truth or for what the user chose.
+ */
+export const ROLE_NAME_HINTS = {
+    [CanonicalMailboxRole.Drafts]: ["drafts", "draft", "concepten"],
+    [CanonicalMailboxRole.Sent]: [
+        "sent",
+        "sent items",
+        "sent messages",
+        "sent mail",
+    ],
+    [CanonicalMailboxRole.Archive]: ["archive", "archives", "all mail"],
+    [CanonicalMailboxRole.Junk]: [
+        "junk",
+        "spam",
+        "junk e-mail",
+        "junk email",
+        "bulk mail",
+    ],
+    // No bare "deleted" and no "bin": both are ordinary folder names a user
+    // keeps mail in, and a wrong guess here files deletes into a folder the
+    // user never meant as Trash. Gmail's en-GB "Bin" and its "[Gmail]/Trash"
+    // both advertise \Trash, so the flag already covers them (#837).
+    [CanonicalMailboxRole.Trash]: ["trash", "deleted items", "deleted messages"],
+    [CanonicalMailboxRole.All]: ["all mail", "all"],
+};
+/**
+ * The role a folder's own leaf name is most conventionally for. A name that
+ * several roles list goes to the role that ranks it highest, so `All Mail` is
+ * an All folder rather than a lookalike of Archive.
+ *
+ * `name` is the leaf segment, lower case.
+ */
+export const roleForFolderName = (name) => {
+    let best;
+    for (const role of CANONICAL_ROLES) {
+        const rank = ROLE_NAME_HINTS[role]?.indexOf(name) ?? -1;
+        if (rank < 0)
+            continue;
+        if (!best || rank < best.rank)
+            best = { role, rank };
+    }
+    return best?.role;
+};
+/**
+ * Whether the mailbox sweep would read a folder with this leaf name as a
+ * duplicate of a role's canonical folder — and so delete its row, and under D8
+ * the mail in it, as soon as another folder carries the role's SPECIAL-USE
+ * flag. It is the sweep's own predicate, so a rename refused on it and a folder
+ * reaped by it can never disagree (docs/architecture/folder-rename-and-delete.md
+ * D5).
+ *
+ * A role with no flag to be a duplicate of is not reserved: nothing reaps a
+ * folder for it.
+ */
+export const isReservedFolderName = (name) => {
+    const role = roleForFolderName(name.toLowerCase());
+    return role !== undefined && ROLE_SPECIAL_USE[role] !== undefined;
+};
+/**
+ * The pane where a user appoints a folder to a role, named as it is labelled.
+ * Every refusal that asks for an appointment points here, in one wording — the
+ * settings screen is titled "Folder roles", and copies of this sentence had
+ * already drifted to "Folders".
+ */
+export const FOLDER_ROLES_SETTINGS_PATH = "Settings › Folder roles";
+/**
+ * Why an operation that files or destroys mail was refused. A delete, an
+ * Empty Trash and the count the handler reports before one all act on the
+ * folder the user appointed or the server flagged, and all refuse in these
+ * words — one sentence, so two surfaces cannot tell a user two things about
+ * one account.
+ */
+export const NO_TRASH_FOLDER_REASON = `This account has no Trash folder, so nothing was deleted. Appoint one under ${FOLDER_ROLES_SETTINGS_PATH}, then try again.`;
+/**
+ * The folder somebody chose as this account's Trash is no longer on the mail
+ * server. Reader will not quietly file mail into whatever it would have picked
+ * had nobody chosen: the user's choice went missing and only they can replace
+ * it.
+ */
+export const STALE_TRASH_FOLDER_REASON = `The folder appointed as this account's Trash is no longer on the mail server, so nothing was deleted. Appoint one under ${FOLDER_ROLES_SETTINGS_PATH}, then try again.`;
+/**
+ * A folder matches the Trash name hint and nothing else — enough to file a
+ * delete somewhere retrievable, never enough to erase what is already in it.
+ * Emptying that folder and deleting a message already inside it both land here
+ * (#876), so the sentence names neither verb: "nothing was deleted" is true of
+ * both, the way its two siblings above are.
+ */
+export const UNCONFIRMED_TRASH_FOLDER_REASON = `Nobody has confirmed which folder is this account's Trash, so nothing was deleted. Appoint one under ${FOLDER_ROLES_SETTINGS_PATH}, then try again.`;
+const resolveWithoutAppointment = (role, mailboxes) => {
+    const specialUse = ROLE_SPECIAL_USE[role];
+    if (specialUse) {
+        const flagged = mailboxes.find((m) => m.specialUse?.includes(specialUse));
+        if (flagged)
+            return { kind: "flagged", mailbox: flagged };
+    }
+    if (role === CanonicalMailboxRole.Inbox) {
+        const inbox = mailboxes.find((m) => m.fullPath.toUpperCase() === "INBOX");
+        return inbox ? { kind: "reserved", mailbox: inbox } : { kind: "none" };
+    }
+    const hints = ROLE_NAME_HINTS[role];
+    if (!hints)
+        return { kind: "none" };
+    const proposed = resolveMailboxByLeafName(mailboxes, hints);
+    return proposed ? { kind: "proposed", mailbox: proposed } : { kind: "none" };
+};
+/**
+ * The single mailbox that holds a canonical role for an account (RFC 032
+ * exclusive-folder-appointment, #976), in one precedence order every caller
+ * shares:
+ *
+ * 1. the mailbox the user appointed;
+ * 2. the server's own SPECIAL-USE flag (RFC 6154) — language-independent truth;
+ * 3. the reserved `INBOX` name, for the Inbox role only (RFC 3501);
+ * 4. a conventional name, matched on the folder's own leaf segment so it
+ *    resolves at any depth under any prefix.
+ *
+ * The last of those is a guess: a folder named `Deleted` is not evidence that
+ * the user means it as Trash. Use it only where being wrong misfiles a message
+ * a user can move back — never where it destroys mail.
+ */
+export const resolveRoleForAccount = (role, mailboxes, appointedMailboxId) => {
+    if (!appointedMailboxId)
+        return resolveWithoutAppointment(role, mailboxes);
+    const appointed = mailboxes.find((m) => m.mailboxId === appointedMailboxId);
+    if (appointed)
+        return { kind: "appointed", mailbox: appointed };
+    return {
+        kind: "appointment_stale",
+        appointedMailboxId,
+        fallback: resolveWithoutAppointment(role, mailboxes),
+    };
+};
+/**
+ * The Trash folder a verb at this assurance level may act on, or which of the
+ * three reasons stops it. One switch: the delete, the expunge and the count
+ * reported before one all decide here, so no two of them can answer a user
+ * differently about the same account.
+ */
+export const trashMailboxAt = (resolution, level) => {
+    switch (resolution.kind) {
+        case "appointed":
+        case "flagged":
+            return { allowed: true, mailbox: resolution.mailbox };
+        case "proposed":
+            return level === "resolved"
+                ? { allowed: true, mailbox: resolution.mailbox }
+                : { allowed: false, reason: "unconfirmed" };
+        case "appointment_stale":
+            return { allowed: false, reason: "stale" };
+        default:
+            return { allowed: false, reason: "none" };
+    }
+};
+export const meetsTrashAssurance = (resolution, level) => trashMailboxAt(resolution, level).allowed;
+/** The resolution each reported source came from (`toFolderAppointment`). */
+const RESOLUTION_FOR_SOURCE = {
+    [FolderAppointmentSource.Appointed]: { kind: "appointed", mailbox: null },
+    [FolderAppointmentSource.Flagged]: { kind: "flagged", mailbox: null },
+    [FolderAppointmentSource.Reserved]: { kind: "reserved", mailbox: null },
+    [FolderAppointmentSource.Proposed]: { kind: "proposed", mailbox: null },
+    [FolderAppointmentSource.Stale]: {
+        kind: "appointment_stale",
+        appointedMailboxId: "",
+        fallback: { kind: "none" },
+    },
+    [FolderAppointmentSource.None]: { kind: "none" },
+};
+/**
+ * The same gate as {@link trashMailboxAt}, asked of the source `/config`
+ * reports rather than of the resolution the server computed — so a client can
+ * word a delete from the answer the service will give it.
+ *
+ * It runs that switch rather than restating it. A hand-written mirror gets
+ * `Reserved` wrong: it reads as designated, and the gate accepts only the user's
+ * appointment and the server's flag.
+ */
+export const trashSourceMeetsAssurance = (source, level) => meetsTrashAssurance(RESOLUTION_FOR_SOURCE[source], level);
+/**
+ * The mailbox a role is CONFIRMED to hold: the one the user appointed, or the
+ * one the server flagged (RFC 6154). No name guessing — `null` here means
+ * nobody has said which folder this is, only that a folder happens to be named
+ * something plausible. An operation that destroys mail resolves through this
+ * and refuses when it comes back empty; `resolveMailboxForRole` adds the guess
+ * on top for the operations where being wrong only misfiles a message.
+ *
+ * An appointment naming a mailbox this account does not hold — deleted,
+ * renamed, or carried in from elsewhere — is stale, and answers `null` here
+ * too: the fallback is the folder the user did not choose, which is fine to
+ * file mail into and no basis at all for destroying it.
+ */
+export const resolveConfirmedMailboxForRole = (role, mailboxes, appointedMailboxId) => {
+    const resolution = resolveRoleForAccount(role, mailboxes, appointedMailboxId);
+    switch (resolution.kind) {
+        case "appointed":
+        case "flagged":
+        case "reserved":
+            return resolution.mailbox;
+        default:
+            return null;
+    }
+};
+/**
+ * The role's mailbox including the name guess: `null` only when nothing
+ * matches at all, so the caller says the role has no folder rather than picking
+ * one. A stale appointment answers with its fallback — every role but Trash
+ * files mail on this read, and refusing them all would be a behaviour change
+ * with no surface to explain it.
+ *
+ * Built on `resolveRoleForAccount` directly, never on the confirmed adapter: a
+ * stale appointment must still reach the `\Sent` flag here, not fall past it
+ * into a folder that merely reads like one.
+ */
+export const resolveMailboxForRole = (role, mailboxes, appointedMailboxId) => {
+    const resolution = resolveRoleForAccount(role, mailboxes, appointedMailboxId);
+    const effective = resolution.kind === "appointment_stale" ? resolution.fallback : resolution;
+    return effective.kind === "none" ? null : effective.mailbox;
+};

package/dist/id.d.ts

@@ -0,0 +1,124 @@
+import type { MessageIdSource, SyncWarningItem } from "./types.js";
+export declare const base36uuid: () => string;
+export declare const base36uuidv5: (name: string, namespace: string) => string;
+export declare const REMIT_NAMESPACE = "9e89694d-214b-4d9b-99f5-214b4d9b99f5";
+export declare const deriveAccountConfigId: (userId: string) => string;
+export declare const deriveAddressId: (accountConfigId: string, email: string) => string;
+/**
+ * The stored form of a calendar's URL segment (issue #15). A DAV path segment
+ * is matched case-insensitively by the clients that bookmark one, so the folded
+ * form is what both the derived id and the stored column are built from — the
+ * id derivation folding on its own would let `findByUrlSegment` and a `get` by
+ * derived id disagree about the same path.
+ */
+export declare const normalizeCalendarUrlSegment: (urlSegment: string) => string;
+/**
+ * Identity of a calendar collection (issue #15). Derived from the account
+ * config and the collection's URL segment, so the CalDAV path a client
+ * bookmarks resolves to a row with no lookup table, and provisioning the
+ * default collection twice — two concurrent first uses of the same account —
+ * writes the same row rather than a second, unreachable one.
+ */
+export declare const deriveCalendarId: (accountConfigId: string, urlSegment: string) => string;
+/**
+ * Identity of a calendar's feed address (issue #1067). Derived from the
+ * collection, so one calendar holds one active token by construction: rotating
+ * rewrites the row it already has instead of leaving a second live address
+ * nobody can see to revoke.
+ */
+export declare const deriveCalendarFeedTokenId: (calendarId: string) => string;
+/**
+ * Identity of a calendar resource (issue #15). Derived from its collection and
+ * its resource name — the last path segment of the resource's URL — so a
+ * repeated PUT of the same resource rewrites its own row instead of forking a
+ * duplicate the collection can never reach.
+ *
+ * The resource name, not the iCalendar UID, is the name: CalDAV addresses a
+ * resource by URL, and a client is free to store the same UID under a second
+ * name (RFC 4791 4.1). Keying on the UID would make those two resources one
+ * row and silently lose the second.
+ */
+export declare const deriveCalendarObjectId: (calendarId: string, resourceName: string) => string;
+/**
+ * Identity of a suggestion read out of a message (issue #1033). Derived from
+ * the message, the MIME part the bytes came from and the event's iCalendar
+ * UID, so re-reading the same message converges on the row it already wrote
+ * instead of stacking a second card on the message every pass.
+ *
+ * All three parts are needed. The message alone would merge two invitations
+ * sent in one mail; the part alone is not stable enough to key on across a
+ * re-parse; and the UID keeps two events sent as one part apart.
+ *
+ * The message is in the seed, so identity is per message, not per event: a
+ * later message carrying the same UID derives its own id, and the earlier
+ * suggestion survives beside it as `Superseded`. The user can see which
+ * revision they are being asked about, and the older message still has a card.
+ * The same holds for a plain resend — a redelivered copy is a new message and
+ * so a new card, which the SEQUENCE comparison then declines to supersede
+ * anything for.
+ */
+export declare const deriveCalendarSuggestionId: (messageId: string, bodyPartId: string, icalUid: string) => string;
+export declare const bareMessageId: (value: string) => string;
+export declare const wireMessageId: (value: string) => string;
+export declare const isValidMessageId: (messageId: string | undefined) => boolean;
+export declare const normalizeMessageIdHeader: (source: MessageIdSource) => string;
+export declare const deriveMessageId: (accountId: string, messageIdHeader: string) => string;
+export declare const deriveMessageIdFromSource: (accountId: string, source: MessageIdSource) => string;
+/**
+ * Identity of a message copied into another folder (issue #75). Derived from
+ * the source message and the destination mailbox so a copy is deterministic:
+ * copying the same mail into the same folder twice — a replayed COPY event or a
+ * repeated user copy — resolves to one row instead of a fresh unreachable
+ * duplicate each time. A random id, which is what the copy path used before,
+ * gave every attempt a new identity that no later sync or delete could reach.
+ *
+ * The destination mailbox is part of the name so a copy of one mail into two
+ * folders is two rows, one per folder. It also keeps this id out of the space
+ * sync assigns: sync keys a message on `deriveMessageId(accountId,
+ * messageIdHeader)`, which is folder-independent, so the copy row can never
+ * collide with, or be overwritten by, the canonical synced row.
+ */
+export declare const deriveCopyMessageId: (sourceMessageId: string, destinationMailboxId: string) => string;
+/**
+ * Identity of a conversation (issue #1017). Keyed on the account config, not on
+ * the account: two mailboxes connected to one config hold the same conversation,
+ * and keying on the account gave each of them its own thread rooted at the same
+ * header — so a reply sent from the second account opened a conversation of one
+ * beside the one it answered.
+ *
+ * Messages stay per account (`deriveMessageId`). Each account keeps its own copy
+ * of a mail, and the copies meet in one thread through the shared root header.
+ */
+export declare const deriveThreadId: (accountConfigId: string, rootMessageIdHeader: string) => string;
+export declare const deriveEnvelopeId: (messageId: string) => string;
+/**
+ * Canonical IMAP path for the root MIME node. BODYSTRUCTURE leaves the
+ * root's `part` blank; we assign "0" so it has a stable, unambiguous key
+ * across the codebase (BodyPart row id, S3 key, seed scripts).
+ */
+export declare const ROOT_PART_PATH = "0";
+export declare const deriveBodyPartId: (messageId: string, partPath: string) => string;
+/**
+ * Identity of a quarantined message (issue #72). Derived rather than generated
+ * so re-quarantining the same message rewrites its own row: the sync path can
+ * write without first checking whether an entry already exists.
+ *
+ * `uidValidity` is part of the name because a uid alone does not identify a
+ * message — only uidValidity + uid does, forever (RFC 9051 2.3.1.1). A mailbox
+ * keeps its `mailboxId` across a UIDVALIDITY bump (the sync path updates the
+ * same row), so without this a stale entry would derive the same id as a later,
+ * unrelated message and suppress it from a sync round.
+ */
+export declare const deriveQuarantineId: (accountId: string, mailboxId: string, uidValidity: number, uid: number) => string;
+/**
+ * The `sha256:`-prefixed Message-ID hash a quarantine record carries, or
+ * undefined when the message declared no usable Message-ID.
+ *
+ * The sync path coerces a missing Message-ID to `""`, and hashing that would
+ * give every Message-ID-less message the same hash — so the one field whose
+ * purpose is correlating reports of the same message would silently correlate
+ * unrelated ones. Absent is the honest value, and this is the only way the
+ * value is produced, so the empty hash cannot be written by accident.
+ */
+export declare const quarantineMessageIdHash: (messageIdHeader: string | undefined) => string | undefined;
+export declare const deriveSyncWarningId: (accountId: string, mailboxId: string, uidValidity: number, uid: number, stage: SyncWarningItem["stage"]) => string;

package/{src/id.ts → dist/id.js}

@@ -1,26 +1,12 @@
 import { createHash } from "node:crypto";
 import shortUuid from "short-uuid";
 import { v5 as uuidv5 } from "uuid";
-import type { MessageIdSource } from "./types.js";
-
 const translator = shortUuid.createTranslator(shortUuid.constants.uuid25Base36);
-
-export const base36uuid = (): string => translator.generate();
-
-export const base36uuidv5 = (name: string, namespace: string): string =>
-	translator.fromUUID(uuidv5(name, namespace));
-
+export const base36uuid = () => translator.generate();
+export const base36uuidv5 = (name, namespace) => translator.fromUUID(uuidv5(name, namespace));
 export const REMIT_NAMESPACE = "9e89694d-214b-4d9b-99f5-214b4d9b99f5";
-
-export const deriveAddressId = (
-	accountConfigId: string,
-	email: string,
-): string =>
-	base36uuidv5(
-		`address:${accountConfigId}:${email.toLowerCase()}`,
-		REMIT_NAMESPACE,
-	);
-
+export const deriveAccountConfigId = (userId) => base36uuidv5(`account:${userId}`, REMIT_NAMESPACE);
+export const deriveAddressId = (accountConfigId, email) => base36uuidv5(`address:${accountConfigId}:${email.toLowerCase()}`, REMIT_NAMESPACE);
 /**
  * The stored form of a calendar's URL segment (issue #15). A DAV path segment
  * is matched case-insensitively by the clients that bookmark one, so the folded
@@ -28,9 +14,7 @@ export const deriveAddressId = (
  * id derivation folding on its own would let `findByUrlSegment` and a `get` by
  * derived id disagree about the same path.
  */
-export const normalizeCalendarUrlSegment = (urlSegment: string): string =>
-	urlSegment.trim().toLowerCase();
-
+export const normalizeCalendarUrlSegment = (urlSegment) => urlSegment.trim().toLowerCase();
 /**
  * Identity of a calendar collection (issue #15). Derived from the account
  * config and the collection's URL segment, so the CalDAV path a client
@@ -38,24 +22,14 @@ export const normalizeCalendarUrlSegment = (urlSegment: string): string =>
  * default collection twice — two concurrent first uses of the same account —
  * writes the same row rather than a second, unreachable one.
  */
-export const deriveCalendarId = (
-	accountConfigId: string,
-	urlSegment: string,
-): string =>
-	base36uuidv5(
-		`calendar:${accountConfigId}:${normalizeCalendarUrlSegment(urlSegment)}`,
-		REMIT_NAMESPACE,
-	);
-
+export const deriveCalendarId = (accountConfigId, urlSegment) => base36uuidv5(`calendar:${accountConfigId}:${normalizeCalendarUrlSegment(urlSegment)}`, REMIT_NAMESPACE);
 /**
  * Identity of a calendar's feed address (issue #1067). Derived from the
  * collection, so one calendar holds one active token by construction: rotating
  * rewrites the row it already has instead of leaving a second live address
  * nobody can see to revoke.
  */
-export const deriveCalendarFeedTokenId = (calendarId: string): string =>
-	base36uuidv5(`calendarfeedtoken:${calendarId}`, REMIT_NAMESPACE);
-
+export const deriveCalendarFeedTokenId = (calendarId) => base36uuidv5(`calendarfeedtoken:${calendarId}`, REMIT_NAMESPACE);
 /**
  * Identity of a calendar resource (issue #15). Derived from its collection and
  * its resource name — the last path segment of the resource's URL — so a
@@ -67,12 +41,7 @@ export const deriveCalendarFeedTokenId = (calendarId: string): string =>
  * name (RFC 4791 4.1). Keying on the UID would make those two resources one
  * row and silently lose the second.
  */
-export const deriveCalendarObjectId = (
-	calendarId: string,
-	resourceName: string,
-): string =>
-	base36uuidv5(`calendarobject:${calendarId}:${resourceName}`, REMIT_NAMESPACE);
-
+export const deriveCalendarObjectId = (calendarId, resourceName) => base36uuidv5(`calendarobject:${calendarId}:${resourceName}`, REMIT_NAMESPACE);
 /**
  * Identity of a suggestion read out of a message (issue #1033). Derived from
  * the message, the MIME part the bytes came from and the event's iCalendar
@@ -91,51 +60,27 @@ export const deriveCalendarObjectId = (
  * so a new card, which the SEQUENCE comparison then declines to supersede
  * anything for.
  */
-export const deriveCalendarSuggestionId = (
-	messageId: string,
-	bodyPartId: string,
-	icalUid: string,
-): string =>
-	base36uuidv5(
-		`calendarsuggestion:${messageId}:${bodyPartId}:${icalUid}`,
-		REMIT_NAMESPACE,
-	);
-
-export const isValidMessageId = (messageId: string | undefined): boolean => {
-	if (!messageId) return false;
-	const trimmed = messageId.trim();
-	return trimmed !== "" && trimmed !== "<>";
+export const deriveCalendarSuggestionId = (messageId, bodyPartId, icalUid) => base36uuidv5(`calendarsuggestion:${messageId}:${bodyPartId}:${icalUid}`, REMIT_NAMESPACE);
+export const bareMessageId = (value) => value.replace(/^[\s<]+|[\s>]+$/g, "");
+export const wireMessageId = (value) => `<${bareMessageId(value)}>`;
+export const isValidMessageId = (messageId) => messageId !== undefined && bareMessageId(messageId) !== "";
+export const normalizeMessageIdHeader = (source) => {
+    if (isValidMessageId(source.messageId)) {
+        return source.messageId;
+    }
+    const parts = [
+        "generated",
+        source.mailboxId,
+        source.uid.toString(),
+        source.date || "",
+        source.subject || "",
+        source.fromMailbox || "",
+        source.fromHost || "",
+    ];
+    return parts.join(":");
 };
-
-export const normalizeMessageIdHeader = (source: MessageIdSource): string => {
-	if (isValidMessageId(source.messageId)) {
-		return source.messageId as string;
-	}
-
-	const parts = [
-		"generated",
-		source.mailboxId,
-		source.uid.toString(),
-		source.date || "",
-		source.subject || "",
-		source.fromMailbox || "",
-		source.fromHost || "",
-	];
-
-	return parts.join(":");
-};
-
-export const deriveMessageId = (
-	accountId: string,
-	messageIdHeader: string,
-): string =>
-	base36uuidv5(`message:${accountId}:${messageIdHeader}`, REMIT_NAMESPACE);
-
-export const deriveMessageIdFromSource = (
-	accountId: string,
-	source: MessageIdSource,
-): string => deriveMessageId(accountId, normalizeMessageIdHeader(source));
-
+export const deriveMessageId = (accountId, messageIdHeader) => base36uuidv5(`message:${accountId}:${messageIdHeader}`, REMIT_NAMESPACE);
+export const deriveMessageIdFromSource = (accountId, source) => deriveMessageId(accountId, normalizeMessageIdHeader(source));
 /**
  * Identity of a message copied into another folder (issue #75). Derived from
  * the source message and the destination mailbox so a copy is deterministic:
@@ -150,15 +95,7 @@ export const deriveMessageIdFromSource = (
  * messageIdHeader)`, which is folder-independent, so the copy row can never
  * collide with, or be overwritten by, the canonical synced row.
  */
-export const deriveCopyMessageId = (
-	sourceMessageId: string,
-	destinationMailboxId: string,
-): string =>
-	base36uuidv5(
-		`messagecopy:${sourceMessageId}:${destinationMailboxId}`,
-		REMIT_NAMESPACE,
-	);
-
+export const deriveCopyMessageId = (sourceMessageId, destinationMailboxId) => base36uuidv5(`messagecopy:${sourceMessageId}:${destinationMailboxId}`, REMIT_NAMESPACE);
 /**
  * Identity of a conversation (issue #1017). Keyed on the account config, not on
  * the account: two mailboxes connected to one config hold the same conversation,
@@ -169,28 +106,15 @@ export const deriveCopyMessageId = (
  * Messages stay per account (`deriveMessageId`). Each account keeps its own copy
  * of a mail, and the copies meet in one thread through the shared root header.
  */
-export const deriveThreadId = (
-	accountConfigId: string,
-	rootMessageIdHeader: string,
-): string =>
-	base36uuidv5(
-		`thread:${accountConfigId}:${rootMessageIdHeader.toLowerCase()}`,
-		REMIT_NAMESPACE,
-	);
-
-export const deriveEnvelopeId = (messageId: string): string =>
-	base36uuidv5(`envelope:${messageId}`, REMIT_NAMESPACE);
-
+export const deriveThreadId = (accountConfigId, rootMessageIdHeader) => base36uuidv5(`thread:${accountConfigId}:${rootMessageIdHeader.toLowerCase()}`, REMIT_NAMESPACE);
+export const deriveEnvelopeId = (messageId) => base36uuidv5(`envelope:${messageId}`, REMIT_NAMESPACE);
 /**
  * Canonical IMAP path for the root MIME node. BODYSTRUCTURE leaves the
  * root's `part` blank; we assign "0" so it has a stable, unambiguous key
  * across the codebase (BodyPart row id, S3 key, seed scripts).
  */
 export const ROOT_PART_PATH = "0";
-
-export const deriveBodyPartId = (messageId: string, partPath: string): string =>
-	base36uuidv5(`bodypart:${messageId}:${partPath}`, REMIT_NAMESPACE);
-
+export const deriveBodyPartId = (messageId, partPath) => base36uuidv5(`bodypart:${messageId}:${partPath}`, REMIT_NAMESPACE);
 /**
  * Identity of a quarantined message (issue #72). Derived rather than generated
  * so re-quarantining the same message rewrites its own row: the sync path can
@@ -202,17 +126,7 @@ export const deriveBodyPartId = (messageId: string, partPath: string): string =>
  * same row), so without this a stale entry would derive the same id as a later,
  * unrelated message and suppress it from a sync round.
  */
-export const deriveQuarantineId = (
-	accountId: string,
-	mailboxId: string,
-	uidValidity: number,
-	uid: number,
-): string =>
-	base36uuidv5(
-		`quarantine:${accountId}:${mailboxId}:${uidValidity}:${uid}`,
-		REMIT_NAMESPACE,
-	);
-
+export const deriveQuarantineId = (accountId, mailboxId, uidValidity, uid) => base36uuidv5(`quarantine:${accountId}:${mailboxId}:${uidValidity}:${uid}`, REMIT_NAMESPACE);
 /**
  * The `sha256:`-prefixed Message-ID hash a quarantine record carries, or
  * undefined when the message declared no usable Message-ID.
@@ -223,12 +137,12 @@ export const deriveQuarantineId = (
  * unrelated ones. Absent is the honest value, and this is the only way the
  * value is produced, so the empty hash cannot be written by accident.
  */
-export const quarantineMessageIdHash = (
-	messageIdHeader: string | undefined,
-): string | undefined => {
-	if (!messageIdHeader || !isValidMessageId(messageIdHeader)) return undefined;
-	const digest = createHash("sha256")
-		.update(messageIdHeader.trim())
-		.digest("hex");
-	return `sha256:${digest}`;
+export const quarantineMessageIdHash = (messageIdHeader) => {
+    if (!messageIdHeader || !isValidMessageId(messageIdHeader))
+        return undefined;
+    const digest = createHash("sha256")
+        .update(messageIdHeader.trim())
+        .digest("hex");
+    return `sha256:${digest}`;
 };
+export const deriveSyncWarningId = (accountId, mailboxId, uidValidity, uid, stage) => base36uuidv5(`syncwarning:${accountId}:${mailboxId}:${uidValidity}:${uid}:${stage}`, REMIT_NAMESPACE);