I'm not convinced that a web-based solution can "not suck" more than Transmit already doesn't (does?). Transmit mounts a drive on my desktop and I just use it like a drive. It stores my accounts in the keychain, which I much prefer to storing them in a decryptable format somewhere in "The Cloud". The experience is native and I don't believe a browser based experience is going to come close.
...except for the fact that I can access it anywhere if it's in a browser, I guess. Personally, I use Transmit with S3, so that's not an issue, but I suppose it could be for a privately owned server.
A native app is in the roadmap. What 1FTP does that no other FTP apps do is allow you to share access with others without giving them direct access to the server. It's great for temporary contractors, or even employees who may quit at some point. You can simply 'unshare' access.
Ok, that makes a lot of sense. It's not a situation that applies to me, but I can certainly see the appeal. Best of luck (assuming you're Brain Scates).
"found myself constantly having to go dig through email to find FTP credentials when things needed updating, or when we needed to give a new worker access. When we had contractors or employees leave, for whatever reason, I’d have to worry about them leaving with access to our servers, as well as client’s servers, which we didn’t control, and hope that they didn’t use that access against us."
This literally makes no sense to me. When someone needs access to an account, add their public SSH key to it. When they don't, remove it.
If the client allows you to transfer files to them via SSH, easy! If they don't, break out the clue-by-four.
EDIT: Don't get me wrong, I think you're providing a useful service. I just hope that people will start a conversation about FTP's problems and alternatives before turning to 1FTP to mitigate the problems.
They don't know how to use SSH. Then you say they should learn. Then I say they aren't interested in learning. Then you say these people shouldn't be uploading files. Then we'll have to respectfully agree to disagree regarding how things do work and how they should work.
What software do they use for FTP? Cyberduck? FileZilla? WinSCP? They can keep using those. Just tell them how to generate an ssh key or set one up for them.
Absolutely. 1ftp actually uses HTTPS on the client end to secure the connection, over port 80. There is no direct FTP connection for users, only on the backend to the server. The service acts as a gateway, though its transparent to the user.
Those things are commonly unavailable on Windows servers, in my experience. This is probably due to some combination of crappy administrators, difficulty of installation, lack of tooling, etc.
Those things are great for tech-savvy developers, but the majority of folks still use FTP - it's the defacto method for connecting to a webserver, and is what every web host emails to their customers. 1FTP will be a heck of a lot easier to set up than Git, or anything else.
It may not seem so to an experienced developer, but the experience for an end user with things like that is an absolute nightmare. We're trying to make it easier, not harder :)
I actually refuse to work with FTP. More developers should. Hosts should refuse too.
There are some good GUIs for SCP that reduce the barriers of entry to the same level as FTP.
IMO you're trying to solve a problem that shouldn't be solved. Maybe turn your 1FTP app into an SCP interface. That way the "difficult" things you describe become easy.
By this logic (musn't force anyone to learn anything) we should all still be using IRC and USENET instead of Skype and web forums. So you want to provide a nice layer of abstraction over file transfers, that's laudable. What doesn't make sense is predicating your abstraction on a shitty protocol with a multi-decade long history of security issues. Best of luck to you in any case.
I'm actually intrigued by this. I've pretty much stopped using FTP because it's easier to email files or use a web based file sharing service for very large files, but if someone actually managed to reinvent FTP that would be awesome.
This sounds like "online file sharing" which many people who work in "digital" refer to as "an FTP site".
So it's not actually FTP, it's HTTP, but you're using the common parlance amongst designers and video types of referring to anything used to share files with clients online as an "FTP site".
Such an annoying misappropriation of terminology ...
Not at all. 1FTP connects to FTP servers, that's it. There's no storing of any files on our servers, it's just a pass through to provide end-user security (no sniffing passwords over wifi) and user access.
1FTP sits between the user and the FTP server, controlling access. User > 1FTP > FTP Server. Result: More secure, easy to control access (share and unshare, like Dropbox), log all activity to know who's doing what.
The big problem is that today everyone shares a single log in to the FTP server which is often passed around via email - to coworkers, outside agencies, contractors, etc. Everyone is logging in as the same user, so you no longer know who is actually logging in. 1FTP solves this, among other things.
Okay so you're saying the bonus is that, using 1FTP, I can have a single sign-on ID which allows me to connect to multiple different FTP servers, so when someone wants to give me access to their FTP account they can do it via my 1FTP id rather than adding a user for me on their FTP account, and sending me yet another username and password.
Like OpenID for FTP (and presumably, you could accept login via Facebook or Twitter as well ... )
I get it now, sorry I didn't understand that you were proxying through to random FTP servers rather than supplying storage (a la dropbox).
One thing, though, unless you're using SFTP or SCP to connect to the destination server, wouldn't it be possible for someone to sniff network packets coming out of your servers to grab the plain text passwords for any of the myriad FTP servers you connect to? I don't really know much about the logistics of it but it seems as though your servers would become a bit of a hub for discovering insecure FTP logins to thousands of servers.
Every 1FTP user has a unique 1FTP account. So to share access, you would simply choose one of the connections you own, click 'share' and input an email address, and then that user would get an email letting them know they have access (if they have an account, or prompt them to create a password for their account if they don't). Think Dropbox. So all users have 1FTP IDs, and are only connecting to 1FTP, not the actual server. 1FTP connects on their behalf on the backend.
SFTP is a protocol, and that isn't what 1FTP is all about. 1FTP is about bringing the convenience of Dropbox-like sharing to FTP shares. There are still a b-zillion FTP shares that companies use everyday to transfer files to vendors, partners, contractors, etc. Even shares that are at the root of their websites. Many of those shares use a single set of credentials that are passed around. No, that ain't smart, but that's how it's done when the process for getting real user accounts on a server involves way too much IT red tape. 1FTP allows access control to move into an easy-to-maintain web app.
...except for the fact that I can access it anywhere if it's in a browser, I guess. Personally, I use Transmit with S3, so that's not an issue, but I suppose it could be for a privately owned server.