ditching redis altogether?

[nothingmuch]

Currently we rely on redis for the directory storage. Although is a decent choice of backend, it still presents some friction:

1. for development, the use of test containers, implicit dependency on docker
2. for operating a directory, same as (1) with additional considerations (e.g. security, monitoring)
3. in the directory implementation, the use of pubsub mechanism, and lack of explicit pruning of storage represents complexity and potential future complexity that is arguably avoidable

The main advantage of using redis this way is that if the directory is upgraded, ongoing sessions aren't lost, and in principle with blue/green style rollover deployment, all interruptions could be avoided entirely.

In order to bring this to a more "production ready" form, pruning is also relatively straightforward to configure, using the maxmemory configuration and allkeys-lru, for example, though arguably it'd be more appropriate for the directory implementation to set the expire field to some reasonable value.

Alternatively, an in memory key value store in the directory itself whose implementation relies on strong assumptions about payload size limits and the desired monotonicity semantics (e.g. idempotent writes, or append only behavior, in particular re persistence) seems nicer to me: fewer dependencies, simpler pubsub signalling, no long lived resources to track (e.g. the pubsub topics may also leak in certain cases).

Personally I feel that just for improving dev UX during testing this seems sufficiently motivated even if it's not a full replacement for redis, but rather both the existing redis implementation and this proposed alternative (perhaps without persistence) were two implementations of a shared db trait, but I thought I'd bring up this slightly more radical idea of relying entirely on a bespoke storage backend for discussion, as this thought has been nagging at me for a few weeks now.

See also #419, #484, #210

[DanGould]

How much work would a bespoke storage backend be and where might we hit snags? It seems like "bespoke" is even a bit overkill of a word since our storage is not incredibly complicated. If we're going to boot redis anyhow, I don't see big reasons not to do it the way you want it done. But I do wonder if we're going to run into complexity when we want to do more with the storage for multiparty stuff.

[nothingmuch]

if the idea is not offensive i think the simplest thing is to just try to implement it and see how we like it? i'm happy to give it a go after i clear my backlog of more important things

i don't foresee much complications with multiparty stuff, if anything that'd make it easier to reason about IMO

[DanGould]

sounds good to me