| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
| |
The client now takes an initial snapshot from the response to `/api/boot`, then picks up the event stream at the immediately-successive event to the moment the snapshot was taken.
This commit removes the following unused endpoints:
* `/api/channels` (GET)
* `/api/channels/:channel/messages` (GET)
The information therein is now part of the boot response. We can always add 'em back, but I wanted to clear the deck for designing something more capable, for dealing with client needs.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |\ \ |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
At least message-type ones, and at least without styling or memory-limit
concerns.
|
| | |\ \ \ |
|
| | | | | | |
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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!
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The unsafe code still exists, but I have more faith in the rusqlite authors than in myself to ensure that the code is correct.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This was motivated by Kit and I both independently discovering that sqlite3 will happily partially apply migrations, leaving the DB in a broken state.
|
| | |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The migration path from the original project inception to now was complicated and buggy, and stranded _both_ Kit and I with broken databases due to oversights and incomplete migrations. We've agreed to start fresh, once.
If this is mistakenly started with an original-schema-flavour DB, startup will be aborted.
|
| | |_|_|/
|/| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
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.
|
| | |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|