Mail library and GAM-based mail app

As I understand, this doesn't work on hardware but works in hosted?

There are many networking bugs that can cause a freeze on hardware but won't be hit in hosted. Even things like certain DNS records. See https://github.com/betrusted-io/xous-core/pull/918 for recode testing infrastructure, which pins some as XFAIL and talks a little in the comments about the type of issue. Once the network CI PR lands, there will be a bunch of network bug PRs to turn failing tests green. I can point you to branches with fixes (PR not opened, branch exists on my fork) if you want to look at it before the fixes land. Many of these are a pain to track down since had to have my Pi hat listening on the debug stream and did at least 20 or 30 flashes to hunt some down... before the renode stuff was made.

As I understand, this doesn't work on hardware but works in hosted?

There are many networking bugs that can cause a freeze on hardware but won't be hit in hosted. Even things like certain DNS records. See https://github.com/betrusted-io/xous-core/pull/918 for recode testing infrastructure, which pins some as XFAIL and talks a little in the comments about the type of issue. Once the network CI PR lands, there will be a bunch of network bug PRs to turn failing tests green. I can point you to branches with fixes (PR not opened, branch exists on my fork) if you want to look at it before the fixes land. Many of these are a pain to track down since had to have my Pi hat listening on the debug stream and did at least 20 or 30 flashes to hunt some down... before the renode stuff was made.

As I understand, this doesn't work on hardware but works in hosted?

There are many networking bugs that can cause a freeze on hardware but won't be hit in hosted. Even things like certain DNS records. See https://github.com/betrusted-io/xous-core/pull/918 for recode testing infrastructure, which pins some as XFAIL and talks a little in the comments about the type of issue. Once the network CI PR lands, there will be a bunch of network bug PRs to turn failing tests green. I can point you to branches with fixes (PR not opened, branch exists on my fork) if you want to look at it before the fixes land. Many of these are a pain to track down since had to have my Pi hat listening on the debug stream and did at least 20 or 30 flashes to hunt some down... before the renode stuff was made.

Used AI agent to help with branch links and checking against my known bugs.

Nice work — the protocol code reads carefully done (literal-safe IMAP framing, the STARTTLS-injection guard). One heads-up for the jump to hardware: hosted mode runs on the host OS network stack via plain std, so services/net and services/dns are never exercised — all of the below only shows up on hardware (or renode).

• DNS: the stock resolver rejects any answer containing CNAME records, which covers a lot of mail endpoints — outlook.office365.com, imap.mail.yahoo.com and iCloud all resolve through CNAME chains and will fail to connect, while imap.gmail.com and Fastmail are plain A records and unaffected. Fix with unit tests: 22824e40d on my xas-integration branch.
• Read timeouts: the mail lib never sets one, so on hardware every read can block forever — and since the network calls run on the UX thread, a stalled server or an AP drop mid-FETCH freezes the app. Adding timeouts is currently a trap, though: on stock services/net a read timeout on a quiet socket never fires (fixes on my net-fixes-v3 branch — 69fabf7fd, aa23039f7, f78484467 — queued behind #918), and a blocked read that carries a timeout isn't woken by the peer's FIN, so reads on a server-closed connection stall for the full timeout (the rx pump checks expiry before its CloseWait branch; no fix for that one yet). Mail servers close idle connections aggressively, so IMAP/SMTP exercises both.
• xas-integration is upstream dev plus the DNS and reaper fixes cherry-picked, if you want a single branch to try on hardware.

Triage hint for a first hardware run: with Gmail or Fastmail, DNS won't be your blocker — the block-forever read is the likelier freeze. TLS should be fine as-is: same libs/tls + rustls pin as mtxchat, which is hardware-proven.

Used AI agent to help with branch links and checking against my known bugs.

Nice work — the protocol code reads carefully done (literal-safe IMAP framing, the STARTTLS-injection guard). One heads-up for the jump to hardware: hosted mode runs on the host OS network stack via plain std, so services/net and services/dns are never exercised — all of the below only shows up on hardware (or renode).

• DNS: the stock resolver rejects any answer containing CNAME records, which covers a lot of mail endpoints — outlook.office365.com, imap.mail.yahoo.com and iCloud all resolve through CNAME chains and will fail to connect, while imap.gmail.com and Fastmail are plain A records and unaffected. Fix with unit tests: 22824e40d on my xas-integration branch.
• Read timeouts: the mail lib never sets one, so on hardware every read can block forever — and since the network calls run on the UX thread, a stalled server or an AP drop mid-FETCH freezes the app. Adding timeouts is currently a trap, though: on stock services/net a read timeout on a quiet socket never fires (fixes on my net-fixes-v3 branch — 69fabf7fd, aa23039f7, f78484467 — queued behind #918), and a blocked read that carries a timeout isn't woken by the peer's FIN, so reads on a server-closed connection stall for the full timeout (the rx pump checks expiry before its CloseWait branch; no fix for that one yet). Mail servers close idle connections aggressively, so IMAP/SMTP exercises both.
• xas-integration is upstream dev plus the DNS and reaper fixes cherry-picked, if you want a single branch to try on hardware.

Triage hint for a first hardware run: with Gmail or Fastmail, DNS won't be your blocker — the block-forever read is the likelier freeze. TLS should be fine as-is: same libs/tls + rustls pin as mtxchat, which is hardware-proven.

Fixed a non-responsive reply key, and added a screenshot! 🎉