Ferdi: Store user data locally

[vantezzen]

As suggested by @bittner:

I've seen performance issues today as the application tried to connect to the Franz server, but that was seemingly under load. The result of this was that my accounts weren't loaded, hence I couldn't use the application.
A solution that would make Franz more resilient would be to cache the account settings locally, load them when starting up, and then only connect to the Franz server to sync with the settings stored online. This way the Franz server could also go into maintenance mode or be totally offline for longer, without users being severely affected. The application could sync changes to the settings or the account as soon as the Franz server shows up again.
This approach would both make Franz more resilient (aka stable) and available offline without any separate business logic (technically, for free). Any thoughts?

https://github.com/meetfranz/franz/issues/1614#issuecomment-532673612

I doubt that Franz itself will implement such a feature, it seems like Franz only tries to get more and more dependent on its servers.

Storing user data (including services, workspaces etc.) locally would also greatly help implement #5 as that feature would also require user data to be stored locally.

Related Franz issues: franz#1542

[bittner]

The reason why I posted the above in the Franz issue tracker was to encourage a valuable enhancement that would significantly contribute to Franz' reputation as "good desktop software". That, in turn, we on the free fork would profit is probably obvious. Having said that, I still hope my feature suggestion stimulates someone, potentially in Vienna, Austria.

And yes, if such a feature is implemented #5 is nothing more than a toggle in the settings, labelled "Use a Ferdi server" (to sync your account data), which may be off by default.

[vantezzen]

Yes, I also hope that Franz itself gets this feature but at this point I highly doubt that they add a feature that lowers Franz's dependence on their servers.
This is why I created this feature request here. We can see if Franz's developers respond to your original comment and just keep this issue open while we wait for that.

[Gaboris]

The main problem is that this has been brought up to the Franz devs several times. A few are actually by me, but so far all of them were shut down after a while by saying "it's a need feature".

Seeing how Ferdi suports custom servers I hope that that means we can run a local server on our machine and use that, but didn't have the time to check it yet.

[vantezzen]

@Gaboris yes you can do that. You can run a ferdi-server locally and change your server to http://localhost:3333.

This feature request would be another improvement to that, so that you eventually don't even have to run a server but Ferdi stores your data locally by itself.

[Gaboris]

@vantezzen Yeah that would be the best. Heck, Franz could also keep the login system and hash a key from that to encrypt the information for extra security.

Heck, the MOST bizarre thing is that when I brought up the idea to make the server sync a paid service so that users don't have to set-up their clients all the time on new machines and to lower their own costs they kept saying that the reason for binding everyone to their server is that they don't have to deal with extra requests.

Since we already have a local server option does anyone know what info does Franz even send to their servers? For a while I was worried that traffic is routed through their own servers for whatever reason, but that made no sense in the end for me.

[vantezzen]

@Gaboris To develop ferdi-server I needed to reverse-engineer what Franz is doing so here is an (uncomplete) list of things Franz is sending to its server:

• When registering: Your first- and last name, email and password (all things you provide when signing up)
• When creating a new service: The service and recipe name and the settings you pick (e.g. HTTP proxy settings, if you enable darkmode, custom URLs used (e.g. for slack or when creating a custom webpage service) and the custom icon you choose)
• When creating/editing workspaces: Workspace name and services inside the workspace

Additionally, it will send some basic information about Franz itself (version, platform, timezone and system language) with every call to the API.

It is pretty much just sending the data and settings you provide it, nothing unusual. It does _not_ send data from inside services (e.g. passwords or chat messages).
Additionally Franz will send some telemetry information to Google analytics (also, nothing unusual), but telemetry has been removed from Ferdi.
From a privacy standpoint, Franz itself doesn't send any too sensitive information to its servers (besides maybe your Slack URLs).

[Gaboris]

Wow well THAT is very reassuring to know. Thank you @vantezzen for that info. :)

[bittner]

The main problem is that this has been brought up to the Franz devs several times. A few are actually by me, but so far all of them were shut down after a while by saying "it's a need feature".

I believe, we can always place a PR in their repository. If they see a value they may merge it. And as the code base is more or less identical there shouldn't be much of additional work to do compared to doing the same thing in our repo. Let's think positive, and hope for the best! :+1:

[vantezzen]

I started working on this feature in the store-data-locally branch (especially with the 7fd5123 commit), but I currently can't get it to wait for the service store to get rehydrated from local storage.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please check if this issue is still relevant and please close it if it's not. This will make sure that our open issues are actually of use and reduce the list of obsolete issues. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Please check if this issue is still relevant and please close it if it's not. This will make sure that our open issues are actually of use and reduce the list of obsolete issues. Thank you for your contributions.