Ferdi: Make it optional to create an account

[bittner]

In the beginnings of Franz there was no need to create an account at meetfranz.com. We should make this optional again.

If people care about getting their accounts configured on several machines easily we may add an "import/export setting" feature as an alternative, or simply describe where the configuration is stored and how it can be transferred.

[bittner]

Related: https://github.com/meetfranz/franz/issues/1446 -- _Clickshaming_

Not sure if this remains in this code base.

[bittner]

Related: https://github.com/meetfranz/franz/issues/1211 -- _Make login optional when using only Franz free features_

[kytwb]

Thanks for paving the way to additional unlocking. I'll take care of these things as soon as I get some free time if nobody has come with a pull request.

[kytwb]

Related https://github.com/meetfranz/franz/issues/1614, https://github.com/meetfranz/franz/issues/71, https://github.com/meetfranz/franz/issues/429

[keunes]

Thanks for for working on Ferdi! Franz seems great, but it's sad you need an account that forces you to sync (which is what the webservices that I add to Franz are already for). Very interested in Ferdi if it could 'solve' that issue :)

[vantezzen]

Looks like we are might be finally making progress in implementing this feature request.

Yesterday I had the idea that instead of trying to implement permanent storage into every store Ferdi uses we could simply run a stripped-down version of ferdi-server in the background that handles storing the user data.
I now implemented this into the local-server branch and it seems to work. User data gets stored into "{FERDI_USER_PATH}/server.sqlite" and, as the stripped-down local server doesn't include any user management, you can simply click "Use Ferdi without an Account" to switch to the local server without needing to create an account.

What we'll still have to figure out is:

• [ ] Make the server compatible to multiple Ferdi instances running at once. The local server will start at port 45569. If a second Ferdi instance is starting it would currently crash as the server port is already occupied. Should we dynamically assign server ports? We could also run multiple Ferdi instances on one server instance, so we could implement a check for if a server is already running.
• [ ] How secure do we have to make the local server? Other applications _could_ access the Ferdi local server on localhost:45569 without needing authentification (as the local server doesn't implement any user authentification). How big is this threat and how can we secure the server?
• [ ] Make the server build-ready. Thus far I have only tested the server in development and never build it. We may find some issues when trying to build the application.

[Gaboris]

I think I actually had this idea about integrating the server into the client itself, but I'm not sure if I ever got around to mention it to anyone.

So yeah this is a nice idea @vantezzen and hope it works out.

If someone is running multiple Ferdi instances wouldn't those all need to be in their own folders? Or did you not mean separately installed ones, but are multiple processes from the same install location possible?

The thing I don't know if that .sqlite file will be plain text or at least encoded within? Is that the reason why accessing the server a question since only that's able to read the contents?

[vantezzen]

Ferdi (by default) always stores its data in the same folder so I meant multiple instances of the same Ferdi application. This is probably not a frequent use case, but Ferdi should still be able to handle this.

I don't think I understand your question to the SQLite file.
The server.sqlite file is a normal SQLite database file which could be read by any other program - but that is not something I am worrying about. The file is in your local filesystem and thus protected from outside access.
I was however questioning if there was anything we could do to secure the server. It already has CORS disabled and is rejecting API access from all requests, who's User Agent does not contain Ferdi, but someone here may know about more things we can do.

[keunes]

Happy to read there's some developments here :) I just wanted to chip in as a (potential) end-user: if there might be a risk other applications can access my personal messages through Ferdi, that doesn't sound very assuring. Then I would prefer to be required to set a password (with the username being the same for every installation, and dealt with in the background) to ensure my data is protected. I can also imagine such choice (with a clear explanation of the risks, downsides & benefits) would be presented to the user.

I don't know what the OP @bittner thinks - but for me the '_optional_ to create account' is creating an account with a third party website/platform - if the account would live locally I'm quite ok with that.

[vantezzen]

@keunes Thank you for your feedback.
I think I need to clarify: Exposing data from the internal server would not expose any of your messages content! The only thing the server would be exposing is the list of services and workspaces you have (e.g. a WhatsApp instance, a Discord instance and a Slack instance (including the slack URL)) but no login credentials, messages or other content. Those information are not stored via the internal server!
We do however still want to protect this list of your services as e.g. your Slack URL could be something you want to keep private. Additionally, as long as your computer uses it's build-in firewall, the internal server will only be accessible by applications on your computer - but those same applications could also directly access the file system to get this information, so the internal server itself shouldn't be a security loophole.

I am however no network security expert - this is why I asked if someone sees additional steps we need to take.

We could think about adding a password protection for the internal server.

[vantezzen]

I have now tested the internal server on my machine and everything seems to work fine. Ferdi still has some problems with running multiple instances at once but dynamic port switching is now implemented.

I have just created PR #131 to merge this feature into develop so we can create a beta build with this feature.
@kytwb Can you release a new beta as soon as the PR has completed its checks and is merged?

To use the local server feature you'll have to log out of your current account, then select "Use Ferdi without an Account" on the login screen. Optionally, you can import your data from another Franz or Ferdi server by visiting http://localhost:45569/import in your browser.

[bittner]

Wow! Awesome move!

Is the data not stored or cached locally? In a way that one could log out from the Franz server and directly use what is lying in the cache locally on one's machine?

And what happens when you start with Ferdi configuring all services locally, but then want to save your settings on a Ferdi or on Franz's server? Will that work, or will the settings be lost?

[vantezzen]

Unfortunately, the data is not stored or cached locally, so we can't simply use that data (#50 is not implemented yet). You can however import your data from your Franz account so you won't have to set up everything again.

There is currently no direct way of transferring the data to another server - that is something we could implement though.

[bittner]

But there is a server running locally now, IIUC, so in a certain sense data is stored locally yet. Doesn't this make #50 obsolete?

What about the impact on system resources? Does the local server have a noticeable impact?

[vantezzen]

The data is now stored locally inside a SQLite database located in the Appdata folder.
This is only the case if you set Ferdi to use the local server, the feature described in #50 is requesting to cache the response from an external server - this isn't possible with the internal server and storage solution.

In my tests, the impact on system resources by the internal server are low: In normal usage my Mac's Activity Monitor shows a CPU usage of 0% when idling and 3%-5% when being actively used by the client (meaning the client is also not idling). The RAM usage is around 30MB.
The internal server will only be started if you select to use it so there should be no impact on system resources when not using it.

[bittner]

I've successfully managed to log out and "Use Ferdi without an account" and import my services from the franzinfra server as mentioned above. :+1:

But it doesn't seem to be possible to switch back, i.e. enter the credentials of my Franz account to connect with the Franz server again. The settings keep saying, "You are using Ferdi without a server". Should I open a separate issue for that?

[vantezzen]

I'll implement that. For now, you can simply replace the text in the server setting ("You are using Ferdi without a server") with the Franz or Ferdi API to log back into a remote server.

Edit: Implemented via 7e332dc.

[vantezzen]

"In progess"? I think this feature is implemented now, isn't it? Just needs #149 to be fixed.

[kytwb]

My bad. Closing in favour of #149 then.