summaryrefslogtreecommitdiff
path: root/src/channel/repo.rs
Commit message (Collapse)AuthorAge
* Cargo fmtOwen Jacobson2024-10-18
|
* Switch to blanking tombstoned data with null, not empty string.Owen Jacobson2024-10-18
| | | | | | | This accomplishes two things: * It removes the need for an additional `channel_name_reservation` table, since `channel.name` now only contains non-null values for active channels, and * It nicely dovetails with the idea that `null` means an unknown value in SQL-land.
* Retain deleted messages and channels temporarily, to preserve events for replay.Owen Jacobson2024-10-17
| | | | | | | | | | | | Previously, when a channel (message) was deleted, `hi` would send events to all _connected_ clients to inform them of the deletion, then delete all memory of the channel (message). Any disconnected client, on reconnecting, would not receive the deletion event, and would de-synch with the service. The creation events were also immediately retconned out of the event stream, as well. With this change, `hi` keeps a record of deleted channels (messages). When replaying events, these records are used to replay the deletion event. After 7 days, the retained data is deleted, both to keep storage under control and to conform to users' expectations that deleted means gone. To match users' likely intuitions about what deletion does, deleting a channel (message) _does_ immediately delete some of its associated data. Channels' names are blanked, and messages' bodies are also blanked. When the event stream is replayed, the original channel.created (message.sent) event is "tombstoned", with an additional `deleted_at` field to inform clients. The included client does not use this field, at least yet. The migration is, once again, screamingingly complicated due to sqlite's limited ALTER TABLE … ALTER COLUMN support. This change also contains capabilities that would allow the API to return 410 Gone for deleted channels or messages, instead of 404. I did experiment with this, but it's tricky to do pervasively, especially since most app-level interfaces return an `Option<Channel>` or `Option<Message>`. Redesigning these to return either `Ok(Channel)` (`Ok(Message)`) or `Err(Error::NotFound)` or `Err(Error::Deleted)` is more work than I wanted to take on for this change, and the utility of 410 Gone responses is not obvious to me. We have other, more pressing API design warts to address.
* Separate `/api/boot` into its own module.Owen Jacobson2024-10-05
|
* List messages per channel.Owen Jacobson2024-10-03
|
* Represent channels and messages using a split "History" and "Snapshot" model.Owen Jacobson2024-10-03
| | | | | | 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.
* Package up common event fields as InstantOwen Jacobson2024-10-02
|
* Retire top-level `repo`.Owen Jacobson2024-10-02
| | | | This helped me discover an organizational scheme I like more.
* Transmit messages via `/:chan/send` and `/:chan/events`.Owen Jacobson2024-09-13
|
* Remove the notion of "channel members."Owen Jacobson2024-09-11
| | | | | | This came out of a conversation with Kit. Their position, loosely, was that seeing scrollback when you look at a channel is useful, and since message delivery isn't meaningfully tied to membership (or at least doesn't have to be), what the hell is membership even doing? (I may have added that last part.) My take, on top of that, is that membership increases the amount of concepts we're committed to. We don't need that commitment yet.
* Support joining channels.Owen Jacobson2024-09-04
|
* Support leaving a channelOwen Jacobson2024-09-04
|
* Allow any login to create channels.Owen Jacobson2024-09-04