Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add managing of Hosts in the CLI #394

Open
mikeshootzz opened this issue Dec 13, 2024 · 7 comments
Open

[Feature Request] Add managing of Hosts in the CLI #394

mikeshootzz opened this issue Dec 13, 2024 · 7 comments

Comments

@mikeshootzz
Copy link

mikeshootzz commented Dec 13, 2024

I really enjoy using xpipe for managing remote connections, but it would be fantastic to have a quicker way to browse and access these connections. Specifically, I'd love to see a terminal-based interface that lists available connections and allows quick navigation using familiar shortcuts (e.g., Vim keybindings).

A potential workflow could be:

  • Run the command xpipe to open a terminal folder view.
  • Navigate through the list of connections using Vim-style shortcuts.
  • Press Spacebar to connect to a selected host, which then opens:
  • A new terminal tab, or
  • A tmux session, or any configurable terminal interface.

This would greatly improve efficiency and streamline connecting to remote hosts.

Example Sketch

Here's a conceptual sketch of what the interface could look like:

+--------------------------------------------------+
| xpipe Connections                                |
+--------------------------------------------------+
| > dev-server-01   [[email protected]]            |
|   prod-server-01  [[email protected]]               |
|   db-server       [[email protected]]            |
|   backup-server   [[email protected]]          |
|   web-server      [[email protected]]         |
+--------------------------------------------------+

Navigation: j/k (down/up), Space (connect), q (quit)
@crschnick
Copy link
Member

I see what you are going for. The thing is that fancy tui libraries aren't really available for Java that much, so this would be an external component in probably another language an using tools like https://github.com/ratatui/ratatui.

About the actual functionality, all of that is already supported via the HTTP API. So it would only be a matter of hooking up a tui to the API. You can find the API docs here
image

I'm open for any contributions in that regard, because I haven't done any TUIs and am not an expert in languages that are typically used for these.

@mikeshootzz
Copy link
Author

Good point :D. I'll get to work and see what I can do

@crschnick
Copy link
Member

If you have any questions regarding on how to use the API, I can help you with that.

@mikeshootzz
Copy link
Author

@crschnick
I've started something here: xpctl. Currently, it only supports ssh connections, and it's really simple, I'm planing on implementing full functionality soon.

@crschnick
Copy link
Member

I can try it out if you want. The only thing I would need are build instructions, I'm not a rust expert.

You can also choose if you want to build the API handling into your app or create a separate rust library for them that others could use as well

@mikeshootzz
Copy link
Author

@crschnick I updated the ReadMe, you should find everything in there. Let me know if you have any questions.

Writing a Rust library is probably a bit out of my scope, and I don't really have the resources to maintain such a library.

@crschnick
Copy link
Member

So I cloned it and tried it myself. Looks very good and works for the SSH connections. The display bugs out if there is an error returned by the API, but that's fine. Is there any particular reason why you only used SSH connections? Any other connections should work the same, so you could in theory display the whole connection tree as you see in xpipe.

In terms of API handshake, note that there is also a local authentication available in the documentation where you perform the handshake with the xpipe_auth file contents instead of the API key. That allows local applications to interact with the daemon without having to deal with the API key. That key is only intended for external use, i.e. not local applications.

In general you have to decide where you want to take this. You can develop it for yourself if you want, or alternatively, it could be kind of made an official project if it reaches a certain maturity and feature level. It could then be a part of the xpipe org, which would make adoption easier as most people don't like to install random executables. Of course that would be made in a fashion that is compatible to the source license. The python API started out the same way. That would be a community-driven project then, I don't think I would be able to contribute a lot to it until I get familiar with rust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants