Hi @leolabs,
I’m currently testing AbleSet 3.2.0-beta.3 as part of a show-control setup that includes several small local bridge services.
One of these services reads the state of an Axe-Fx and sends normalized OSC feedback to AbleSet. Both AbleSet and the bridge run on the same Mac, so this particular OSC connection is intended to be entirely local:
Local bridge → 127.0.0.1:12301 → AbleSet
When I configure an AbleSet OSC connection with listen port 12301, AbleSet currently binds it to all IPv4 interfaces (0.0.0.0:12301). This means that other devices on the network can also send data to that connection.
I’m aware of the “Preferred Interface” setting in AbleSet’s status window. As far as I understand, this controls the address shown by AbleSet and used for AbleNet. My request is more specific: it concerns the local bind address of an individual OSC connection’s Listen Port. In my test, the additional OSC listener was still reachable through all IPv4 interfaces even though its peer communicated exclusively through 127.0.0.1.
In my setup, the iPads and other clients should still be able to access AbleSet’s web interface, but they should not be able to inject state into this local OSC feedback connection. I could potentially solve this with a platform-specific firewall rule, but it would be cleaner and more portable if the restriction were owned by the OSC connection itself.
Would you consider adding an optional setting per OSC connection such as:
- All network interfaces — current behavior
- Localhost only — bind to
127.0.0.1and, where appropriate,::1
I’m not necessarily asking for arbitrary interface or IP selection. A simple “Localhost only” toggle would solve my use case while avoiding most of the complexity associated with changing IP addresses, DHCP, redundant hosts, and cross-platform interface selection.
For backward compatibility, existing connections could continue using “All network interfaces.” The local option would only apply when explicitly selected.
I realize my particular Axe-Fx bridge setup is fairly specialized, but I think the feature could have broader value. AbleSet users may run local integrations such as:
- AbletonOSC
- local bridge or translation services
- lighting or automation middleware on the same computer
- local monitoring and state-feedback processes
- development or simulator tools
For these connections, accepting packets from the entire LAN is often unnecessary. A localhost-only option would:
- reduce accidental or unauthorized OSC input;
- separate local integrations from network-facing OSC devices;
- make setups more predictable on computers with multiple network interfaces;
- reduce reliance on OS-specific firewall configuration;
- simplify secure deployment across macOS and Windows.
This would not replace OSC authentication or network security for connections that intentionally listen on the LAN, but it would provide a useful least-privilege boundary for local services.
No urgency from my side—I’m deliberately testing the beta and understand that priorities and support implications matter. I wanted to describe the concrete use case and suggest the smallest version of the feature that would solve it cleanly.
