The only reason we accepted a client was that so we have access
to the next message id when we need it.
So let's accept an id provider function instead.
The interface should not contain things that aren't the API of the
storage interface.
Further, rename ISqliteMessageStorage to SearchableMessageStorage,
as that's also an implementation detail.
We'll never have a second sqlite backend, so the name seems
strange.
TL is stupid and doesn't wait for message{Provider,Storage} to
settle before it starts using the store.
While this should be fixed globally, we can hack around the problem
by pushing everything onto the call stack and hope that we'll eventually
finish the setup before we blow the stack.
Message stores are more complicated that a sync "fire and forget"
API allows for.
For starters, non trivial stores (say sqlite) can fail during init
and we want to be able to catch that.
Second, we really need to be able to run migrations and such, which
may block (and fail) the activation of the store.
On the plus side, this pushes error handling to the caller rather
than the stores, which is a good thing as that allows us to eventually
push this to the client in the UI, rather than just logging it in the
server on stdout
When a URL is prefixed with a TLS scheme, we should make sure
that the remote provides a valid cert, even just for prefetches.
Else MITM of such a site is trivial.
This probably breaks some people with self signed cert, but the
age where that was acceptable is past. We have free CAs now like
Let's Encrypt.
The message was ordered the wrong way in the TS rewrite.
Old:
+bookworm sent a CTCP request: "chadler" to version
New:
+bookworm sent a CTCP request: "version" to chadler
