Replace `channel` with `conversation` throughout the API.

This is a **breaking change** for essentially all clients. Thankfully, there's presently just the one, so we don't need to go to much effort to accommoate that; the client is modified in this commit to adapt, users can reload their client, and life will go on.

2 files changed, 2 insertions, 2 deletions

diff --git a/docs/developer/server/code-organization.md b/docs/developer/server/code-organization.md
index d17b604..3a691a2 100644
--- a/docs/developer/server/code-organization.md
+++ b/docs/developer/server/code-organization.md
@@ -6,7 +6,7 @@ Trust your gut, and reorganize to meet new needs. We've already revised this sch
 
 ## Topic modules
 
-High-level concerns are grouped into topical modules. These include `crate::channel`, `crate::events`, `crate::login`, and others. Those modules generally contain their own app types, their own repo types, their own extractors, and any other supporting code they need. They may also provide an interface to other modules in the program.
+High-level concerns are grouped into topical modules. These include `crate::conversation`, `crate::events`, `crate::login`, and others. Those modules generally contain their own app types, their own repo types, their own extractors, and any other supporting code they need. They may also provide an interface to other modules in the program.
 
 Most topic modules contain one or more of:
 
diff --git a/docs/developer/server/testing.md b/docs/developer/server/testing.md
index 8e87568..a3109cb 100644
--- a/docs/developer/server/testing.md
+++ b/docs/developer/server/testing.md
@@ -22,6 +22,6 @@ Prefer writing "flat" fixtures that do one thing, over compound fixtures that do
 
 Prefer role-specific names for test values: use, for example, `sender` for a login related to sending messages, rather than `login`. Fixture data is cheap, so make as many entities as make sense for the test. They'll vanish at the end of the test anyways.
 
-Prefer testing a single endpoint at a time. Other interactions, which may be needed to set up the scenario or verify the results, should be done against the `app` abstraction directly. It's okay if this leads to redundant tests (see for example `src/channel/routes/test/on_send.rs` and `src/events/routes/test.rs`, which overlap heavily).
+Prefer testing a single endpoint at a time. Other interactions, which may be needed to set up the scenario or verify the results, should be done against the `app` abstraction directly. It's okay if this leads to redundant tests (see for example `src/conversation/routes/test/on_send.rs` and `src/events/routes/test.rs`, which overlap heavily).
 
 Panicking in tests is fine. Panic messages should describe why the preconditions were expected, and can be terse.