- Shipped
- August 14, 2026 at 7:08 PM UTC
- Author
- kamo
- Commit
- fcde8fb
The bell opened a popover, which is the right shape for "what just happened" and the wrong one for "what did that reminder say on Tuesday". A panel hanging off a toolbar cannot be paged, cannot be filtered without crowding, and closes when you click anything — so a member could see a few recent unread notifications and nothing else. Everything already read was, in practice, gone. That is a poor property for the record of what the application has told someone. /notifications is that record. It reads as a chronology rather than a list, because notifications are events and the question a member brings is nearly always "when": a spine of days with the notifications hanging off it, each dot in its own kind's colour, so a month of history reads as bands before a single word is read. Unread rows carry the ground and read ones carry only the dot, which is the difference being scanned for. The filter rail narrows what the spine holds rather than reordering it — read, unread or both, and by kind with a count against each. The day grouping is calendar-aware rather than elapsed-hours: at half past midnight, something from four hours ago happened yesterday, and "4h ago" is not what a person looking for it will scan for. Anything the server could not date is kept and grouped apart, where it cannot claim a day it may not belong to. The bell is now a link, badged like the other two attention marks in the bar so all three read the same way. What differs is the movement, and deliberately: an outstanding document and a running clock are states, and they pulse a ring that says "still true". An unread notification is an event, and what a bell does when an event happens is ring. So it swings — struck once and settling, amplitudes halving 12° → 9° → 6° → 3° → 1.5°, pivoting at the crown because a bell hangs — and then rests for four seconds. A bell that never stopped would be an alarm, and the count beside it already says the thing persists.