Windows has VolumeID like the old IBM systems. Maybe base the mechanics of security on the VolumeID and then you can use any drive letter.
Also for decades I have mounted mapped drives in the rough order of z, y, x, w etc for the very reasons given. So now I would have the problem. VolumeID solves this.
Great, this is much better. I was actually thinking about this before. Then a user can name it any label they want.
And if and when its ported to linux then you can use the mount name
Now we have this:
If you remove the drive, do you get the same one back when adding one under a letter?
And if so, must you use the original one or the latest one?
Nevermind, no delete button anymore, still may be usefull to know in case thereâs a corruption somewhere.
Perhaps you could do that with a Raspberry Pi Zero. A RPi Zero can be used as a USB device. If you set it up as an âEthernet Gadgetâ you get a network connection to the RPi through the USB port. Then the RPi could run a SAFE client and the computer could forward encrypted data from SAFE to be safely decrypted on the RPi that contains the credentials, while the RPi could expose the decrypted data as a network drive to the computer.
Nopes. The letter is not tied to the drive. The drive has a volume id, which is a base for its SAFENetwork credentials.
(itâs evolving)
When you add a drive you can choose any drive letter from the available ones. Those you already have in config, and the ones already mounted on your machine are not available. (If you were to mount a physical drive, then load your SAFE.NetworkDrive config and have a conflicting letter, youâd have to change its letter to mount it).
The volume id is derived from your password and a serial number, called VolumeNr.
(You could basically call VolumeId a composite key based on your password and VolumeNr.)
Every time you create a drive, it is given a VolumeNr from the current VolumeNrCheckpoint, which is then incremented and stored back to your user config.
The drive config includes among things: SAFENetwork credentialsDriveLetter, VolumeNr, VolumeId.
DriveLetter can be changed any time and affects nothing. Itâs just whatâs shown on your local machine.
So you can have a drive with letter F on machine 1, and at the same time, the same drive (i.e. volume id) with letter G on machine 2. Itâs the same data you access from both of them.
If you create drives from different machines, your local config will see different VolumeNrCheckpoint, but what happens is that as long as you are not leveled, when you add on the one that is behind, you are simply adding drives that already exist. I will have to work out what the best UI would be, might be option to add a specific version. This can be circumvented by just keeping a central account, where necessary drive info is stored. Iâm not sure I want to do that now, as the isolation between the drives is lessened by it. But that might change, especially considering that there might be other breaches in the isolation that we eventually find acceptable, which moves the red line, and just makes that specific precaution moot.
If you remove a drive from your config, you can add it back again. 
The principal is that you can just try all numbers you currently donât have, up to your current max number - in case you donât know which it was you removed. Now, what the best UI for this will be, thatâs still to find out.
All you ever need to remember is one password. (And naturally, it will have to be strong, all of that is a later topic, needing more details eventually from MaidSafe on mutability of âlogin packetsâ, as I think they were called.)
Iâd like to say about login credentials and secrets in general itâd be great to store the entropy securely rather than keys. This is because a) entropy can easily be converted to the keys required (eg ecdsa for bitcoin, ec25519 for SAFE etc) whereas keys cannot be reversed into entropy and b) entropy can easily be converted into a mnemonic or user-friendly representation for safe storage. Inter-network compatibility is going to be an important part of key management for all users, and the best way to manage it (I feel) is by storing entropy rather than keys.
Looks like SAFE.NetworkDrive is doing things the right way, and the point Iâm making is not at all related to this specific software. Just seemed like a good chance to pedal my agenda 
Thatâs right, the âpasswordâ is the entropy, which is used to generate a seed. Everything else is derived from it. But itâs placeholder logic for it now, needs to be refined.
Also, itâs confirmed that the BSOD was a bug in the driver. Dokan team are working on fixing it.
Perhaps it could have an option to autogenerate the password, or maybe even a BIP39 mnemonic, instead of having the user type one. User selected passwords will typically be insecure. Then it could display a message something like âKeep your password safely in a password manager or another secure location, without it you will lose access you your drive and all your files.â and maybe a button âprint passwordâ to print it out.
Yes I have been thinking that as well.
There are several things here, and some conflicting needs.
Requiring a mnemonic of more than a few words is going to be problematic for the every day average user.
Using a memorable password to seed the actual network credentials makes it susceptible to brute force.
Mnemonics have been shown [source missing] to be easier to remember per achieved entropy than âpasswordsâ, so thatâs why the first approach was to just include a super simple âpassword managerâ in the app (encrypting and storing locally the safenetwork credentials that user entered). The easy to remember password is then not seeding anything, and it is all much less susceptible to brute force attacks (attacker needs to get access to your machine first).
Generating a very strong password or a mnemonic for the user, which is then encrypted locally with the easy password (instead of involving password manager), is just the next step of that.
But then of course, itâs preferrable to use a mnemonic, in case the user actually wants to try remember it. Natural next step is to allow printing of it.
Keeping it encrypted locally, is not a very robust solution though since it is stored on a single machine. Weâve also lost portability, without extra measurements taken.
Easy to access for user from everywhere, hard to access for others, robust (hardware fault tolerant), these things are not easy to reconcile.
Thereâs the option to create a SAFENetwork account to save it. Hell, thatâs even what I have wanted to use SAFENetwork for, the ultimate key manager. But can also become a compromise in another end, with regards to drive isolation (more to be said there).
Ultimately though, I donât think you want the application on a desktop machine. Rather you want it on a hardware encrypted stick.
There are still plausible vulnerabilities, but the number of them decrease a bit that way.
One of the major benefits of mnemonics is they can easily be hand-written (unlike hex or base58 encoded entropy). Printers may keep history in weird and unexpected ways, so I generally donât recommend printing any cryptographic secrets. Instead I recommend recording the mnemonic on paper using a high quality pen and high quality paper (âhigh qualityâ is specifically used since it adds gravitas to the transcribing process, and also may improve longevity of the actual artifact).
Haha yes indeed secure key management is quite a slippery slope
I was under the impression that pencil is more robust for long term storage than pen.
Longer term solution would be to adopt webauthn for all logins? https://webauthn.guide/
Hi everyone
Iâm giving a short update so you all know what is going on.
I have not worked much on this project for a while.
Since spring Iâve had to maintain some land, cleaning up from last years tree felling and stuff. Then my plans for landscaping grew a bit and came to include draining and renovation of an old farmhouse and what not. Actually, all this was plenty good because being outside and working with the body, feeling the dirt, sun, wind on your skin⌠all that is needed when you normally spend pretty much all time in front of a screen⌠(And the renovation is not done yet!)
Then a couple of months ago my work machine burned. Fortunately there were a few months left on the warranty, so I got pretty much everything replaced. This week I finally got all the parts and these lines here are the first Iâm writing from the newly assembled machine.
And now, since new data types (RFC 54 - Published and Unpublished DataType and RFC 55 - Unpublished ImmutableData) are coming, Iâll be waiting for those to be more concrete before continuing.
So, most likely the summer will be off for other things.
Thatâs that for now, just wanted to let you know!
Great update! One of the most important projects in my eyes to get people using the SAFE Network!
Not to mention organising three SAFE meetups 
At the end of all things, tending your land and community is such rewarding work. And life is short, so work hard and rest and enjoy the Swedish summer.
I hope you come back, full and rested, and ready to tend to SAFE and this community once again!