Bring back ADCS

[smallketchup82]

I never really used it since it was rather premature, but it was a good idea in practice (you'd have an always up-to-date dataset). We should bring it back, but I'm a little split on implementation.

I would want ADCS to be a class. But at the same time, I don't want galaxygpt to have a reference dependency on dataset-assistant, since it's meant to be a utility.

But at the same time, I don't want to have to copy-paste the code from dataset-assistant into galaxygpt.

I can only see a couple ways of properly implementing this:

1. Make ADCS a seperate project. Have it depend on dataset-assistant. Maybe add quartz.net to it for scheduling.
2. Decouple the dataset creation code from dataset-assistant, put it in galaxygpt, then have dataset-assistant depend on galaxygpt's DatasetCreator class. And bake ADCS into galaxygpt.
3. Combine both solutions. Have ADCS be a seperate project, but instead of referencing dataset-assistant, decouple the dataset creation logic from dataset-assistant and put it in galaxygpt. Then have ADCS depend on galaxygpt's DatasetCreator class.

[smallketchup82]

as an update to this, i had long ago added the db infra needed for this. previously the mariadb database that comet uses was only exposed via unix socket, not tcp/ip. this meant that only really comet could access mariadb, nothing else.

a while ago i made a change where i enabled tcp/ip alongside unix socket. the galaxypedia connects through the socket since it's on comet, and benefits from the added speed and security of it. on the other hand, i used ufw to allow tailscale access to the mariadb port, but nothing else.

meaning the tailscale network that i run should provide access to to the database, and galaxygpt (which is on ketchupdesktop) should be able to communicate to the database over wireguard where communication is end-to-end encrypted.

the only thing that's left is to add in the galaxygpt-sided infrastructure. i believe that it'd be better to go route 2 from the OP