Sync the self-hosting stack

2026-09-08 13:38:18 +02:00
parent 9b7a93452a
commit 9aac9f6174
1 changed files with 24 additions and 0 deletions
@@ -9,6 +9,30 @@ one of them changed. An entry says which artefact and which version, so `web 0.1
 Every version published to a channel appears here. Nothing is written from memory afterwards: a build
 cannot be published without its entry.
 ## 2026-09-08 — "Last active" told you someone had been seen, not that they had said anything `api 0.108.0` `web 0.131.0`
 The per-user table on the Statistics page counted what each account had written, and showed when that
 account was last active. Those two are further apart than they look. Being active is bumped by any use
 of the product at all, so an account opened every morning to read reports that it was here today —
 and says nothing about whether the person has typed since March. On a screen whose job is to show who
 is actually using the instance, that gap is usually the thing being looked for.
 **A "Last message" column**, sitting next to the message count it belongs to: when each account last
 wrote, or "Never" if it never has. On a narrow screen it becomes its own labelled line on the card,
 rather than a second bare "3 days ago" beside the first one, which would have named neither.
 **This one column does not sort**, and the reason is worth stating rather than hiding. Every other
 column there is ordered by the database while it selects the page; this one is worked out afterwards,
 for the fifty accounts that page already chose. That is what keeps it from costing anything on a large
 instance, and it is also what leaves the server nothing to order by. "Last active" beside it still
 sorts, and answers the same question more coarsely.
 **Self-hosters:** one index on the messages table is replaced by a wider one leading on the same
 column — the old one is dropped and the new one built in its place, automatically when the api starts,
 like every schema change here. No column is dropped and nothing becomes unique, so the schema guard
 has nothing to refuse. On an instance with millions of messages the build is not instantaneous, and
 the api finishes starting when the index finishes.
 ## 2026-09-08 — Nobody running Jarvis could tell how much it was actually being used `api 0.107.0` `web 0.130.0`
 A platform administrator had no way to answer "is this instance quiet or busy, growing or stalled,