Adds a Cloud Config System

Hey there,

In this PR I will add a Cloud Config System:

• Load/Syncing Settings Data
• Deletion Option
• Cloud is open source: https://github.com/Wuemeli/goofcord-cloudserver

Please do not merge this yet as I want to add Client Side Encryption and make some Design changes to the Cloud Buttons

I've made the Design Changes. I will now implement Client Side Encryption.

I tried running GoofCord with your changes and

1. The cloud token is set to "favicon.ico"
2. It blows up cachedConfig by setting it to { cloudHost: 'https://goofcordcloud.wuemeli.com' } leading to all config parameters being missing and set to default.

That does not seem right

Try running from a clean GoofCord install

Interesting. In loadConfig() output straight from fs.readFileSync is { "cloudHost": "https://goofcordcloud.wuemeli.com" } Even though the file has different contents in reality.

I'm guessing you can't reproduce that

Cloud functionality seems to write to the settings.json file only with { cloudHost: 'https://goofcordcloud.wuemeli.com/' }, and then update it again with every setting as it should be. Can't find where that happens though

Ah found it

Weird. When i tested it it did override the current settings with all the settings from the cloud

Looking through the code in saveCloud() you make an array out of {key, value} objects and send that. What's the reason behind that? Why not just send it raw straight from cachedConfig?

I forgot to remove it, I was testing something before

Why do you store token in a separate file and not just in settings.json? Also tokens are regenerated on every authorization so that kind of defeats the purpose

I was testing a lot. At the end, we can store it in settings.json and just don't send it to the Cloud. The Idea there was to give the User the Ability to reset their Auth Token.

Never mind, silly brain moment, I forgor server generates a second token and how oauth works

I'm thinking if we are going to go the encryption route, why not encrypt the whole stringified JSON and store on the server as a string? Someone will of course eventually use the server to store funny cat pictures, but that would happen even without encryption/storing everything as a string.

Seems that it would result in an easier implementation both on the server and the client

Yeah, that would be easier

Do you want to do it, or should I implement this?

You can do it now if you want, or I can do it tomorrow

I don't really have that much time, so you can do it. Else you might need to wait 1–2 Days

Kay sure

Is there anything else I can add?

Not really. Only things left is to finish encryption, polish UX and it's ready to merge

Yayyy

Should i make the encryption and ux?

So I wanted to continue working on encryption, but when I attempted to load settings from (the public) cloud for a test the server returned { settings: { settings: "actual settings" } } which expectedly blew up the loading system. Definitely not a client error, and the server code seemed fine-ish, so I wanted to run the server locally to put up a bunch of debug logs everywhere. Well it turns out NixOS which I recently switched to doesn't provide binaries for MongoDB, so I spent a good hour looking at compile logs thinking of this image before deciding it would be more productive to hand this task over to you. So, yeah, would be cool if you looked into that.

This pr is kind of a blocker because I plan on making some big changes in settings/config system for the next release, and it would be nice to merge this as soon as possible and finish some minor stuff later. So the only essential thing left is to

1. make so cloud encryption password (and encryption passwords if password is empty) is excluded from settings that are sent to cloud
2. make so settings are not encrypted when password is empty (just base64'd)

So I wanted to continue working on encryption, but when I attempted to load settings from (the public) cloud for a test the server returned { settings: { settings: "actual settings" } } which expectedly blew up the loading system. Definitely not a client error, and the server code seemed fine-ish, so I wanted to run the server locally to put up a bunch of debug logs everywhere. Well it turns out NixOS which I recently switched to doesn't provide binaries for MongoDB, so I spent a good hour looking at compile logs thinking of this image before deciding it would be more productive to hand this task over to you. So, yeah, would be cool if you looked into that.

did you try to delete them? maybe it didnt overwrite

This pr is kind of a blocker because I plan on making some big changes in settings/config system for the next release, and it would be nice to merge this as soon as possible and finish some minor stuff later. So the only essential thing left is to

1. make so cloud encryption password (and encryption passwords if password is empty) is excluded from settings that are sent to cloud
2. make so settings are not encrypted when password is empty (just base64'd)

I don't have that much time. What if we merge this without encryption and when I have time (Most prob in 8 days) I can make the encryption and open a pr

Comment out encryption stuff for later use