tailscale
elixir: Initial commit
This commit includes a very rudimentary NIF-based wrapper for interfacing with libtailscale from Elixir/Erlang.
It includes everything from tailscale.h, except
tailscale_enable_funnel_to_localhost_plaintext_http1. However only the listen/accept parts have been tested somewhat thoroughly.
An example echo server can be run by first executing mix deps.get and then mix run examples/echo.exs.
This Elixir library (which is also published to
Hex, the Elixir package manager), but it should probably not be used directly. Instead, I have provided a gen_tailscale library, which wraps the libtailscale sockets in a gen_tcp-like interface. I've also released tailscale_transport, which allows users to expose their bandit/phoenix-based app directly to their tailnet using libtailscale and the gen_tailscale wrapper.
Everything in this chain of packages should be considered proof of concept at this point and should not be used for anything important. Especially the gen_tailscale library has been constructed by crudely hacking the original gen_tcp module to use libtailscale and could use a total rewrite at some point. However, it works well enough that my example application tschat is able to accept connections from different Tailscale users and show their username by retrieving data from the Tailscale connection.
Finally, I should note that I'm not sure merging this elixir-wrapper directly into this repository is the best way forward. I've published a package based on my fork, because Hex, the Elixir package manager, requires other packages' dependencies to also be Hex-packages. But if we merge this PR, should the package then point to tailscale/libtailscale? That seems weird, since I'm the one who has released the package. Anyway, let me hear your thoughts. I wanted to share my work here, but I'm open for other suggestions for how to actually proceed.
Pull Request Revisions
| Revision | Description |
|---|---|
| r1 | Added Elixir library for TailscaleCreated a complete Elixir library project structure for Libtailscale, including Makefile, NIF bindings, mix configuration, README, example code, and necessary project files for an Elixir NIF wrapper around libtailscale |
✅ AI review completed for r1
Help
React with emojis to give feedback on AI-generated reviews:- 👍 means the feedback was helpful and actionable
- 👎 means the feedback was incorrect or unhelpful
We'd love to hear from you—reach out anytime at [email protected].
This is really great to see! I actually had a similar version I was working on as well but it looks like you got quite a bit further than me, especially with the gen and transport versions :clap:
Finally, I should note that I'm not sure merging this elixir-wrapper directly into this repository is the best way forward
I'm not a tailscalar, but I am an insider so I'll see if I can get someone to take a look and comment on how they see this repo progressing with the other existing bindings. That might help figure out what options are available and whether a merge would have any benefit.
Having some blessed version of the bindings in this repo might garner a little more support from tailscale and the community. On the other hand, I don't believe the Tailscale team have much in the way of elixir experience, that being the case it'll probably fall to the community to maintain in some capacity anyway. That's not to say they couldn't support that in other ways though!
I'm really excited to see how far you've managed to get this. I'll pull your branch and packages and will give it a go and see if I can get a demo working as well. Maybe I can contribute some fixes I find along the way.
Thanks @elliotblackburn! I spent way too much time scratching this particular itch, but it was nice to finally get something working. I would very much appreciate if you could try it out and see if you can get this and the companion libraries working.
It would be great to have some kind of statement from Tailscale so we can figure out how this library could move forward. If they don't want it to be part of this repo, an alternative could be to have a separate repo with a git submodule that points to this repo. I think that could work.
For reference, I wrote a bit about my efforts here: https://gist.github.com/Munksgaard/9102f0be2562f7ba1eca32b7e0da643e