Hi,
First of all, thank you for building SLM — it’s an incredibly impressive project. The mathematical foundations, the local-first philosophy, and the overall architecture are outstanding. I've been using it in my own home lab and the core memory capabilities work beautifully.
I have a few questions and suggestions about the project's future direction, listed roughly in order of importance to me. I’m not a professional developer (I’m an architect by trade), so please forgive me if I’ve misunderstood some aspect of the current design.
-
Are there any plans to support OpenClaw?
OpenClaw is another open-source AI assistant that speaks MCP natively, and it’s gaining popularity. It would be amazing if SLM could eventually treat OpenClaw (and potentially other non-Claude MCP clients) as first-class citizens — for mesh peer visibility, automatic memory injection, and session lifecycle events. I’m curious whether this is on your roadmap, or if you’ve considered it.
-
How should users like me handle distributed agent setups?
My deployment is fully distributed across multiple LXC containers: SLM runs on one machine, OpenClaw on another, and the MCP Hub on a third. This works wonderfully for modularity and maintenance, but I’ve run into some friction because SLM currently assumes a single-machine, single-user setup — for instance, the dashboard and API bind only to 127.0.0.1 by default, which requires me to add port forwarding just to access the UI from other containers.
I’m wondering if you have any recommendations for users with similar distributed setups, or if there are plans to make this smoother in the future.
-
A few variables would greatly improve flexibility
If possible, having environment variables to control the bind address (e.g., SLM_BIND_HOST), or to customize which MCP clients are recognized as mesh peers, would make distributed deployments much easier without sacrificing security defaults. This would let advanced users adapt SLM to their environments while keeping the out-of-the-box experience safe for everyone.
-
I might be missing something
As I mentioned, I’m not an IT professional, so there’s a good chance I’m simply unaware of existing configuration options that could solve some of these issues. If I’ve overlooked something, I’d be very grateful for any guidance.
Thank you again for your work on SLM. It’s a genuinely impressive project, and I’m excited to see where it goes next.
Best regards,
[sinking]
Hi,
First of all, thank you for building SLM — it’s an incredibly impressive project. The mathematical foundations, the local-first philosophy, and the overall architecture are outstanding. I've been using it in my own home lab and the core memory capabilities work beautifully.
I have a few questions and suggestions about the project's future direction, listed roughly in order of importance to me. I’m not a professional developer (I’m an architect by trade), so please forgive me if I’ve misunderstood some aspect of the current design.
Are there any plans to support OpenClaw?
OpenClaw is another open-source AI assistant that speaks MCP natively, and it’s gaining popularity. It would be amazing if SLM could eventually treat OpenClaw (and potentially other non-Claude MCP clients) as first-class citizens — for mesh peer visibility, automatic memory injection, and session lifecycle events. I’m curious whether this is on your roadmap, or if you’ve considered it.
How should users like me handle distributed agent setups?
My deployment is fully distributed across multiple LXC containers: SLM runs on one machine, OpenClaw on another, and the MCP Hub on a third. This works wonderfully for modularity and maintenance, but I’ve run into some friction because SLM currently assumes a single-machine, single-user setup — for instance, the dashboard and API bind only to 127.0.0.1 by default, which requires me to add port forwarding just to access the UI from other containers.
I’m wondering if you have any recommendations for users with similar distributed setups, or if there are plans to make this smoother in the future.
A few variables would greatly improve flexibility
If possible, having environment variables to control the bind address (e.g., SLM_BIND_HOST), or to customize which MCP clients are recognized as mesh peers, would make distributed deployments much easier without sacrificing security defaults. This would let advanced users adapt SLM to their environments while keeping the out-of-the-box experience safe for everyone.
I might be missing something
As I mentioned, I’m not an IT professional, so there’s a good chance I’m simply unaware of existing configuration options that could solve some of these issues. If I’ve overlooked something, I’d be very grateful for any guidance.
Thank you again for your work on SLM. It’s a genuinely impressive project, and I’m excited to see where it goes next.
Best regards,
[sinking]