atagen

macltok

public
Star0
Watch0
0bfa3f46f0be39529f9541bdfbff51255e54ffba
3
ssh://brewery@pls.lobotomise.me:33/atagen/macltok.git

Blame: docs/design-decisions.md

96fdf90aacd6atagen2026-09-08 08:24 UTC1
# macltok design decisions
96fdf90aacd6atagen2026-09-08 08:24 UTC2
31ce2453c82fatagen2026-09-24 13:07 UTC3
the contract the working tree actually implements. if the code disagrees with
31ce2453c82fatagen2026-09-24 13:07 UTC4
this, one of them is lying and it should be fixed
31ce2453c82fatagen2026-09-24 13:07 UTC5
31ce2453c82fatagen2026-09-24 13:07 UTC6
## two ways in, one way out
31ce2453c82fatagen2026-09-24 13:07 UTC7
31ce2453c82fatagen2026-09-24 13:07 UTC8
state changes are commands. `ClientHandle::send` queues one and hands back a
31ce2453c82fatagen2026-09-24 13:07 UTC9
`Pending`, `execute` queues and waits, and there's an awaited convenience method
31ce2453c82fatagen2026-09-24 13:07 UTC10
for every command. each command answers exactly once with
31ce2453c82fatagen2026-09-24 13:07 UTC11
`Result<CommandOutput, Error>`. drop the `Pending` if you don't care, the
31ce2453c82fatagen2026-09-24 13:07 UTC12
command still runs
31ce2453c82fatagen2026-09-24 13:07 UTC13
31ce2453c82fatagen2026-09-24 13:07 UTC14
pure reads skip the engine and ask the sdk directly through the handle. rooms,
31ce2453c82fatagen2026-09-24 13:07 UTC15
members, power levels, account data, devices, push notification resolution,
31ce2453c82fatagen2026-09-24 13:07 UTC16
and media bytes all live here
31ce2453c82fatagen2026-09-24 13:07 UTC17
31ce2453c82fatagen2026-09-24 13:07 UTC18
the event stream carries state and only state. timelines, history, typing,
31ce2453c82fatagen2026-09-24 13:07 UTC19
rooms, connection, encryption, verification, upload progress, session. no
31ce2453c82fatagen2026-09-24 13:07 UTC20
command results ride on it. drain it from its own task, it's bounded and the
31ce2453c82fatagen2026-09-24 13:07 UTC21
engine waits for you
31ce2453c82fatagen2026-09-24 13:07 UTC22
31ce2453c82fatagen2026-09-24 13:07 UTC23
one error type for everything, `Error { kind, message, challenge }`. match on
31ce2453c82fatagen2026-09-24 13:07 UTC24
`kind`. `Interrupted` means the engine stopped, the room closed, or the task
31ce2453c82fatagen2026-09-24 13:07 UTC25
doing the work died before it could answer. `challenge` turns up with
31ce2453c82fatagen2026-09-24 13:07 UTC26
`InteractiveAuthRequired`
31ce2453c82fatagen2026-09-24 13:07 UTC27
31ce2453c82fatagen2026-09-24 13:07 UTC28
## engine
31ce2453c82fatagen2026-09-24 13:07 UTC29
31ce2453c82fatagen2026-09-24 13:07 UTC30
the run loop routes and does nothing slow. every task it spawns is registered
31ce2453c82fatagen2026-09-24 13:07 UTC31
with a context. a command task that panics costs its caller an `Interrupted`
31ce2453c82fatagen2026-09-24 13:07 UTC32
and gets logged. a watcher or a room actor that panics takes the engine down,
62fe32759529atagen2026-09-26 08:50 UTC33
emitting `Failed` then `Stopped`. natively, anyway. wasm aborts the whole
62fe32759529atagen2026-09-26 08:50 UTC34
instance on any panic and nothing is left to log it
31ce2453c82fatagen2026-09-24 13:07 UTC35
31ce2453c82fatagen2026-09-24 13:07 UTC36
sync restarts itself with backoff after an error or an unexpected stop, and
5a52012c9b1datagen2026-09-24 23:45 UTC37
`ConnectionChanged` shows `Offline` meanwhile. a run that drops again inside
5a52012c9b1datagen2026-09-24 23:45 UTC38
thirty seconds counts as a failure too, or a server that answers `/versions`
5a52012c9b1datagen2026-09-24 23:45 UTC39
but refuses sync would bounce us between online and offline forever. every return to `Online` re-arms
31ce2453c82fatagen2026-09-24 13:07 UTC40
the send queues, since the sdk parks a room's queue on any send failure and
31ce2453c82fatagen2026-09-24 13:07 UTC41
never unparks it. a recoverable failure while online gets the room another go
31ce2453c82fatagen2026-09-24 13:07 UTC42
after a few seconds
31ce2453c82fatagen2026-09-24 13:07 UTC43
fe4133dbcd47atagen2026-09-26 09:05 UTC44
logout and a rejected token both stop the engine. `run` resolves to a
fe4133dbcd47atagen2026-09-26 09:05 UTC45
`Termination` naming which of those it was, or a shutdown, or every handle
fe4133dbcd47atagen2026-09-26 09:05 UTC46
dropping, so the host never works it out from the events. `Shutdown` answers once
5a52012c9b1datagen2026-09-24 23:45 UTC47
`Stopped` has gone out, every one of them if several were queued
5a52012c9b1datagen2026-09-24 23:45 UTC48
5a52012c9b1datagen2026-09-24 23:45 UTC49
`Engine::run` hands back a boxed future. the real one nests deep enough that
5a52012c9b1datagen2026-09-24 23:45 UTC50
every crate spawning it would trip the compiler's query depth
31ce2453c82fatagen2026-09-24 13:07 UTC51
31ce2453c82fatagen2026-09-24 13:07 UTC52
## rooms
31ce2453c82fatagen2026-09-24 13:07 UTC53
31ce2453c82fatagen2026-09-24 13:07 UTC54
one actor per open room. the engine holds a slot per room, `Active` with a
31ce2453c82fatagen2026-09-24 13:07 UTC55
sender or `Closing` with a fifo of opens and closes that arrived while it wound
31ce2453c82fatagen2026-09-24 13:07 UTC56
down. those replay in order once the actor exits. a room you leave, or get
5a52012c9b1datagen2026-09-24 23:45 UTC57
kicked or banned from, closes itself. it tells the engine first, and anything
5a52012c9b1datagen2026-09-24 23:45 UTC58
already queued to it comes back to be answered or replayed, so an open racing a
5a52012c9b1datagen2026-09-24 23:45 UTC59
leave still gets a fresh actor
31ce2453c82fatagen2026-09-24 13:07 UTC60
0bfa3f46f0beatagen2026-09-26 09:12 UTC61
however an actor ends, short of the engine stopping, its typing goes out empty
0bfa3f46f0beatagen2026-09-26 09:12 UTC62
and each of its timelines sends `TimelineClosed`. so does a closed thread. a
0bfa3f46f0beatagen2026-09-26 09:12 UTC63
timeline that never sent a reset never sends a close either
0bfa3f46f0beatagen2026-09-26 09:12 UTC64
31ce2453c82fatagen2026-09-24 13:07 UTC65
opening sends `TimelineReset` on the stream before it answers. opening an
31ce2453c82fatagen2026-09-24 13:07 UTC66
already open room sends a fresh reset, so a second frontend gets a snapshot
31ce2453c82fatagen2026-09-24 13:07 UTC67
31ce2453c82fatagen2026-09-24 13:07 UTC68
sends, edits and replies run on the actor in order, so they reach the send
31ce2453c82fatagen2026-09-24 13:07 UTC69
queue in the order they were asked for. redactions, reactions and read
31ce2453c82fatagen2026-09-24 13:07 UTC70
receipts are network calls, so they run beside the actor and a slow one
31ce2453c82fatagen2026-09-24 13:07 UTC71
doesn't queue the room behind it. closing lets them finish rather than lie
31ce2453c82fatagen2026-09-24 13:07 UTC72
31ce2453c82fatagen2026-09-24 13:07 UTC73
threads belong to their room's actor. commands for a thread that's still
31ce2453c82fatagen2026-09-24 13:07 UTC74
opening wait behind the open, up to the actor's queue capacity
31ce2453c82fatagen2026-09-24 13:07 UTC75
31ce2453c82fatagen2026-09-24 13:07 UTC76
pagination runs one request at a time per timeline and emits `HistoryChanged`
31ce2453c82fatagen2026-09-24 13:07 UTC77
around each. the sdk remembers where history starts, we don't, because a gappy
31ce2453c82fatagen2026-09-24 13:07 UTC78
sync can unload it again
31ce2453c82fatagen2026-09-24 13:07 UTC79
5a52012c9b1datagen2026-09-24 23:45 UTC80
the actor's watchers are supervised, and a panic in any of them panics the
5a52012c9b1datagen2026-09-24 23:45 UTC81
actor. its command work isn't, a panicking redaction just answers `Interrupted`
5a52012c9b1datagen2026-09-24 23:45 UTC82
and gets logged
31ce2453c82fatagen2026-09-24 13:07 UTC83
31ce2453c82fatagen2026-09-24 13:07 UTC84
## timelines
31ce2453c82fatagen2026-09-24 13:07 UTC85
31ce2453c82fatagen2026-09-24 13:07 UTC86
`TimelineDiff::try_apply` refuses a diff whose indices don't fit your snapshot
31ce2453c82fatagen2026-09-24 13:07 UTC87
and leaves the snapshot alone. stop applying, `resync`, and carry on from the
31ce2453c82fatagen2026-09-24 13:07 UTC88
next `TimelineReset`. resync kills the old watcher before the new reset goes
31ce2453c82fatagen2026-09-24 13:07 UTC89
out, so no stale diff can land after it
31ce2453c82fatagen2026-09-24 13:07 UTC90
31ce2453c82fatagen2026-09-24 13:07 UTC91
`TimelineId` tells a room from a thread by its root event
31ce2453c82fatagen2026-09-24 13:07 UTC92
960ac0721079atagen2026-09-25 00:24 UTC93
every item is an event, a day divider, the read marker or the start. an event
960ac0721079atagen2026-09-25 00:24 UTC94
carries its sender with avatar and name ambiguity, and a `TimelineContent`
960ac0721079atagen2026-09-25 00:24 UTC95
saying what it actually is. messages keep their msgtype, membership and profile
960ac0721079atagen2026-09-25 00:24 UTC96
changes and the common room state changes get their own variants, and anything
960ac0721079atagen2026-09-25 00:24 UTC97
else is `OtherState` or `Other` with its type. nothing is flattened into english
960ac0721079atagen2026-09-25 00:24 UTC98
in a body field
960ac0721079atagen2026-09-25 00:24 UTC99
5a52012c9b1datagen2026-09-24 23:45 UTC100
thread receipts for a thread that isn't open go straight to the room, so
5a52012c9b1datagen2026-09-24 23:45 UTC101
marking a thread read works the same whether its room is on screen or not
5a52012c9b1datagen2026-09-24 23:45 UTC102
960ac0721079atagen2026-09-25 00:24 UTC103
replies carry the replied-to event once it's loaded. the watcher asks the sdk
960ac0721079atagen2026-09-25 00:24 UTC104
for any it hasn't got, once per event, since the sdk won't on its own
960ac0721079atagen2026-09-25 00:24 UTC105
960ac0721079atagen2026-09-25 00:24 UTC106
edit, redact and react take an `EventRef`, so your own message can be edited or
960ac0721079atagen2026-09-25 00:24 UTC107
reacted to before the server has echoed it back. redacting an unsent one just
960ac0721079atagen2026-09-25 00:24 UTC108
cancels it
960ac0721079atagen2026-09-25 00:24 UTC109
31ce2453c82fatagen2026-09-24 13:07 UTC110
## mutations
31ce2453c82fatagen2026-09-24 13:07 UTC111
31ce2453c82fatagen2026-09-24 13:07 UTC112
membership, moderation, power levels, room creation and account data writes go
31ce2453c82fatagen2026-09-24 13:07 UTC113
through one keyed fifo scheduler. same room, same alias, same dm partner or
31ce2453c82fatagen2026-09-24 13:07 UTC114
same account data type run in order, everything else runs at once.
31ce2453c82fatagen2026-09-24 13:07 UTC115
`create_direct` hands back the existing dm when there is one
31ce2453c82fatagen2026-09-24 13:07 UTC116
31ce2453c82fatagen2026-09-24 13:07 UTC117
notifications and encryption each get one serial worker. the encryption worker
31ce2453c82fatagen2026-09-24 13:07 UTC118
owns the verification controller outright
31ce2453c82fatagen2026-09-24 13:07 UTC119
31ce2453c82fatagen2026-09-24 13:07 UTC120
power level changes build one state event from the local mapping, since the
31ce2453c82fatagen2026-09-24 13:07 UTC121
sdk's own patcher is private
31ce2453c82fatagen2026-09-24 13:07 UTC122
31ce2453c82fatagen2026-09-24 13:07 UTC123
## media
31ce2453c82fatagen2026-09-24 13:07 UTC124
31ce2453c82fatagen2026-09-24 13:07 UTC125
media is a read. `ClientHandle::media` takes a `MediaId` a retained timeline
31ce2453c82fatagen2026-09-24 13:07 UTC126
handed you, `mxc_media` takes any plain mxc uri. both share one bounded
5a52012c9b1datagen2026-09-24 23:45 UTC127
download path with the byte cap the sdk's own download lacks, an hour's total
5a52012c9b1datagen2026-09-24 23:45 UTC128
deadline instead of the sdk client's thirty seconds, and a minute's patience
5a52012c9b1datagen2026-09-24 23:45 UTC129
for a stalled stream. concurrent asks for the same bytes share one flight.
5a52012c9b1datagen2026-09-24 23:45 UTC130
a thumbnail the server won't make falls back to the file itself.
5a52012c9b1datagen2026-09-24 23:45 UTC131
`MediaId` parses from a string, since a web client has to round trip it
31ce2453c82fatagen2026-09-24 13:07 UTC132
31ce2453c82fatagen2026-09-24 13:07 UTC133
the cache holds plaintext, keyed like the sdk keys it, so the sdk and macltok
5a52012c9b1datagen2026-09-24 23:45 UTC134
can read each other's entries. that's how your own encrypted uploads come back.
5a52012c9b1datagen2026-09-24 23:45 UTC135
the sdk keys plain and encrypted sources alike, so a plain event pointing at
5a52012c9b1datagen2026-09-24 23:45 UTC136
someone's encrypted file can leave ciphertext in the cache. an encrypted read
5a52012c9b1datagen2026-09-24 23:45 UTC137
checks the cached bytes against the file's hash and decrypts them if they match
31ce2453c82fatagen2026-09-24 13:07 UTC138
31ce2453c82fatagen2026-09-24 13:07 UTC139
media ids are registered as timelines render and forgotten when their timeline
31ce2453c82fatagen2026-09-24 13:07 UTC140
closes, least recently seen first once the cap is hit
31ce2453c82fatagen2026-09-24 13:07 UTC141
5a52012c9b1datagen2026-09-24 23:45 UTC142
uploads are commands that answer once the send queue has them. progress only
5a52012c9b1datagen2026-09-24 23:45 UTC143
goes out on a room's own send queue channel, so each room that uploads gets a
5a52012c9b1datagen2026-09-24 23:45 UTC144
forwarder, subscribed before the upload is queued and restarted for uploads the
0bfa3f46f0beatagen2026-09-26 09:12 UTC145
sdk resumes from last time. everything but progress reaches the client-wide
0bfa3f46f0beatagen2026-09-26 09:12 UTC146
channel, so one watcher there follows every attachment in the queue and ends
0bfa3f46f0beatagen2026-09-26 09:12 UTC147
each with one `MediaUploadFinished`. sent, cancelled, its room forgotten, or
0bfa3f46f0beatagen2026-09-26 09:12 UTC148
missed when that channel overflowed at the wrong moment, since then there's no
0bfa3f46f0beatagen2026-09-26 09:12 UTC149
knowing which. a failure isn't an ending, a wedged upload can still be retried.
0bfa3f46f0beatagen2026-09-26 09:12 UTC150
uploads don't belong to a room's actor, so closing the room leaves them be
31ce2453c82fatagen2026-09-24 13:07 UTC151
31ce2453c82fatagen2026-09-24 13:07 UTC152
## sessions and secrets
31ce2453c82fatagen2026-09-24 13:07 UTC153
31ce2453c82fatagen2026-09-24 13:07 UTC154
`Session::login_password`, `begin_oauth` and `restore` share one client builder
62fe32759529atagen2026-09-26 08:50 UTC155
with an encrypted store, refresh tokens and threads. the store is sqlite
62fe32759529atagen2026-09-26 08:50 UTC156
natively and indexeddb in a browser. secret-bearing inputs don't derive `Clone`
31ce2453c82fatagen2026-09-24 13:07 UTC157
31ce2453c82fatagen2026-09-24 13:07 UTC158
the caller owns the saved record. save `Session::record()` after login and
31ce2453c82fatagen2026-09-24 13:07 UTC159
replace it atomically with `ClientHandle::session_record()` on every
31ce2453c82fatagen2026-09-24 13:07 UTC160
`SessionTokensChanged`. logout and a hard rejection kill the record and the
31ce2453c82fatagen2026-09-24 13:07 UTC161
store. a soft logout keeps the store for a same-device login, or the e2ee keys
31ce2453c82fatagen2026-09-24 13:07 UTC162
go with it. a bare `Stopped` kills nothing. one store directory per login
31ce2453c82fatagen2026-09-24 13:07 UTC163
960ac0721079atagen2026-09-25 00:24 UTC164
## room lists, spaces and profiles
960ac0721079atagen2026-09-25 00:24 UTC165
960ac0721079atagen2026-09-25 00:24 UTC166
`RoomSummary` has what a room list row needs without a second query. topic,
960ac0721079atagen2026-09-25 00:24 UTC167
alias, member counts, heroes for nameless rooms, the inviter, where an upgraded
960ac0721079atagen2026-09-25 00:24 UTC168
room went, a latest event preview, the joined spaces listing it, and for a
960ac0721079atagen2026-09-25 00:24 UTC169
space the children it lists
960ac0721079atagen2026-09-25 00:24 UTC170
960ac0721079atagen2026-09-25 00:24 UTC171
parents come from one lazily built `SpaceService` shared by every handle.
960ac0721079atagen2026-09-25 00:24 UTC172
children come straight from the space's local state, joined or not.
960ac0721079atagen2026-09-25 00:24 UTC173
`space_hierarchy` pages through the server's view for browsing rooms you
960ac0721079atagen2026-09-25 00:24 UTC174
haven't joined, and holds its place between pages
960ac0721079atagen2026-09-25 00:24 UTC175
960ac0721079atagen2026-09-25 00:24 UTC176
`own_profile` and `user_profile` read profiles. name and avatar changes are
960ac0721079atagen2026-09-25 00:24 UTC177
commands, and uploading an avatar gets the same byte cap as any upload
960ac0721079atagen2026-09-25 00:24 UTC178
31ce2453c82fatagen2026-09-24 13:07 UTC179
## notifications and room data
31ce2453c82fatagen2026-09-24 13:07 UTC180
31ce2453c82fatagen2026-09-24 13:07 UTC181
the notification client is built lazily and shares the engine's sync service.
31ce2453c82fatagen2026-09-24 13:07 UTC182
sdk ui types stay behind the boundary
31ce2453c82fatagen2026-09-24 13:07 UTC183
31ce2453c82fatagen2026-09-24 13:07 UTC184
`rooms` normalises on demand with bounded concurrency and sorts by latest event,
31ce2453c82fatagen2026-09-24 13:07 UTC185
then name, then id. `RoomsChanged` is an invalidation, coalesced so one sync
0bfa3f46f0beatagen2026-09-26 09:12 UTC186
touching fifty rooms is one event. a left room stays in the list with its
0bfa3f46f0beatagen2026-09-26 09:12 UTC187
membership until it's forgotten. push rule changes never touch room info, so
0bfa3f46f0beatagen2026-09-26 09:12 UTC188
`NotificationSettingsChanged` brings a `RoomsChanged` along for the modes in
0bfa3f46f0beatagen2026-09-26 09:12 UTC189
the summaries
31ce2453c82fatagen2026-09-24 13:07 UTC190
31ce2453c82fatagen2026-09-24 13:07 UTC191
## verification
31ce2453c82fatagen2026-09-24 13:07 UTC192
5a52012c9b1datagen2026-09-24 23:45 UTC193
`Accept`, `Confirm`, `Reject` and `Cancel`. a request another device sends
5a52012c9b1datagen2026-09-24 23:45 UTC194
shows up as `Incoming` and waits for `Accept`, or `Cancel` to turn it down. one
5a52012c9b1datagen2026-09-24 23:45 UTC195
is only taken up while nothing else is in flight. reject tells the other side
5a52012c9b1datagen2026-09-24 23:45 UTC196
the emoji didn't match. the watchers subscribe before they look at the current
5a52012c9b1datagen2026-09-24 23:45 UTC197
state, since the sdk only reports what changes after you ask. the watcher and
5a52012c9b1datagen2026-09-24 23:45 UTC198
the action paths claim the terminal event, so a racing
31ce2453c82fatagen2026-09-24 13:07 UTC199
cancel can't turn `Done` into `Cancelled`
31ce2453c82fatagen2026-09-24 13:07 UTC200
31ce2453c82fatagen2026-09-24 13:07 UTC201
## public model
31ce2453c82fatagen2026-09-24 13:07 UTC202
31ce2453c82fatagen2026-09-24 13:07 UTC203
owned ruma ids and typed data wherever there's a stable shape, `Raw` where
31ce2453c82fatagen2026-09-24 13:07 UTC204
arbitrary content has to survive. anything expected to grow is
31ce2453c82fatagen2026-09-24 13:07 UTC205
`#[non_exhaustive]`. `Engine::from_client` stays public for people who built
31ce2453c82fatagen2026-09-24 13:07 UTC206
their own client