draft/read-marker keeps the read position on the server, so opening moho on a second
machine — or beside a phone client — starts where you left off rather than at the
bottom.
moho already does this on Matrix (m.fully_read, matrix/receipts.rs:150) and
Discord (MESSAGE_ACK). IRC is where it silently does not.
What is needed
Request draft/read-marker, send MARKREAD <target> timestamp=... when a buffer is
marked read, and apply an inbound MARKREAD to the unread count.
markBufferRead is already the one place this happens.
Done looks like: a channel read on one machine is read on the other.
One of the four draft IRCv3 extensions that actively-maintained clients already ship
(WeeChat, Halloy, bIRC). The other eight drafts were scored by the 2026-09-10 coverage
review and deliberately not filed: they can still change underneath an implementation.
moho currently implements 1 of the 12 drafts (chathistory).
`draft/read-marker` keeps the read position on the server, so opening moho on a second
machine — or beside a phone client — starts where you left off rather than at the
bottom.
moho already does this on Matrix (`m.fully_read`, `matrix/receipts.rs:150`) and
Discord (`MESSAGE_ACK`). IRC is where it silently does not.
**What is needed**
- Request `draft/read-marker`, send `MARKREAD <target> timestamp=...` when a buffer is
marked read, and apply an inbound `MARKREAD` to the unread count.
- `markBufferRead` is already the one place this happens.
**Done looks like:** a channel read on one machine is read on the other.
One of the four draft IRCv3 extensions that actively-maintained clients already ship
(WeeChat, Halloy, bIRC). The other eight drafts were scored by the 2026-09-10 coverage
review and deliberately not filed: they can still change underneath an implementation.
moho currently implements **1 of the 12 drafts** (`chathistory`).
MARKREAD is sent when a buffer is marked read, and an inbound one is passed to the frontend as a readMarker event.
Deliberately not stored in the daemon: which messages count as read is a question the thing with the screen owns, and a daemon keeping a second answer would be keeping one that disagrees. The capability negotiates on Ergo; the cross-client behaviour itself was not exercised, since that needs two clients on one account.
Done in nobilis [d271fb7](https://git.salastil.com/Salastil/nobilis/commit/d271fb7).
`MARKREAD` is sent when a buffer is marked read, and an inbound one is passed to the frontend as a `readMarker` event.
Deliberately not stored in the daemon: which messages count as read is a question the thing with the screen owns, and a daemon keeping a second answer would be keeping one that disagrees. The capability negotiates on Ergo; the cross-client behaviour itself was not exercised, since that needs two clients on one account.
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.
draft/read-markerkeeps the read position on the server, so opening moho on a secondmachine — or beside a phone client — starts where you left off rather than at the
bottom.
moho already does this on Matrix (
m.fully_read,matrix/receipts.rs:150) andDiscord (
MESSAGE_ACK). IRC is where it silently does not.What is needed
draft/read-marker, sendMARKREAD <target> timestamp=...when a buffer ismarked read, and apply an inbound
MARKREADto the unread count.markBufferReadis already the one place this happens.Done looks like: a channel read on one machine is read on the other.
One of the four draft IRCv3 extensions that actively-maintained clients already ship
(WeeChat, Halloy, bIRC). The other eight drafts were scored by the 2026-09-10 coverage
review and deliberately not filed: they can still change underneath an implementation.
moho currently implements 1 of the 12 drafts (
chathistory).Done in nobilis d271fb7.
MARKREADis sent when a buffer is marked read, and an inbound one is passed to the frontend as areadMarkerevent.Deliberately not stored in the daemon: which messages count as read is a question the thing with the screen owns, and a daemon keeping a second answer would be keeping one that disagrees. The capability negotiates on Ergo; the cross-client behaviour itself was not exercised, since that needs two clients on one account.