| Commit message (Collapse) | Author | Age |
| |
|
|
| |
This - in passing - fixes the problem where the client failed to subscribe after logging in, by causing the whole subscription process to be re-run when returning to the main interface.
|
| | |
|
| |
|
|
| |
We now (try to) use the identity cookie in `/ch/:channel`. This will not work, because the cookie's path doesn't include `/ch/`.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The original version of this migration happened to work correctly, by accident, for databases with exactly one login. I missed this, and so did Kit, because both of our test databases _actually do_ contain exactly one login, and because I didn't run the tests before committing the migration.
The fixed version works correctly for all scenarios I tested (zero, one, and two users, not super thorough). I've added code to patch out the original migration hash in databases that have it; no further corrective work is needed, as if the migration failed, then it got backed out anyways, and if it succeeded, you fell into the "one user" case.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Operational experience with the server has shown that leaving the backup in place is not helpful. The near-automatic choice is to immediately delete it, and the server won't start until it has been deleted. If the backup restore succeeded, then we know the user has a copy of their database, since the sqlite3 online backups API promises to make the target database bitwise-identical to the source database, so there's little chance the user will need a duplicate.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
This is a bit easier to compute, and sets us up nicely for pulling message boot out of the `/api/boot` response entirely.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This will make it much easier to slot in new event types (login events!).
|
| | |/
| |
| |
| | |
This structure didn't accomplish anything and made certain refactorings harder.
|
| | |
| |
| |
| |
| | |
I would love to make the whole-thing container 100vh, and let the row of
the interface sort out its own height. I will, eventually, I guess.
|
| | |
| |
| |
| | |
Maybe this isn't ideal, but whatever.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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!
|
| | | | | | | |
|