Two things, both from using it on two real accounts.
1. An account linked for its files also offered its calendar and address book
Neither had been shared. That wasn't ihasmail inventing them — asked about the other account, live 0.16.19 returns every calendar and every book it holds, each with full rights:
[email protected]
calendar "InBuxA Calendar (postmaster)" isSubscribed: false
myRights: read, write, share, delete — all true
address book "InBuxA Address Book (postmaster)" isSubscribed: false
myRights: read, write, share, delete — all true
There is nothing in the rights to tell "shared with me" from "reachable at all", because the server doesn't distinguish them. isSubscribed does, and it's the field JMAP has for exactly this — false on all of them.
So a shared calendar or book is listed under Shared with me once added, and under Available to add until then, one button either way.
Nothing unsubscribed contributes anything. A calendar not added draws no events; a book not added lends no cards to the To field. That last one matters most — it's the difference between offering a colleague's contacts and offering a stranger's without anyone having asked.
The mock's shared collections now arrive unsubscribed, the way the real server hands them over, and its Calendar/set / AddressBook/set route by account since subscribing is a write to their account.
2. Recipients could only be typed, not browsed
Addressing worked only if you already knew the name you were half-way through typing. Autocomplete answers "finish this for me"; there was no answer to "who is there?".
The To row now opens the address books — from a button beside Cc and Bcc, where someone thinking about recipients is already looking, and from the To label itself. Search across every book or narrow to one, tick as many people as the message needs, send them to To, Cc or Bcc. Picking for a hidden field opens it, since a Bcc dropped somewhere invisible is worse than no Bcc.
Every address is its own row, not every person. Someone with a work address and a personal one is a choice the writer has to make; a picker that listed the card and quietly took the first address would make it for them.
Shared books are in it on the same footing as your own, with the account named on each row.
Verified
Shared calendar sits under Available to add with no events in the grid; adding moves it to Shared with me and its events appear; removing undoes both.
suggest("katherine") returns nothing until the shared book is added, then returns her.
The picker lists own and shared contacts, each row naming its source; ticking one of each and choosing Cc opens the Cc row with both in it.
328 web and 77 server tests pass. npm run typecheck clean.
Two things, both from using it on two real accounts.
## 1. An account linked for its files also offered its calendar and address book
Neither had been shared. That wasn't ihasmail inventing them — asked about the other account, live 0.16.19 returns every calendar and every book it holds, each with full rights:
```
[email protected]
calendar "InBuxA Calendar (postmaster)" isSubscribed: false
myRights: read, write, share, delete — all true
address book "InBuxA Address Book (postmaster)" isSubscribed: false
myRights: read, write, share, delete — all true
```
There is nothing in the rights to tell "shared with me" from "reachable at all", because the server doesn't distinguish them. `isSubscribed` does, and it's the field JMAP has for exactly this — false on all of them.
So a shared calendar or book is listed under **Shared with me** once added, and under **Available to add** until then, one button either way.
**Nothing unsubscribed contributes anything.** A calendar not added draws no events; a book not added lends no cards to the To field. That last one matters most — it's the difference between offering a colleague's contacts and offering a stranger's without anyone having asked.
The mock's shared collections now arrive unsubscribed, the way the real server hands them over, and its `Calendar/set` / `AddressBook/set` route by account since subscribing is a write to *their* account.
## 2. Recipients could only be typed, not browsed
Addressing worked only if you already knew the name you were half-way through typing. Autocomplete answers "finish this for me"; there was no answer to "who is there?".
The To row now opens the address books — from a button beside Cc and Bcc, where someone thinking about recipients is already looking, and from the To label itself. Search across every book or narrow to one, tick as many people as the message needs, send them to To, Cc or Bcc. Picking for a hidden field opens it, since a Bcc dropped somewhere invisible is worse than no Bcc.
**Every address is its own row, not every person.** Someone with a work address and a personal one is a choice the writer has to make; a picker that listed the card and quietly took the first address would make it for them.
Shared books are in it on the same footing as your own, with the account named on each row.
### Verified
- Shared calendar sits under Available to add with no events in the grid; adding moves it to Shared with me and its events appear; removing undoes both.
- `suggest("katherine")` returns nothing until the shared book is added, then returns her.
- The picker lists own and shared contacts, each row naming its source; ticking one of each and choosing Cc opens the Cc row with both in it.
328 web and 77 server tests pass. `npm run typecheck` clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
**Merged** 2026-08-27 as coffey-labs/ihasmail@d9995cd0b4c2
<sub>Rebuilt from: GH Archive, git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Two things, both from using it on two real accounts.
1. An account linked for its files also offered its calendar and address book
Neither had been shared. That wasn't ihasmail inventing them — asked about the other account, live 0.16.19 returns every calendar and every book it holds, each with full rights:
There is nothing in the rights to tell "shared with me" from "reachable at all", because the server doesn't distinguish them.
isSubscribeddoes, and it's the field JMAP has for exactly this — false on all of them.So a shared calendar or book is listed under Shared with me once added, and under Available to add until then, one button either way.
Nothing unsubscribed contributes anything. A calendar not added draws no events; a book not added lends no cards to the To field. That last one matters most — it's the difference between offering a colleague's contacts and offering a stranger's without anyone having asked.
The mock's shared collections now arrive unsubscribed, the way the real server hands them over, and its
Calendar/set/AddressBook/setroute by account since subscribing is a write to their account.2. Recipients could only be typed, not browsed
Addressing worked only if you already knew the name you were half-way through typing. Autocomplete answers "finish this for me"; there was no answer to "who is there?".
The To row now opens the address books — from a button beside Cc and Bcc, where someone thinking about recipients is already looking, and from the To label itself. Search across every book or narrow to one, tick as many people as the message needs, send them to To, Cc or Bcc. Picking for a hidden field opens it, since a Bcc dropped somewhere invisible is worse than no Bcc.
Every address is its own row, not every person. Someone with a work address and a personal one is a choice the writer has to make; a picker that listed the card and quietly took the first address would make it for them.
Shared books are in it on the same footing as your own, with the account named on each row.
Verified
suggest("katherine")returns nothing until the shared book is added, then returns her.328 web and 77 server tests pass.
npm run typecheckclean.🤖 Generated with Claude Code
Merged 2026-08-27 as coffey-labs/ihasmail@d9995cd0b4
Rebuilt from: GH Archive, git history, session transcript.