docs(hearth): where hearth's calendar credential should come from #987

Merged

lytedev merged 1 commit from propose/hearth-credential-doc into main

2026-08-12 16:15:16 -05:00

lytedev commented

2026-08-12 16:00:14 -05:00

Owner

Hearth still reads the household calendar from Google; moving it to Stalwart is blocked on a credential, and every obvious candidate is the wrong one. This records why.

Written to the repo because the original lived in /tmp and was lost to a reboot before anyone acted on it.

Corrected on the way in: the family calendar moved to a Stalwart group collection on 2026-08-12, so the URL the original recommended now 403s — a failure that presents as a credential problem and isn't one.

Hearth still reads the household calendar from Google; moving it to Stalwart is blocked on a credential, and every obvious candidate is the wrong one. This records why. Written to the repo because the original lived in `/tmp` and was **lost to a reboot** before anyone acted on it. Corrected on the way in: the family calendar moved to a Stalwart *group* collection on 2026-08-12, so the URL the original recommended now 403s — a failure that presents as a credential problem and isn't one.

lytedev added 1 commit

2026-08-12 16:00:14 -05:00

docs(hearth): where hearth's calendar credential should come from

/ check-format (push) Successful in 9s

Details

/ build (push) Has been skipped

Details

2fcad6e13f

Hearth still reads the household calendar from Google. Moving it to
Stalwart is blocked on a credential, and every obvious candidate is the
wrong one -- this records why, so the next attempt does not rediscover
it.

Written to the repo because the original lived in /tmp and was lost to a
reboot before anyone acted on it, which is the whole argument for not
keeping findings there.

Corrected on the way in: the family calendar moved from daniel's own
collection (shared by RFC 3744 ACL) to a Stalwart GROUP collection on
2026-08-12, so the URL the original recommended now returns 403. That
failure is worth calling out by name -- it presents as a credential
problem and is not one, which cost an hour today when the assistant's
agenda broke while its credential was provably fine.

The substance is that app passwords here are server-generated and
shown once, because directoryId points at Kanidm and makes every
Stalwart account external; that they can be scoped by permission AND by
source IP; and that hearth wants its own scoped credential rather than
the assistant's, whose rotation would otherwise silently break the TV.

Open questions are listed as open rather than guessed at -- in
particular whether an ApiKey authenticates over CalDAV at all, which
decides whether hearth needs an app password instead.

lytedev merged commit 2fcad6e13f into main

2026-08-12 16:15:16 -05:00

lytedev deleted branch propose/hearth-credential-doc

2026-08-12 16:15:16 -05:00