| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is the [recommended] adapter for a single-page app. That's approximately how I expect to deploy the UI.
[recommended]: https://kit.svelte.dev/docs/single-page-apps
|
| |
|
|
| |
They're badly styled and don't do anything yet anyway.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
For the styling.
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
It is deliberate that the expire() functions do not use them. To avoid races, the transactions must be committed before events get sent, in both cases, which makes them structurally pretty different.
|
| | |
| |
| |
| |
| |
| | |
This separates the code that figures out what happened to an entity from the code that represents it to a user, and makes it easier to compute a snapshot at a point in time (for things like bootstrap). It also makes the internal logic a bit easier to follow, since it's easier to tell whether you're working with a point in time or with the whole recorded history.
This hefty.
|
| | | |
|
| | |
| |
| |
| | |
This helped me discover an organizational scheme I like more.
|
| | | |
|
| | |
| |
| |
| | |
This is primarily renames and repackagings.
|
| | |
| |
| |
| | |
(This is part of a larger reorganization.)
|
| | |
| |
| |
| | |
sequence.
|
| | |
| |
| |
| | |
Per-channel event sequences were a cute idea, but it made reasoning about event resumption much, much harder (case in point: recovering the order of events in a partially-ordered collection is quadratic, since it's basically graph sort). The minor overhead of a global sequence number is likely tolerable, and this simplifies both the API and the internals.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
At least message-type ones, and at least without styling or memory-limit
concerns.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
This (a) reduces the amount of passing secrets around that's needed, and (b) allows tests to log out in a more straightforwards manner.
Ish. The fixtures are a mess, but so is the nomenclature. Fix the latter and the former will probably follow.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
expires.
When tokens are revoked (logout or expiry), the server now publishes an internal event via the new `logins` event broadcaster. These events are used to guard the `/api/events` stream. When a token revocation event arrives for the token used to subscribe to the stream, the stream is cut short, disconnecting the client.
In service of this, tokens now have IDs, which are non-confidential values that can be used to discuss tokens without their secrets being passed around unnecessarily. These IDs are not (at this time) exposed to clients, but they could be.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following values are considered confidential, and should never be logged, even by accident:
* `Password`, which is a durable bearer token for a specific Login;
* `IdentitySecret`, which is an ephemeral but potentially long-lived bearer token for a specific Login; or
* `IdentityToken`, which may hold cookies containing an `IdentitySecret`.
These values are now wrapped in types whose `Debug` impls output opaque values, so that they can be included in structs that `#[derive(Debug)]` without requiring any additional care. The wrappers also avoid implementing `Display`, to prevent inadvertent `to_string()`s.
We don't bother obfuscating `IdentitySecret`s in memory or in the `.hi` database. There's no point: we'd also need to store the information needed to de-obfuscate them, and they can be freely invalidated and replaced by blanking that table and asking everyone to log in again. Passwords _are_ obfuscated for storage, as they're intended to be durable.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Trying to reliably do expiry mid-request was causing some anomalies:
* Creating a channel with a dup name would fail, then succeed after listing channels.
It was very hard to reason about which operations needed to trigger expiry, to fix this "correctly," so now expiry runs on every request.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It now includes events for all channels. Clients are responsible for filtering.
The schema for channel events has changed; it now includes a channel name and ID, in the same format as the sender's name and ID. They also now include a `"type"` field, whose only valid value (as of this writing) is `"message"`.
This is groundwork for delivering message deletion (expiry) events to clients, and notifying clients of channel lifecycle events.
|
| | | |
|
| | |
| |
| |
| |
| | |
It's not robust, and it's not yet able to handle multiline or rich
input. We'll get there.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
Using Svelte.
No tests, no linting, yet.
This is just starting to get familiar with things.
You'll still have to run the dev server and the dev client builder each
in their own terminals.
Enjoy!
|
| |
|
|
| |
This change makes the identity cookie available throughout `/api`.
|
| |
|
|
| |
This also has the happy effect of removing an unwrap. This feels like a more coherent way of achieving the same result.
|
| |
|
|
| |
I had no idea `std` included a `matches!` macro, and I feel we're better off using it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
