@withbuddi/buddi 0.1.0-pre.27 → 0.1.0-pre.28

package/node_modules/imapflow/dist/esm/tools.js

@@ -645,9 +645,10 @@ export function getColorFlags(color) {
  *
  * @param untagged - Parsed untagged IMAP response
  * @param mailbox - Current mailbox state object
+ * @param idHashAlgorithm - Hash for the fallback message id, `md5` unless the client was told otherwise
  * @returns Formatted message object with properties like seq, uid, flags, envelope, etc.
  */
-export async function formatMessageResponse(untagged, mailbox) {
+export async function formatMessageResponse(untagged, mailbox, idHashAlgorithm) {
     let map = {};
     // The sequence number indexes into mailbox state, so an unusable one is dropped rather
     // than coerced to NaN or Infinity
@@ -829,13 +830,14 @@ export async function formatMessageResponse(untagged, mailbox) {
                 // ignore
             }
         }
-        // Non-cryptographic identifier: MD5 is used only to derive a stable, compact
-        // account-unique id from non-secret data (path:uidValidity:uid). No security
-        // property (collision/preimage resistance, secrecy) is relied upon, so a fast
-        // hash is the appropriate choice here - not a security-sensitive use.
+        // Non-cryptographic identifier: the hash only derives a stable, compact account-unique
+        // id from non-secret data (path:uidValidity:uid). No security property (collision or
+        // preimage resistance, secrecy) is relied upon, so the fast default is MD5; a host whose
+        // OpenSSL runs in FIPS mode has no MD5 and names another algorithm through the client
+        // option, at the price of ids that differ from the default ones
         map.id =
             map.emailId ||
-                createHash('md5')
+                createHash(idHashAlgorithm || 'md5')
                     .update([path, mailbox.uidValidity?.toString() || '', map.uid.toString()].join(':'))
                     .digest('hex');
     }

package/node_modules/imapflow/dist/esm/types.d.ts

@@ -44,6 +44,14 @@ export interface ImapFlowOptions {
     clientInfo?: IdInfoObject | undefined;
     /** If true, then do not start IDLE when connection is established */
     disableAutoIdle?: boolean | undefined;
+    /**
+     * Hash algorithm (any name Node's crypto supports) for the fallback message `id` that is
+     * derived from the mailbox path, UIDVALIDITY and UID when the server provides no email id
+     * through OBJECTID or X-GM-EXT-1. Defaults to `'md5'`, which keeps the ids earlier releases
+     * produced. A host whose OpenSSL runs in FIPS mode does not offer MD5, and has to set a
+     * different one, for example `'sha256'`, which yields a 64 character hex id
+     */
+    idHashAlgorithm?: string | undefined;
     /**
      * How long (in ms) the connection has to be inactive before IDLE is started automatically.
      * Keep it above the pause your own code usually leaves between two commands, otherwise every
@@ -97,7 +105,7 @@ export interface ImapFlowOptions {
     disableBinary?: boolean | undefined;
     /** If true, do not enable supported extensions */
     disableAutoEnable?: boolean | undefined;
-    /** If true, do not enable IMAP4rev2 mode even if the server advertises it, and do not treat the advertisement as support for anything IMAP4rev2 implies, such as the extended LIST syntax */
+    /** If true, do not enable IMAP4rev2 mode even if the server advertises it, and do not treat the advertisement as support for anything IMAP4rev2 implies, such as the extended LIST syntax. Servers known to misbehave in IMAP4rev2 mode (Strato RZimapd, detected from its ID response) are kept out of it without this option */
     disableIMAP4rev2?: boolean | undefined;
     /**
      * How long to wait for a usable transport, covering DNS resolution, proxy negotiation and the

package/node_modules/imapflow/package.json

@@ -1,6 +1,6 @@
 {
     "name": "imapflow",
-    "version": "2.1.2",
+    "version": "2.2.1",
     "description": "IMAP Client for Node",
     "type": "module",
     "main": "./dist/cjs/imap-flow.js",
@@ -72,13 +72,13 @@
         "c8": "12.0.0",
         "eslint": "10.11.0",
         "eslint-config-prettier": "10.1.8",
-        "globals": "17.12.0",
+        "globals": "17.13.0",
         "prettier": "3.9.9",
         "tsx": "4.23.15",
         "types-node-legacy": "npm:@types/node@20.0.0",
         "typescript": "6.0.3",
-        "typescript-eslint": "8.70.1",
-        "wrangler": "4.142.0"
+        "typescript-eslint": "8.71.0",
+        "wrangler": "4.145.0"
     },
     "dependencies": {
         "@zone-eu/mailsplit": "5.4.19",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@withbuddi/buddi",
-  "version": "0.1.0-pre.27",
+  "version": "0.1.0-pre.28",
   "type": "module",
   "description": "Your personal agents, on your computer",
   "repository": {
@@ -17,7 +17,7 @@
     "buddi": "packages/install/dist/launcher.js"
   },
   "buddi": {
-    "notes": "### Added\n\n- A reply that stops because it used all its steps now offers **Continue**: a button on the \"Turn budget reached\" line under the conversation's latest reply (while nothing is running), and a Continue button under the answer on Telegram. Either sends \"continue\" as you into the same conversation, once, and the agent picks up with the whole history.\n\n### Changed\n\n- The agent's Setup → Brain shows \"Steps per reply\" (was \"Max turns\"), with the built-in default of 40 named when the file sets none, a 10 to 500 range, and a hint that each tool call is a step. It saves through the same path as `buddi agents set --max-turns`.\n- The Developer agent the developer plugin proposes asks for 150 steps per reply instead of the default 40. An agent already installed keeps its file as it is.\n\n- Home opens on a glance: the date, a large greeting and what needs you as one line of counts, each a link to its list (failed jobs, urgent alerts, proposals; approvals and messages scroll to \"Needs you\"). On the right, the Weather plugin's card — now, sky and place, the next twelve hours as a small line, high and low — with the Blob in it; without the plugin the Blob stands there alone. The composer moved under the glance and is one line that grows as you type, with the Continue chips under it. On a phone it stacks.\n- The \"Keep buddi one click away\" card left the top of Home. Home now shows one quiet line at the foot, \"Install buddi as an app, one click from your dock\", only when the browser has offered an install; the owner menu has \"Install the app\" whenever it does, and Settings → System has \"The dashboard as an app\" with the bookmark tip and, on the Mac, `buddi dashboard --install-app`.\n- A plugin's Home glance can carry a card (a figure, one line, a run of numbers drawn as a sparkline, a foot); Home draws the first one on the right of the greeting. The Weather plugin sends one from its next release, and its glance opens the Weather page.\n\n### Fixed\n\n- Restoring a backup before reinstalling its plugins (the normal order on a new machine) skipped those plugins' data, and installing them afterwards gave empty tables. The restore now keeps each missing plugin's data under the data dir and loads it when the plugin is installed (or at the next start), into empty tables only; the recovery checklist says \"finance — 1,544 rows waiting, loaded when you install it\", a table that already had rows stays aside and is listed on its own, and `buddi doctor` shows what is still waiting.\n- An upgrade could leave Postgres unable to start (\"Library not loaded: …libicuuc.77.dylib\"), because npm did not run the Postgres package's script that makes its library links and buddi's own copy pointed back into npm's folder. buddi now makes the missing links itself before every Postgres start and keeps its copy self-contained, and an upgrade first checks that the new version's Postgres starts; if it does not, buddi puts the previous version back, keeps running, and the upgrade result says why.\n- A message an agent sent you repeated its \"@handle:\" at the start of the title on the dashboard, right under the agent's name. Home's Needs you, Settings → Notifications and the toasts now leave the signature off; Telegram keeps it."
+    "notes": "### Added\n\n- Reactions on Telegram count as feedback: 👍 (and ❤️ 🔥 👏 🎉 🙏) or 👎 (💩 🤮) on an agent's answer is recorded against that answer and the run behind it, shows under the same message on the dashboard, and taking it back clears it. The bot replies to nothing, except that a 👎 gets one \"What was off?\", and your Reply to it is kept as the note instead of starting a new turn. The weekly learning digest counts reactions per agent and quotes the 👎 notes.\n- Agents can clean your mailbox, with your approval: mark mail read or unread, archive it (on Gmail it leaves the inbox and keeps its labels; elsewhere it goes to the server's Archive folder), move it to an existing folder or label, or move it to Trash. An agent first shows how many messages and five of them, then one approval covers up to 500, and the card says the count, the mailbox and why (\"newsletters older than a week\"). Nothing is ever deleted outright and no folder is created. Mark, archive and move can be allowed always; Trash is asked every time.\n- The Mail page lists \"Recent changes\" buddi made to your mailbox, with Undo on each: marked mail goes back to how it was, archived or moved mail goes back to its folder, and trashed mail comes back while it is still in Trash (Gmail labels included). Agents can undo too, with your approval.\n- A mail rule can also act on arrival: archive, mark read, or move each matching message to a folder as it comes in. The rule's approval card and its line on Settings → Email say so, Add a rule has the same choice, and each change shows under Recent changes with Undo.\n- Plugins can keep a learned rule themselves where their own rule allows it, and core records who decided each proposal (you, or the plugin by itself). Your track record counts too: once you have kept five rules of one kind from a plugin, with no discard since, new ones of that kind keep themselves; a discard, or an Undo, turns that off again. Plugin host API 1.14.\n- Settings → Proposals groups open rules of the same kind into one card with \"Keep all (N)\": one tap keeps them all, each applied as if kept on its own. Rules that kept themselves say so in the fold.\n- Mail stops asking you about newsletters: when buddi learns to quiet a sender whose mail is sent to many (it carries an unsubscribe link or a mailing-list header, or comes from a no-reply address) and you have never written to them, the rule applies itself instead of waiting as a card. The Mail page lists these under \"Learned\", newest first, each with Undo, and you get at most one line a day (\"buddi learned 7 rules: quieted 7 newsletters — review\"). Senders you have written to, and anything other than quieting, still ask first. On the first start after upgrading, the newsletter cards already waiting are kept the same way.\n- New mail reaches buddi within seconds: each mailbox keeps an IMAP IDLE connection on its inbox, so the server says when mail arrives (or leaves, or changes) and that mailbox is checked right away. The 5-minute check stays as the safety net (every 15 minutes while the live connection is up); a server without IDLE, or a connection that keeps dropping, simply stays on the 5-minute check while buddi reconnects with growing pauses. A rejected password shows \"Password needed\" and stops retrying until you set a new one. Settings → Email shows each mailbox as \"Instant\" or \"Checking every 5 min\". Plugin host API 1.15 (sources can have a long-lived watcher).\n- Each agent has its own \"New chat after\" on Setup → Brain: 3 hours (the default), a day, a week, or never. A chat idle longer than that starts a fresh conversation with your next message; a transcript that grows too long still does, whatever the setting. Also `buddi agents set --idle-rollover` and `buddi.agent_update` over MCP. A plugin's proposed agent can ask for its own default; the Developer agent asks for a day. Plugin host API 1.16.\n- When a chat rolls over (idle or size), the new conversation opens with a short note the agent's own model wrote from the old one: what you were doing, decisions, open threads, what's next. It shows as a folded \"Carried over\" item above the chat that you can read and delete, and the agent reads it as context. Plugins can add lines of their own; the developer plugin adds the workspace, branch, last commit and uncommitted files. If the summary can't be written, the chat still rolls over (with the old copied note after a long transcript, or nothing after an idle gap). Plugin host API 1.16.\n- Settings → Email can change a mailbox's password: \"Set password\" on each row opens a small form that signs in with the new app password against the mailbox's own server first, keeps it only if that works (otherwise the old one stays and the server's reason is shown), and leaves the mailbox's mail where it is. A mailbox whose password buddi can't read says \"Password needed\" with the same button. Agents can't use it.\n- A thin status line at the foot of every dashboard page, each item a link: how this page reaches buddi (Local, Tailnet, or Reconnecting…), the focus that is on and until when, the work (agents working, the queue running or paused, failed jobs), approvals waiting, the version with a dot when a newer buddi is ready, and the time in your timezone, naming it when this device's differs. On a phone it folds into a dot on the rail that opens the same items.\n- `docs/cli.md` gives every command its own linked section (usage, flags, an example, what it tells you to do next such as `buddi service restart`, exit codes, JSON fields), from the same table as `buddi help`, and opens with common tasks: add a model account, change an agent's model or step budget, back up and restore, pair Telegram, add a local connection, upgrade. `buddi help <command>` now says what to do next too, and every command has an example.\n\n### Fixed\n\n- Settings → Email now says \"Password needed\" when your mail provider rejects the saved password while checking mail (an app password revoked at Google, say); it used to keep saying the password was in the vault while nothing was read. The next sign-in that works, or Set password, clears it.\n- Restarting or upgrading buddi no longer signs you out of the dashboard: sessions are kept in the database (only a hash of each session id is stored, and the CSRF value is derived rather than stored), with the same 30-day / 12-hour idle lifetimes and the 7-day Tailscale cap. Sessions from before this version end once at the upgrade. Backups do not carry them.\n- Opening the dashboard while signed out now shows a buddi page (\"You're signed out of this buddi … run `buddi dashboard` for a sign-in link\", with Try again) instead of the browser's \"This site can't be reached\"; through Tailscale with a login that isn't allowed, it says so. API calls still get an empty 401, and the lockout counts the same.\n- A restored plugin's settings no longer wait forever because the plugin seeded a default at install: a settings table (a single text `key` plus a `value`, like finance's preferences) gets the backup's missing keys added, keeps the values already there, and leaves the recovery checklist. Other tables that already have rows are still kept aside.\n- `buddi doctor` on a packaged install now prints \"Kept plugin data: …\" while a restore's plugin data is waiting; the packaged doctor never ran the row the checkout's doctor had.\n- `buddi help vault get` said it prints the secret; it says whether the secret is set, never its value, and the help now says so. `buddi help agents set` lists `--idle-rollover` and points `--account` at Settings → Model accounts; `buddi help upgrade` mentions the packaged `buddi upgrade <version>`; the exit codes of `plugins list`, `plugins approve`, `plugins update`, `telegram unpair`, `backup verify`, `vault set` and `doctor` are written down.\n\n…"
   },
   "files": [
     "packages",