Show HN: XPipe, a brand-new type of remote file browser and shell connection hub (xpipe.io)
At first glance it might not look very novel, but if you dig a little deeper, you will see that the entire foundation of how it communicates with remote systems is completely different from any other solution out there. What happens in the background can essentially be explained this way: It launches a local shell process like cmd, sh, etc. and in it executes a command that opens a remote shell connection such as ssh user@host. All communication is then done through the stdin/stdout/stderr of that process. From there, it detects what kind of server and environment, e.g. shell type, os, etc. you have logged into and adjusts how it talks to the remote system. By then using file system related commands such as ls, rm, touch, etc. and its equivalents, it can realize a functional file manager that works on essentially every system without any protocol requirements. For other types of connections, it can just execute things like docker exec -i to open a shell into a container and work the same way. Right now it supports: - SSH by running your locally installed SSH CLI client - Docker, Podman, LXD, and Kubernetes containers - WSL, MSYS2, and Cygwin environments on Windows - Various other things like some VMs for VMware and Proxmox, but work is still going on on there
This approach to delegate everything to your installed tools is also utilized for other tasks. That means that I can save a lot of development time while you can happily use the tools you are comfortable with in conjunction with XPipe. In fact, XPipe doesn't ship with any libraries or tools for remote shell connections, protocol handling, or terminal integration at all. It just delegates everything to your own text editor, terminal emulator, RDP clients, and more.
Due to its nature, XPipe has to handle a lot of sensitive information like passwords, keys, and more. To tackle the topics of security and privacy, I put an emphasis on security settings and created a dedicated security page in the docs that should hopefully contain all relevant information. There is also a password manager integration, so you don't have to store any sensitive information in XPipe itself if you use a compatible password manager.
As it is a common use case to synchronize connection information across many systems, e.g. your desktop at home and laptop for travel, there is also a git integration which allows you to have XPipe automatically synchronize all connection information with a remote git repository of your choice. It supports any git remote repository, advanced authentication measures like SSH auth, GPG signing, and more. You can also use this for collaboration if you're working in a team.
The early stage development has been quite challenging as this new approach requires a completely new implementation, but I am confident that it's ready now. I appreciate any kind of feedback from you to guide me in the right development direction from here.
Enjoy!
70 comments
[ 1.3 ms ] story [ 93.6 ms ] threadMaybe I can find a solution to that. The free plan restrictions are not perfect yet and I was planning to experiment with different solutions to it.
Would you consider detecting whether each PVE instance the user connects to is a licensed / subscription-supported instance, and allowing non-licensed XPipe to connect to non-licensed PVE instances? There is an API for it already, see the 'level' field in https://pve.proxmox.com/pve-docs/api-viewer/index.html#/clus... .
Doubly so on Yubikey/GPG/PKCS11 support. Enhanced security should never be behind a paywall, IMO.
A better approach might be number of machines instead of this detection.
The Yubikey security argument is fair though, I will reconsider that.
The number of machines detection has been on my TODO list for a while, but it's a little bit tricky to implement with the current implementation.
If the user can afford the enterprise costs of those, they can certainly afford paying for xpipe?
Discount for individuals actually managing their own infra sounds like a reasonable place to draw the line.
Probably a lot of shadow IT around where the employer pays for all the big cloud stuff and employees either can't or won't bother getting the software side of their work tools paid for.
(As for me, I'm one of those annoying FLOSS maximalists so I won't be interested without the source under a reasonable license and I'm able to compile it locally without spending a week spelunking in undocumented build scripts. But hey, I wish you the best and don't be afraid to charge properly. It's easier to lower prices than raise them if you catch my drift)
But if I see this correctly, I could call the API from the command-line with this: https://pve.proxmox.com/wiki/Proxmox_VE_API#Using_'pvesh'_to... and check the response. If that is possible I can definitely change that limitation.
Unpopular opinion - if you have information on your private computers that's sensitive enough to warrant a yubikey then you most certainly would WANT to pay a company to ensure the software is well maintained. Did you balk at the price of a yubikey when you made that purchase?
But after reading up on that, it is actually quite similar to what xpipe does. Good to know about, I will dig deeper into it and see what the emacs community came up with.
What you're describing is like how the Visual Studio Code Remote system works, but broader and untethered from an editor environment. I will have to experiment with it.
Because it turns out in practice some shells and programs do not like being run in the background in a dumb terminal as this is an obscure use case.
That should work though, it might not list the file as an explicit detected key-based authentication method when you edit the connection (Might be listed as None), but it should still apply the identity file option you have set in the config.
If that is not happening, then this is a bug and I can investigate that.
I think to apply you would need to remove the config entry in xpipe and search for it again.
About the reimport, you can right-click the SSH config root, remove it, click on the magnifying glass button on the local machine to automatically add it again with the latest info. But I can fully understand that you don't want to do that, dealing with unintuitive interfaces isn't fun.
Thank you in advance!
What it will add:
- You have direct access to all systems running on the servers you connect to, e.g. docker containers, using the exact same graphical interface. On the CLI you also have that in theory, but that's tedious
- You can bring your shell environments / init scripts / aliases with you in a noninvasive way. I.e. you don't have to modify the remote system dotfiles, when you connect through xpipe it will set up any scripts you want to have available automatically
- You can link up your password manager with your SSH client and other connection methods that require passwords
- You have the ability to synchronize your connections and environments through git, including your SSH configs
- You get special integration for SSH tunnels that allows you to toggle them to start / stop in the background, you can also make tunnels automatically start on XPipe's launch
- You get an overview over all your remote connections and can access the file system of any connected remote system via a uniform graphical user interface
I've always been able to do some crazy stuff with SSH (it's really wizardry what one can do) but it definitely required using it quite frequently to remember all the commands/options etc.
Honest feedback:
- Downloaded it on Mac and ran it
- Immediately on guard due to the non-native GUI
- Try to make a connection and get the following:
java.io.IOException: Unable to launch terminal Kitty: Process returned exit code 1: Unable to find application named 'kitty.app'
I don't know what Kitty is. I probably don't want Kitty. I'll probably go do something else now.
Hopefully others are able to hit the ground running and enjoy it more quickly.
You should be able to fix this by going to Settings -> Terminal -> Set the terminal emulator you want to use
It seems like someone at apple thought that having mdfind always return 0 even if I didn't find anything was a good idea.
But there's also much more included in XPipe that you can't find in WinSCP. There is SSH tunnel support, container support like for docker, dynamic root elevation in a file browser session without having to restart, a scripting system, a VNC viewer, an RDP launcher, and more.
But I can fully understand your concerns, establishing trust is important. At the end of the day it's up to you whether you feel comfortable enough with it.
1. Firstly, nice work! What a cool idea and a nice looking implementation. I especially appreciate the light touch of using existing implementations for as many things as possible.
2. Thank you for providing RPMs! This is greatly appreciated.
3. Do you (or are you open to) making professional features source-available for paying customers? (so in other words would you share the source code for the closed portions, obviously with limitations redistributability).
4. I see it's Java, but what UI framework are you using? How has your experience been in it? I used a ton of Swing in the 00s and early 10s but moved to Qt for all my GUIs. I love Qt, but I do have a burning curiosity about the state of desktop GUI dev in Java.
5. I've gotten very conservative about buying software, not because of the money but because of the way "license enforcement" and other DRMs cause pain. Does XPipe implement license checks or stuff like that, and if so can XPipe function without internet for long periods of time?
6. It is very clear from reading your HN post and the website and README.md file that you are passionate, that you care a lot about your product, and also that you are thorough and thoughtful. To me this is a huge selling point because it gives me high confidence that you aren't just shipping fast and breaking things, and embracing the modern "ship it to prod and we'll find the bugs and hotfix them" approach which I loathe. Nice touches like the CLI (which offers very helpful message), and the option to "Quit" or "Minimize to tray" feel very polished and user friendly. I love being asked that instead of just minimizing to tray by default!
3. Making the source available would technically be possible, but I would have to consult with a lawyer for that first on how such a thing would be implemented. But I can definitely see this being a feature for the enterprise plan if the customer is interested in it.
4. XPipe uses JavaFX as the GUI framework. It might not be the most fancy and modern solution out there but gets the job done. It is still maintained, but that concerns mainly bug and security fixes. In terms of new features there isn't that much happening but that's not that bad as the desktop hasn't changed a lot over the last decade. There might be more modern solutions out there like Jetbrains Compose, but the advantage of JavaFX is that it is very stable and mature. There's also a good ecosystem of libraries for it.
5. In terms of license enforcement, it's pretty lenient. You only have to validate the license after at most 7 days, so if you are offline for a period of time it will work fine. If you are working on a fully offline system, there is also the possibility to request an offline license that will not require any internet connectivity. See https://xpipe.io/pricing#faq for that.
6. I try to do my best shipping a stable product. I think most developers would probably want to do that, but in practice it's usually investors or management pushing down from above to get features out quicker. I guess I'm in the fortunate position right now being able to choose my own development pace.
I think the best way to get started would be to download the sampler application from https://github.com/mkpaz/atlantafx. That is state of the art, good implementation. You can play around with it and jump to the source code to see how it is implemented. It contains almost everything an application needs.
Also depending how old your general Java knowledge is, the modern way of creating applications is through the module system and the jlink/jpackage tools. There are many outdated solutions for application packaging out there as well. If anything you see is using the classpath, builds jars or fat jars, or is using external tools outside the JDK, it's probably old and no longer appropriate.