HackerTrans
TopNewTrendsCommentsPastAskShowJobs

glitchnsec

no profile record

Submissions

FortyOne OS – an SMS-first open-source multi user AI assistant OS

1 points·by glitchnsec·il y a 3 mois·0 comments

Show HN: FortyOne OSS – an SMS-first multi-tenant AI assistant platform

github.com
1 points·by glitchnsec·il y a 3 mois·1 comments

comments

glitchnsec
·il y a 3 mois·discuss
This is really cool - I'm still in V2 with NER for redacting PII before sending to model BUT that was just on simple email analysis. I bet most teams building for security with AI haven't addressed this! Thanks for sharing!
glitchnsec
·il y a 3 mois·discuss
[dead]
glitchnsec
·il y a 3 mois·discuss
Hi HN, I built FortyOne, an AGPL-licensed, self-hostable AI assistant platform designed around SMS as the primary end-user interface.

Github repo: https://github.com/glitchnsec/fortyone-oss/

The short version: one technical operator can run a deployment for multiple users. End users text their own named assistant. The operator manages the infrastructure, OAuth setup, secrets, dashboard, and integrations.

The why: Between work and friends, I’ve probably coached about five OpenClaw setups. What’s worse is, while I want to share with my non-tech buddies how they can up level with AI, I simply don’t want to go through the chore of handholding. It’s the operational work: API keys, Docker, OAuth apps, webhook URLs, secrets, VPS decisions, etc. Additionally, at least two friends never used it after the deployment, aside from trivial stuff you’ll search in Google..

My hypothesis is that many assistants are organized around tools first, and users second. FortyOne is an attempt at the reverse: memory, goals, personas, reminders, proactive check-ins, and user context are first-class. Tools are implementation details. I picked this thinking from Daniel Miessler’s TELOS framework.

If you’ve had these same issue, go deploy FortyOne, once - for all your friends and family!

How to try it:

  - Clone the repo
  - Copy `.env.example`
  - Set `JWT_SECRET`, `ENCRYPTION_KEY`, `SERVICE_AUTH_TOKEN`, and `OPENROUTER_API_KEY`
  - Run `docker compose up --build`
  - Open the dashboard on `localhost:8000`
For real SMS you need Twilio and a public webhook URL. The repo includes setup docs for Docker, webhooks, Twilio, Slack, Google OAuth, OpenRouter, database, and encryption.

I wanted the end-user experience to be trivial, some might even say… boring as possible: text a number, that’s it.

What works today:

  - SMS via Twilio
  - Slack DM channel
  - Web dashboard for registration/configuration
  - Multi-tenant users
  - Personas
  - Goals and reminders
  - Proactive scheduler with quiet hours/cooldowns/content suppression
  - Gmail and Calendar via Google OAuth
  - Slack workspace tools
  - MCP gateway support
  - Custom agents
  - Admin dashboard
  - Internal connections service for OAuth tokens/provider tools
The current stack is FastAPI, Redis Streams, PostgreSQL + pgvector, React/Vite, Twilio, OpenRouter, and a separate connections service.

The architecture is API/worker split: the API receives SMS/Slack webhooks, identifies the user, assembles context, queues work in Redis Streams, and races the worker result against an ACK timeout. If the worker finishes quickly, the user gets one response. If not, the user gets an ACK first and the final response later via Redis pub/sub. This is so the user feels the app is responsive and not slow/delayed.

One design choice I’d especially like feedback on is the connections service. OAuth tokens live in a separate internal service, encrypted at rest and scoped by user/persona. The main agent app requests tool execution; it does not need raw Gmail/Calendar/Slack/MCP credentials. This is meant as a small proof of concept for a broader “agent credential vault + tool guardrail” pattern.

I’m planning a managed node later for people who want the assistant without running the infrastructure. So you bet, I’ll be back!

Curious what HN thinks about: - SMS as the primary interface - proactive assistants vs. notification spam - separating agent orchestration from credential storage - the general architecture and how it impacts how the user feels about their assistant. E.g speed, context, tone, extensibility.

I wrote all about it in this blog: https://medium.com/@glitchnsec/your-chief-of-staff-one-text-...