Currently Orbit saves all its data to one global directory. It would be better if the data directory was namespace per user.
Instead of:
~/Library/Application Support/orbit/
Do:
~/Library/Application Support/orbit/<userId>/
This requires changes to the startup sequence in index.js and in the UI so that we first display the login window, user enters their name, and after that we boot up the IPFS daemon. Currently we first boot up the daemon, then login.
The upside of this change is that the login screen will appear much faster than it currently does making the UX slightly better in terms of the user getting to actionable content.
The downside is that there will be a loading period between user pressing "login" and getting to the main view ("connected"). This may be reduced to a very short period if the daemon startup time can be optimized.
We will need to take a look at how go-ipfs starts up as currently it can take anything up to 10 seconds to reach "Daemon started" state. Apparently this is due to connecting to the bootstrap nodes and after that moving to "started" state. There was discussion that this can be changed so that the bootstrapping happens after the daemon's state has been set to "started". cc @whyrusleeping @jbenet
Currently Orbit saves all its data to one global directory. It would be better if the data directory was namespace per user.
Instead of:
~/Library/Application Support/orbit/Do:
~/Library/Application Support/orbit/<userId>/This requires changes to the startup sequence in index.js and in the UI so that we first display the login window, user enters their name, and after that we boot up the IPFS daemon. Currently we first boot up the daemon, then login.
The upside of this change is that the login screen will appear much faster than it currently does making the UX slightly better in terms of the user getting to actionable content.
The downside is that there will be a loading period between user pressing "login" and getting to the main view ("connected"). This may be reduced to a very short period if the daemon startup time can be optimized.
We will need to take a look at how go-ipfs starts up as currently it can take anything up to 10 seconds to reach "Daemon started" state. Apparently this is due to connecting to the bootstrap nodes and after that moving to "started" state. There was discussion that this can be changed so that the bootstrapping happens after the daemon's state has been set to "started". cc @whyrusleeping @jbenet