Chat history but in SQLite

[Python1320]

Unfortunately coded with Opencode Big Pickle as an experiment so I will still need to comb through everything and squash the loading problem, but it works:

Tables:

-- global, player, admin, etc in name, id is just autoincrement
CREATE TABLE ec_channels (
	id INTEGER PRIMARY KEY AUTOINCREMENT,
	name TEXT NOT NULL UNIQUE
)

-- actual history, mapped via channel_id so we save at least somewhat on storage space. probably not worth it...
CREATE TABLE ec_history (
	id INTEGER PRIMARY KEY AUTOINCREMENT,
	channel_id INTEGER NOT NULL, 
	data TEXT NOT NULL,
	created_at INTEGER NOT NULL
)

Concerns:

1. There are no old file migrations
2. the old files will be left as is for now until I can be sure this new one works.
3. Broken SQLite (on startup or during operation) should not take down easychat. I have not tested this yet.

Future:

1. should add history length config and whatnot
2. Maybe also store chat input history here (lua commands at least)

[JustMrPhoenix]

seggs

[Earu]

@Python1320 do you save steamid information? What about player information in general, like what happens if I click on someone's name in the history, do the correct menus show up?

[Earu]

Additionally one of the features of the current history was that it was easily accessible/readable in the data folder, i think if we're using sqlite, there should at least be a way to see your histories somewhere in settings and/or to export them as .txt

[Python1320]

TLDR of below: Same functionality as before: Only colors and text are stored. for PMs steamid is still stored in the other table. No links are stored, though they could be with the extensible json format.

I thought the whole history thing was work in progress as I was always getting garbled data. Maybe it is just the legacy richtext 🤔

I couldn't validate the old because it didn't work for me (I suspect it is because easychat is opening the file for reading and writing at the same time).

As far as I understood the richtext history code, it doesn't store clickable links, etc either and we just relied on the text having steamids instead of links containing the metadata.
Or you mean the PM system? Only towards the end I realized we have some custom PM tab instead of easychat's PM tab so I will need to check that behavior also before this could ever be merged.

SQlite:
I'll probably rewrite back into jsonl as this data doesn't really benefit from relational linkage as is at least. It sounded better in my head with easy old message purging and whatnot (just drop old rows!) instead of fixing the current implementation.

Next idea for another PR related to this so I don't forget what triggered staring at the code to begin with: chacha20+maybe poly encrypted per-server PMs/conversations so other servers cannot read them (clients receive decryption key from servers, "unique" per client, not sure if we can do better without binary modules).