Hey @jensimmons.bsky.social. I know there are other places for bug reports, but FYI: the compact tab layout seems broken in Safari 26 on Sequoia 15.7. I can't close tabs or edit the URL with the mouse. The separated layout works fine. Same behavior in the Technology Preview.

Nice! I started working on something like this during the Christmas holidays. Seems like I can stop that now and focus on other stuff. 😄

I’ll check it out after work.

I would say it falls under nice drip!

Shrinking season 1 and 2, it was a fun watch! Still need to watch Silo season 2

Haha, totally. I branched off a bit. Didn’t mean to tell you what to do with your project! Sorry if it sounded that way. Your tweet made me think about the pushback I faced when pitching Elixir in the past, so I just wanted to share that. :)
I’m excited to see how alpha stack turns out!

We already have LiveSvelte, LiveVue, and LiveReact. I haven’t checked how stable they are, but maybe the development effort behind them could be combined, similar to LVN. Having them as ‘escape hatches’ is very important—even if the end goal is to rarely use them.

LiveView is awesome, and I use it whenever I can. But asking teams to shift their entire frontend stack is a big ask—maybe not so much for solo devs. Nailing interoperability between JS frameworks and Elixir/Phoenix is key to winning people over, especially with existing codebases.

Yes, I agree, but just having the current hot bundler as the default is not enough to drive adoption. We need to offer templates that make it easy to adopt Phoenix as a backend without hoping that everyone will embrace LiveView. Like the Laravel Breeze starter kits. Maybe Igniter can help here.

I disagree with this take, but we as a community could improve the documentation on how to set up Vite or other bundlers—maybe even incorporate it into the Phoenix docs. People coming from JS will always have their own opinions on which bundler to use, in addition to runtimes and package managers.

Great to have you here! :)

Sadly, I no longer have access to the project, but I’ve been thinking about reimplementing it and open-sourcing it, along with a blog post explaining the approach. Its application might be niche, but maybe, someone finds it useful. Also would be grate to get some feedback on it :) #ElixirLang

The auth flow we ended up with:
In Go, we sign each GQL request body using an encrypted SSH key stored in the user’s SSH agent. The signature and a user identifier get attached to the request as headers. On the Elixir side, a plug verifies the request by retrieving the public key from LDAP.

After some research, I proposed signing the request data with SSH. I had found a post discussing the same idea (blog.the-space.agency/2020/03/16/s...) and it felt like a solid approach. Implementing the Go side of it wasn't difficult and thanks to your lib the Elixir part was easy.

The service provided a GraphQL API for the CLI and initially used short-lived access tokens for authentication. However, the constant need to request new tokens wasn’t well-received by the support team, which hindered adoption. So we had to rethink authentication.

Happy to share! :) The CLI and Elixir service replaced a Python script used by customer support to aggregate data over SSH. The Elixir service was designed to minimize the number of systems customer support needed access to.

Thanks for building it! I used it to authenticate a Go CLI against an Elixir backend at a previous job, and as far as I know, it still works that way.