Quick Connect redesign for multi-protocol connectors #369
Replies: 22 comments 12 replies
|
Koofr first, the simplest multi-protocol connector. Its WebDAV and Native API modes share one account credential (the same email plus app password), so switching protocol here is genuinely just "same profile, different protocol", which is exactly the case this redesign is about. Layout only, the saved record under the hood is unchanged. Here is the current Quick Connect for Koofr, both modes, in both states. When you ADD a new profile the footer is already a single clean Save, which is what you asked for. Native API, new profile: 
WebDAV, new profile: 
But when you EDIT a saved profile and switch its mode, that single Save is replaced by three buttons: an x, a green "Save as new", and an orange "Convert to", plus a "Replaces the original profile" note. There is so little room that the labels truncate to "Save as new ..." and "Convert to Na...". Native API, editing and switching mode: 
WebDAV, editing and switching mode: 
This footer is the heart of what you raised:
So the proposal is to make EDIT behave like ADD: one single Save that converts the profile in place, no x, no "Save as new", no truncated labels. Duplicating a profile is done from the My Servers page, not from this form. The protocol selector sits as the divider, the fields above it are shared across modes, the fields below it (for Koofr, only WebDAV's Endpoint URL and Port) are protocol specific, so for a shared-credential connector like Koofr the form barely changes between modes. Proposed layout (Native API shown; WebDAV is the same with Endpoint URL and Port appearing below the protocol selector): 
Open points for this page:
Ehud, does this match what you had in mind for the edit and mode-switch flow. Once Koofr is settled I will bring the same treatment to Filen, MEGA, OpenDrive, FileLu and 4shared. |
|
Thank you for your effort on this topic. Here are the changes that I like from your screenshots so far:
Here is my feedback on your draft screenshots:
More feedback on the Quick Connect pages of v4.1.0-v4.1.1 outside of your screenshots:
|
|
A follow-up on this: Please write Protocol above the protocol selector radio buttons, so they're consistently labelled like all the other inputs. The only other input that I see in your last screenshot that also needs a label is Icon, which I noted in my bullet point number 4. |
|
Regarding bullet point 10: Thank you for adding a '💾 Save' button to OAuth 2.0, but unfortunately, it doesn't work. |
|
Regarding API Quick Connect pages with 2FA, namely Internxt, MEGA and Filen:
I was even thinking of combining these 2 points somehow so the 2FA secret will generate TOTPs directly in the TOTP field, but I still think about how to design it so it would look good. These two points, for now, should be very easy to implement by just changing HTML and CSS, not even JS or Rust. It'll be easier to see what to change next after seeing both changes. |
|
Both layout points shipped for v4.1.2 across all three 2FA Quick Connect pages (Filen, MEGA, Internxt): the code field is now a compact six-glyph input with a Details in the v4.1.2 tracker: #384 |
|
More Filen and MEGA Quick Connect pages feedback: By the way, I noticed that when deleting the MEGAcmd WebDAV Endpoint URL, saving it and then connecting, it connects to http://127.0.0.1:4443/. You can see this both as the placeholder and when clicking '🖊 Edit'. |
|
Good catch. On the MEGAcmd endpoint: this is already handled. On connect AeroFTP runs On |
|
kDrive’s Quick Connect page: I have great news that I know you’re going to love! I managed to find a link that takes you directly to the ‘API tokens’ page in kDrive’s Developer section, which is what we lacked in #110: https://manager.infomaniak.com/v3/ng/profile/user/token/list. Here’s how I found it: go to https://manager.infomaniak.com ➜ click on your user icon at the top-right ➜ click on ‘Manage my account’ ➜ right-click on ‘Developer ↗’ ➜ click on ‘Copy clean link’. That link is https://manager.infomaniak.com/v3/ng/profile/user/applications/list. Opening it takes you to the ‘API app’ page, which is a sibling to the ‘API tokens’ page. Going to each changes these URLs by adding the numeric user ID, but I noticed that the only difference between them is the words Also, we covered how to generate an API token for kDrive in #110, but haven’t actually covered how to find the Drive ID. I forgot how I even found it. It’s confusing; it’s a different 7-digits than what appears in the URL bar when entering https://manager.infomaniak.com. What this means now is that it significantly simplifies the docs and allows adding this link to the Quick Connect page of kDrive, So the special changes that I propose specifically to kDrive’s Quick Connect page are as follows:
Please note that since you watch this repo, you should’ve received an email that I added another comment over the last day in #321. However, I decided to remove it, because after posting it, I discovered https://manager.infomaniak.com/v3/ng/profile/user/token/list, Also, this post should be a place to discuss the design of all Quick Connect pages, not only those with multiple protocols. |
|
That direct link is exactly what was missing, thank you. The kDrive Quick Connect help text now links straight to the Infomaniak API tokens page (https://manager.infomaniak.com/v3/ng/profile/user/token/list), closing the #110 gap. Shipping in v4.1.2. |
|
I saw that you implemented nearly all of these bullet points in v4.1.2. Thanks. |
|
More Quick Connect feedback:
<!DOCTYPE html><html>
<b>6-digit TOTP (not saved)</b><br>
<div class='TOTP'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
<input type='text' inputmode='numeric' autocomplete='one-time-code' maxlength='1' class='totp-box' placeholder='0'>
</div>
<br><b>Drive ID</b><br>
<input id='DriveID' type='text' inputmode='numeric' maxlength='10' placeholder='1234567'>
<style>
input{margin-top:8px}
.TOTP{display:flex;gap:8px}
.totp-box{width:18px;height:24px;text-align:center;border:2px solid#ddd;border-radius:6px}
.totp-box:focus{border-color:#0055ff;outline:none}
::placeholder{color:#d6d6d6}
.totp-box:focus::placeholder{color:transparent}
#DriveID{width:78px}
</style>
<script>
const inputs=document.querySelectorAll('.totp-box'),L=inputs.length
,handlePaste=e=>{
e.preventDefault()
const pastedData=e.clipboardData.getData('text').replace(/\D/g,'').slice(0,L),l=pastedData.length
for(let i=-1;++i<l;)inputs[i]&&(inputs[i].value=pastedData[i])
l&&inputs[Math.min(l,L-1)].focus()
}
,handleInput=e=>{
e.target.value=e.target.value.replace(/\D/g,'') // Only allow 0-9 digit inputs
e.target.value&&e.target.nextElementSibling&&e.target.nextElementSibling.focus()
}
,handleKeydown=e=>{// The arrows keys can navigate between the 6 TOTP fields.
switch(e.key){
case 'Backspace':
!e.target.value&&e.target.previousElementSibling&&e.target.previousElementSibling.focus()
break
case 'ArrowLeft':
case 'ArrowUp':
e.preventDefault()
e.target.previousElementSibling&&e.target.previousElementSibling.focus()
break
case 'ArrowRight':
case 'ArrowDown':
e.preventDefault()
e.target.nextElementSibling&&e.target.nextElementSibling.focus()
break
}
}
for(let i=-1;++i<L;){
inputs[i].addEventListener('input',handleInput)
inputs[i].addEventListener('keydown',handleKeydown)
inputs[i].addEventListener('paste',handlePaste)
}
// Only allow 0-9 digit inputs
document.getElementById('DriveID').addEventListener('input',e=>e.target.value=e.target.value.replace(/\D/g,''))
</script>
</html> |
|
Thanks for implementing most of this comment in v4.1.2. Please narrow the width of Drive ID to exactly 10 digits and separate the TOTP field into 6 boxes to clarify their natures. If you think about it, these are some of the few input fields out there which not only can we restrict to digit inputs only, but we also know their maximum lengths, so we can narrow their widths. |
|
I see that you wrote the word LOCAL twice for each local protocol, WebDAV and S3, in Filen's Quick Connect page. |
|
Based on my pCloud Drive OAuth guide (#321 (comment)), and similar to my feedback on OneDrive's Quick Connect page (#270 (comment)), I think it's best to change the URL of the 'Get credentials ↗' hyperlink in the Quick Connect page of pCloud Drive OAuth from https://docs.pcloud.com/methods/oauth_2.0/authorize.html to https://docs.pcloud.com/my_apps/, because the former confuses and overwhelms the user and really doesn't help. I also suggest editing this hyperlink's text from 'Get credentials ↗' to something like 'Manage credentials ↗' or 'Edit credentials ↗', because that link can't generate the credentials; it only manages them. There needs to be an official guide that details how to politely email support@pcloud.com to ask for creating a new OAuth app. The slash at the end of the link is very important, because https://docs.pcloud.com/my_apps defaults to https://docs.pcloud.com, which is the current page that I'd like to avoid. |
|
Three of the Quick Connect items are fixed on
The ALL CAPS drive-name consistency point is separate and not in this batch; I have it noted and will get to it. Everything above is tracked in #388. |
|
The following cloud drives write that they support different amounts of free storage at the top-right of their Quick Connect pages than what's written in the table view of the Add Service page and other places. So for the sake of consistency, please correct these.
Also, I think it's inconsistent how some Quick Connect pages don't show their amount of free storage at their top-right. |
|
Where: Filen’s Quick Connect page. Why: While I thought about and wrote #276 (comment) and #266 (reply in thread), I used KeePassXC to generate usernames and passwords for the Filen desktop app’s WebDAV and S3 local servers. I found something interesting: The Filen desktop app seems to only accept WebDAV usernames and passwords, and S3 AccessKeyIDs and SecretKeyIDs, which are no longer than 32 characters and only of the following types: 
Considering that I observed this for both WebDAV and S3, I think that it’s not due to the fundamentals of these protocols, but rather just how Filen implements them. And before you ask, no, this isn’t what caused previous issues that I had with Filen S3. What: |
|
Two things here, and the second one you will like: I am taking your Filen suggestions, and it turns out AeroFTP already ships a password generator you may not have seen. First, your concrete asks, which I agree with and will implement on the Filen Quick Connect page: cap the WebDAV password and the S3 SecretKeyID (and the matching username / AccessKeyID) at 32 characters like the kDrive drive-ID field, add a short note listing the allowed characters, and warn when a rejected character is entered. Your read is right that this is Filen's own constraint on its local WebDAV and S3 servers, not the protocols, since you saw it on both. Second, the part you may not have run into: AeroFTP has a built-in generator, "Password Forge", inside a small Security Tools panel (alongside a Hash Forge and a CryptoLab). It is honestly a bit hidden today, it only appears under the Cyber theme, which is exactly the discoverability problem I want to fix off the back of your comment. It is not a toy: passwords come from a CSPRNG (not Math.random), the entropy readout is the real length times log2(pool), and the CryptoLab uses Argon2id plus AES-256-GCM or ChaCha20-Poly1305. So the engine is already serious, it just is not where you would look for it, and it is not yet flexible enough for a constrained target like Filen. 
Here is where it stands and where I am taking it, including where each piece plugs into the app:
And the rest of the same toolkit, so you can see it is not just a password box: 
The key gap your Filen case exposes is the one in the first row: today the symbol set is all-or-nothing and it includes characters Filen rejects, so there is no way to ask for "only the symbols Filen accepts". That is what the custom / excludable character set is for, and the "Filen-safe" preset will bake in exactly the set you found. One practical tip you can use today, before any of that ships: in Password Forge set the length to 32 and turn symbols off. That gives you a 32-character alphanumeric password, fully within Filen's accepted set and still 191 bits of entropy, far more than a WebDAV or S3 credential needs. It is not the safe-symbol subset you built in KeePassXC, but it is compliant and strong, and it is one click once the tool is easier to reach. 
Thank you for the Filen finding and the field-limit suggestion, both are going in, and they are also nudging the generator out of hiding, which it needed. Credited to you. |
|
I don’t see where these Security Tools are. I think <> AeroTools is a good place for them. |
|
Two of the items you raised here are addressed: Security Tools discoverability (EF-20). The Security Tools (Password Forge, Hash Forge, CryptoLab) were only visible under the Cyber theme in v4.1.4. Since v4.1.5 they are always discoverable regardless of theme: the button now lives in the titlebar utility cluster, immediately to the left of the AeroVault button, and opens the tools modal (Password Forge / Hash Forge / CryptoLab tabs), with inline generation covering AeroVault, encrypted overlays and protected archives. That is close to but not identical to the Provider display-name casing (EF-27). The ALL-CAPS rendering on Quick Connect headers for names like Dropbox, OneDrive, box, kDrive, Filen, pCloud Drive and Google Drive is fixed in the v4.1.6 wave (a fallback was completing the display name instead of upper-casing it). MEGA and TAB.DIGITAL remain the intended all-caps exceptions. Could you retest both on the current build. Thanks. |
|
I just found the Security Tools next to AeroVault when the Cyber theme is on in v4.1.4. Nice Easter egg. Please follow the example of this demo: https://connor4312.github.io/blake3/index.html.
More feedback from me: please enable drag & drop of files to '# Hash Forge'. I also tried the Password Forge now. Here’s my feedback from KeePass for '🔑 Password Forge':
Well, I think so, because Tools are in the name of Security Tools, so AeroTools are the most intuitive place to look for this. |
|
All of your points are in for the next wave: Hash Forge (BLAKE3 demo parity). Output-length field for BLAKE3 (1-1024 bytes, XOF, default 32); the Calculate button is gone, so the hash recomputes automatically as you type (Generate-style randomized actions keep their buttons); empty input is hashed (the classic Password Forge. Generated passwords are now masked by default with a per-row 👁 reveal toggle (same pattern as CryptoLab). About the KeePass-style clipboard behavior: that was already shipped. Copy auto-clears the clipboard after 30 seconds. AeroTools placement. Agreed with your reasoning: Security Tools now has an always-available launcher in the AeroTools panel toolbar (all themes). And since you liked the easter egg, the titlebar shield is back to being Cyber-theme-only. |
|
Please notice that the ‘Copy Hash’ button is just about wide enough that it causes the output field to its left to be narrow enough that it pushes 64 characters into a second row. You can see it with SHA-256, SHA-512 and BLAKE3. |
|
In the Quick Connect page of MEGAcmd WebDAV, see how the Wrappers / Overlays collapsible uses the ˅ and ^ symbols to indicate that it opens and closes vertically. |
|
I wondered to myself the following question: Does AeroFTP currently require more user input than is necessary in Quick Connect pages?
So instead of writing which bucket or drive ID, the user will be able to scroll or even search through and select from a list of options. I think that Backblaze B2’s API might be similar to S3, so if there is potential in one of them, there is likely potential in the other. This idea occurred to me because kDrive's API Token seems as long as Jottacloud’s, and Jottacloud doesn't need to specify a Drive ID, |
|
Speaking of restricting input fields, let’s consider the 'Total storage (manual)' input field in some Quick Connect pages such as S3Drive. As for the units, please either:
For pre-configured profiles like S3Drive, I suggest having the storage capacity and the placeholder as the free-tier amount by default. |
|
Please move the 'Total storage (manual)' input and the ‘Calculate used storage on connect’ checkbox under the Protocol selection radio buttons, and the 'Remember credentials for every protocol of this account' checkbox above these. You can see where they currently are in FileLu’s Quick Connect page. The idea again is to group related elements and to have elements below the inputs on which they depend. |
|
In OAuth 2.0 Quick Connect pages, please remove the ‘🔁 Use Different Account’, ‘Disconnect account’ and ‘Edit’ buttons. Maybe also have a toggle to switch between |
|
Where: Quick Connect pages that have AeroCrypt set up. What: Show the toggle switches ‘Write header to remote’ and ‘Default salt’ toggled on and the 256-bit radio button selected, if they were selected during setup. Why: It’s confusing to see these off, as it's interesting and important information for the user to know what settings are in use. |
|
At the bottom of the 'Crypt (Encryption)' section in Wrappers / Overlays, please correct what it writes at the bottom: |
|
More on the topic of useful information on Crypt in Quick Connect pages: I'm still not quite sure if the 128-bit and 256-bit radio buttons are the minimum requirements for the password, or the entropy of the salt or both. To answer this question, and be informative in general, please write the actual default public salt of AeroCrypt v3 under them. That way, if there are two such salts, the user will be able to read and back these up just in case, even though they're public and already backed up in the software and likely elsewhere. This is also a good opportunity to add the following analogy to make it clear to the users: Much like table salt 🧂 is an optional additive, not the main food, likewise, a salt here is an optional additive for the KDF that encryption uses. There are also old notes in https://docs.aeroftp.app/features/aerocrypt.html about |
|
What: When Crypt is on, the Remote Path is locked with this text: Why: It seems like it should be possible to change without undoing and redoing the Crypt setup, because it’s outside of the |
|
I think setting up AeroCrypt is now a little bit more complicated than it should be. Firstly, the 128-bit and 256-bit radio buttons are redundant, because the password field already measures the strength of a password. Secondly, the 'I generated this password with a password manager and understand the linkability tradeoff.' checkbox doesn’t seem to do anything whether it’s ticked or not. I suggest removing these. Pros and cons, and best practices can be covered in the docs. Rclone Crypt lacks both of these, and it’s quite secure. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This thread is for designing the Quick Connect (Add / Edit Server) layout, starting with the connectors that expose more than one protocol for the same account.
It grew out of a bug report, #215, where @EhudKirsh asked to switch a saved profile between its protocols (Native API, WebDAV, S3) without losing credentials, the favourite star or the storage quota. All of that is fixed and shipped. Along the way Ehud sketched a much better Quick Connect layout and a clear line of thinking behind it, and that design work does not belong in a bug thread, so I am moving it here where it can have proper mockups and a real back and forth.
Credit where it is due: the core idea, and the first mock, are Ehud's. In his words the goal is to need only one profile per online account, and to switch protocols from inside that one profile, instead of keeping one remote per protocol like rclone does. His Koofr sketch reorganised the form around that idea, and it is the starting point for this thread.
What he proposed, in short:
A first piece has already shipped in v4.1.0: every connector now uses the same two-column layout, the OAuth pages included, with the profile icon next to the name and the Wrappers / Overlays section (the transparent crypt overlay) open by default. Here is the pCloud OAuth page.
One important scope note, because it is the natural worry with a "one profile, many protocols" UX. This is a GUI reorganisation only. Under the hood each protocol stays its own independent profile record, with its own id and its own credential in the vault, and it stays individually selectable in export and import. The single cleaner form is a nicer way to drive records that already exist, it does not merge or couple your profiles. Existing exports and existing setups are unaffected.
How I would like to run this thread:
Next post in this thread is the first set of Koofr mockups. Ehud, please react to those and tell me which direction feels right before I move on to the harder pages.
All reactions