I'll give that import script a try, thanks! It should be enough for my usecase, don't need to push logs from the client, and agreed having soju look around in the filesystem on a clients' request is not good.

Looking at the database providers, StoreMessage seems to have a "ON CONFLICT DO NOTHING,). Does this mean I should be able to import incrementally, as it'll skip over existing entries?

On another note, I've been using weechat, and its logs. Would you be up to a change adding parsing for these, and a flag to the import script?

irc.server.xxx.tls_cert is about client certificates, that the client (Soju in that case) uses to identify with the IRC server.

Some IRC servers issue client certificates, and this issue is about being able to configure Soju with these certs without manually poking in the database.

While we have CHATHISTORY to query history, it's not yet possible to import history, potentially generated by another client / bouncer, before soju was used.

It might be possible to do this simply by inserting into the the database directly, but it'd probably prefer a sojuctl command. It could take znc syntax logs, so in tandem with https://codeberg.org/emersion/chathistorysync this could also be used to migrate logs from one bouncer to another.

You're right - found https://lists.sr.ht/~sircmpwn/aerc/patches/8864 now aswell, it indeed uses the workers for threading. I'll give it a try, and will also take a look at adding notmuch support :-)

I'd also be very interested in a threaded view. However, I don't think assembling threads should be done client-side.

IMAP seems to support threading, and backends like notmuch are also probably much faster when loading threads or displaying query results in threaded view.