Buttler: what a shared screen may not show
A household assistant answers on personal phones, on the living-room TV and in rooms. How do you keep one person's mail, calendar or memories off the shared screens, including when guests are in the room?
- Status
- In personal use, private. The code isn't public.
- My role
- Author. Buttler is my own project.
- Scope
- Which device and which room may reach personal data, and what changes when guests are present
- Last reviewed
- 29 September 2026
Where it started
Buttler holds a lot of highly sensitive information. On the more public devices it has to be restricted, and even that restriction needs a second gate: some things residents may know, and less may be shared with people outside the household, such as guests.
Someone in the living room says "Yes, we can meet on Tuesday." The wrong answer is "Sorry Petra, you have an appointment with your doctor about your condition." The right one is "Sorry Petra, you forgot you already have a doctor's appointment from two to three."
How a request is scoped
Buttler runs on personal phones, on a television that belongs to nobody, and on satellites in rooms. Before anything else, the server decides a request's reach: a device bound to a person gets that person's view, a shared or unbound device gets the house view.
Decisions
The house view is an allowlist. On a house-view turn the engine offers only tools classified for the house, and a tool that isn't offered is refused before it runs. Every tool is classified by audience and data scope; one nobody classified stops the server at startup. This replaced a subtraction on 23 September 2026. The prompt carries no preferences, memories or profile, and one fixed sentence lists what's unavailable, so the model can say so and suggest asking from the person's own device.
Reach is checked before routing. A task for a named person goes only to that person's own device or a non-shared room satellite, never to a shared device or someone else's. The check runs before the room, attendance and screen filters, so no filter can be a way around it. Room tasks are untouched: a room is a place, not a person.
Pages don't reveal what exists. A page the server wrote is served only to a device bound to that page's person. Unknown, expired and out-of-reach pages get the same answer, and a shared screen never shows private history.
Guests in the room
Company is a state a resident declares. Nothing a guest says changes it, and attendee lists on calendar events aren't read. In company, a room switches to the house view for everyone in it, because the room can't tell guests from residents and everyone hears the answer. Company can only narrow what the reach allows, never widen it. Memories written during a visit aren't attributed to a resident, and messages Buttler couldn't deliver earlier aren't offered in the room.
The rejected exemption. Only a device bound to a person is exempt. Exempting everything that isn't a table device looked simpler, but a shared television and an unclaimed phone both have no person. That rule would have exempted exactly the two devices most likely to be in a room full of people.
Where this applies elsewhere
The same question comes up in any system where one screen serves several people: which data may this device show, and where is that decided? Reviewing that boundary is part of my technical reviews.
Stack: Python / FastAPI, Flutter, .NET 8, Raspberry Pi.