Any WEB UI planned?

[lion24]

Hi there,

First, very nice project 😊 Testing it right now and works rock solid.

Do you have any planned to integrate a Web UI like the Tailscale one?

I guess for that TLS would need to be enforce, but I guess this is doable.
The WebUI can talk to the backend API and automatically register new nodes one the user is logged in.

I think this would be very handy and provide an experience really close to what Tailscale is doing 😊

The UI itself should be fairly quick to create, it's more the interaction with the backend that could be challenging I guess.

Let me know what's your plan.

Kr.

[kradalby]

We are currently adding a HTTP API, so making this will become possible within a couple of releases.

That said I dont have any concrete plans to add a web ui other than "down the line".

My priorities are driven by my need and I might work on Terraform provider first. Of course if someone would be willing to sponsor the feature, then the priorities could shift.

[fdelucchijr]

We are currently adding an HTTP API, so making this will become possible within a couple of releases.

That said I don't have any concrete plans to add a web UI other than "down the line".

My priorities are driven by my need and I might work on Terraform provider first. Of course, if someone would be willing to sponsor the feature, then the priorities could shift.

I’m a Flutter(Android, iOS, Web) developer in my company (actually I’m because of funds and economy of the company a FullStack (the only) developer in a microservices backend and an event-driven mobile app 🤣). I'll be happy to sponsor this feature. If the UI is made in Flutter it can take less than a week (and can be exported as a Windows/macOS app), if prefer a proper web framework can take a little longer because of MVC and management of components.

[kradalby]

@fdelucchijr we would appreciate help. I have some concerns with using Flutter, which is mainly that it would mean that the current maintainers would have to learn a new language (Dart) and Flutter as a framework.

But I am happy to have a chat and be convinced :)

Other than that I would probably opt for Elm + TailwindCSS as that is what I know. I assume using something like Typescript + Vue would make it accessible for contributors.

[fdelucchijr]

@kradalby
I have been thinking about this since I wrote the previous message. Flutter Web is good for web apps, but I feel that for the classic control panel it doesn't make much sense, Is some sort of overpowered. At some point, I will make a control panel with flutter just to be able to control the headscale server from my cell phone or without exposing the WebGUI (LoL 🤣).

Elm looks super interesting! I would love to learn it, but it is true that with typescript there would be more flexibility for contributors.
Tailwind I think is a very good option, in combination with Vue it can be perfect to make maintenance and development easiest possible.

The following steps should understand which usecases should go into the screens, and make a mockup of the layout. (At this point we don't need to choose a language yet, nor the complete API, just understand what the webpage should cover)

Is the conversation on this topic ok here? or is it preferred by a special chat?

[cgrs]

What about just having a Web UI completely decoupled from the server? That way anyone who wants to have different UIs can develop them or use them on their own, being in Flutter, Elm or Vue.

[fdelucchijr]

Sounds good, but I think would make a lot more variable the development and if theres no "oficial" web gui gonna come up a lot of unmantained or incompatible versions of the same panel.

@kradalby Say is in development an api. I think with proper docs should be enough for anybody to make a external webgui, and adding a bool parameter to deactivate the internal is more like a'cherry on top (for my idea of a Flutter mobile app this would be awesome).

Obviously this isn't my choice, as implies a handful of definitions in the complete project approach.

Deploy a headscale container with all the components and other with just the server with a companion container for the webgui is something interesting for k8s, tho.

[kradalby]

The API might be available as beta and "subject to change" in the version after next. It will support OpenAPI so client code can be generated.

The API will open for anyone to make a WebUI, so @cgrs, feel free :)

I would assume that at some point we might include one, and having a collected effort might make more sense.

Also having everything in the same binary would be neat and easy to ship around.

[srdjanrosic]

Might be an unpopular opinion, or .. not..

... but, how about not making a web APP at all... and instead, just having the server render some simple html with current status to start with, ... and then maybe adding a few endpoints that can take form submissions to change things down the line.

By this I mean, how about just using go templates for showing a mix of current config and state, and having a few blue links and buttons scattered around to do some common things and move around, ... and relying on simple re-rendering of a page for any complicated UX transitions.

... how it looks can be prettied up well enough with some basic CSS, ... and you could even do things like show/hide and tabs using CSS, ... if that's where things go (spoiler, radio-buttons are mutually exclusive like tabs and can be made to look like so).

---

Reason I'm leaning toward this solution (over any of the javascript/typescript/wasm + framework-du-jour), is because I think:

a) majority of tailscale (by proxy headscale) users, myself included, would probably appreciate simplicity in their stack
b) we'd end up not fragmenting or burdening end users with different UIs that are a potential source of confusion / analysis-paralysis during adoption phase, and a potential support / maintenance burden or a distraction down the road.
c) requires very little no additional dependencies or toolchain changes
d) requires very little to no additional cognitive load to maintain / build / run .. and extend with new features, as they appear on the back end.

---

None of that would be necessarily exclusive to having a well thought out API as well ... but having the info laid out in a browser would be a bit more friendly to casual users (folks who don't manage VPNs for a living or as part of their critical role at a company or similar).

Security wise, beyond basic TLS, we'd probably be mostly good with just some basic cryptographic xsrf tokens stuffed in form fields and some explicit http headers (CSP, x-frame-options, that kind of stuff).... not sure how we'd think about identity in the web ui in the first place ... oauth?

---

development process wise - a good start would be to expose just the read-only status somehow safely, before allowing state mutations through the webui.

[bohtho]

I'm just a weekend code (w)hacker but am a Tailscale (UI/coordinator) user, and my 2p go to a decoupled UI as a simple but modern web gui (precompiled js please). How about something based on Svelte (or Svelte Kit) which is succinct and easy to grok for new developers? Then you smart lot can concentrate on the API and coordinator itself.

[klvnptr]

I suggest using some straightforward decoupled React +Tailwind UI. It is very popular and it is easier to recruit contributors :)

[fdelucchijr]

@kradalby, sorry because of my hiatus, the holidays have been a mess. There's news on the API progress? I've already made a Figma board and started a mood board of different self-hosted solutions to make a wireframe of the UI.

Seen that there's still a debate on how to implement the WebUI at a technical level, I will stick to the conceptual level for now. Probably will drop the Figma board here when I have some of the modules ready.

I will maintain my opinion in a Tailwind-Vue combo, and really don't care much about the coupling in the server-client, but I really think there's a need for a Headscale officially maintained WebUI that at least show the state of the service and allow the admin to configure some settings (the more the better). This will expand the project as the best self-hosted VPN solution for regular users out there.

[kradalby]

@fdelucchijr I have not been working on this for a bit, had a break so no news atm.
I can see myself starting to play around with headscale in a bit, but not yet.

As for my opinion/decision towards WebUI:

I have decided that if I will work on it, be involved and do possibly a good batch of the work, I will write it in Elm + TailwindCSS (or something like F#/Fable).

The reasoning for this is that I am doing this project for fun, and if I am to enjoy doing this, I cannot use JavaScript/Typescript/Vue/React as I do not find it fun to work with. I do enjoy working with Elm.

I do not intend to mandate that the project is done in Elm, this is mostly to make it clear that if I start it, or am to contribute, that will be the language. If anyone feel strongly about choosing more mainstream tech, that is fine, but then they better start working on it before I get to it and uphold a good enough quality (whatever-that-means).

I have no timeline for when I will consider diving into this as I don't personally need a WebUI for headscale.

As for other implementation details, I think for a WebUI to be viable, it must be embedded in the binary and served without any extra setup. Luckily Go is reasonably good at this.

[endigma]

Is there an HTTP API planned? If there was one I'd make a webui.

[artemklevtsov]

@endigma HTTP API already introduced (see #204).

[endigma]

@endigma HTTP API already introduced (see #204).

docs for routes/payloads anywhere?