Prompt to connect on first startup.

[Dokument]

When a user is first starting bitmessage (no keys.dat file) their client immediately connects to the network using the default settings. If a user wishes to use bitmessage with a proxy (including Tor) then they would have to disable their internet connection before starting bitmessage, make the changes, stop bitmessage, enable their internet connection, then start bitmessage.

A notification window stating "This is the first time running Bitmessage, would you like to: Connect using the default settings, Connect using custom settings

Depending on which choice is selected, the appropriate action would occur.

Chosing "Connect using custom settings" could do nothing more than prevent bitmessage from connecting to the network. Then the user could make their changes and restart bitmessage at which point everything would happen the way they want it to.

This gives an appropriate time and place for the user to set their proxy settings, define their own node(s) for bootstrapping, select WAN or LAN operation and other future settings that are included.

[aalexgabi]

+1

[AyrA]

While this is an issue and can be fixed with the proposed method, misconfiguration of network firewalls is not a bitmessage issue. People should configure firewalls in a way, which only lets applications communicating with the internet, if they allow to do so.

[Dokument]

I agree that it is not the responsibility of Bitmessage to keep a user from misconfiguring their firewall. However, this is a very easy thing for us to implement, does not intrude on an experienced/advanced user, and helps out those that are not up to par with current security standards. Also it would be up to the user to find the bootstrap server ip addresses and the DNS bootstrap servers and keep that list updated in their firewall (assuming they change) and this does seem like a Bitmessage issue.

Another implementation method would be to have the dialogue box say "Would you like to connect to the Bitmessage network using the default settings? Choosing no requires you to restart Bitmessage in order to connect. Please make all network related changes before you restart." Then it could be a simple "Yes" or "No" selection.

It could even have an included warning "Warning: Using the default settings shares your public IP address with the rest of the network."

[jlgaddis]

I agree that this is an important feature that absolutely should be implemented.

When I first ran BitMessage, I scrambled to kill it as soon as I realized that it was communicating over the network. I then reconfigured it and got it to run over Tor.

Had I been an individual in a third-world country subject to government monitoring, however, it's quite possible that the traffic that had already sent and received would be enough to identify me to the government and put me at risk.

[DivineOmega]

@jlgaddis I think you make a very good point at the end of your comment. This is especially true with Bitmessage at the moment, as it currently does not have any transport layer encryption, making Bitmessage specific traffic reasonably easy to identify.

Perhaps this could be implemented as some form of 'Welcome to Bitmessage' and/or 'Getting Started' message prior to the network connection(s) being established.

[Dokument]

Even with TLS it would be nice to configure Bitmessage before it connects to the network. Mainly for new users and those wishing to utilize the security features built into the client. Also, this method accomplishes that without taking away from the user experience or making it more difficult to use.

[Atheros1]

Ok, I will add the feature.

[Dokument]

Consideration should be taken if users use a non-gui interface. I suppose the best answer would be checking if daemon mode is enabled.

Bitmessage would interpret it like this: Startup, check for keys.dat, check for daemon, if daemon = true, use the network settings, if no specified network settings, use default.

An alternative idea would be passing an argument to bitmessagemain (or .exe) such as "python bitmessagemain.py daemon" since this would only be used for flagging daemon as true so not necessary every time. Again, settings in keys.dat should dictate network settings (if the settings exist)

[grant-olson]

This can be closed, right?

[jlgaddis]

@grant-olson It looks like this feature was added in commit 350e8d6 (with some later refinements) so I think #278 can be marked closed. Thanks!