Authorisation
Authorisation decides what each agent may do on your behalf: which writes it makes freely, which wait for you, and which outside services it can reach. It also decides who else is in your work, by project, session or document.
How it works
Writes can be turned off per project. With writes off, a session asks before it runs a shell command, writes a file, starts a monitor, or makes any of Mod's own writes. It does not refuse: the request becomes a question on the session's log, with "This time", "Always in this project" and "No", and you can answer it from any surface, your phone included. The switch is read on every turn, so a change takes effect from the next one.
Your standing yeses are kept in a file on your Mac, not on the log or in the project. Anything on the log an agent can write, and an approval an agent could write is one it could give itself. The device that enforces the rule is the one that keeps your answers.
Running something on your Mac is a separate permission from editing documents. A session in a VM runs host work, such as a build for your phone, as a named recipe, and a recipe you have not approved waits for your yes on that session. Calling an outside API with your key is separate again: it needs a grant for that one host, in that one project (see authentication).
An app reaches only what it declares. Its reads and writes lists name the record types it may use, and anything else is refused at the first call. Looking at a task list does not imply being able to close a task.
A session that cannot write can still move your window: switch spaces, open pages and change the layout. Making, renaming or closing a space changes your World, so it needs write access.
Membership is a set of signed grants that every peer checks, rather than a list on a server. A project and a shared session are each a group. Sessions start private to the person who started them, and sharing one shares that thread and the documents its agent wrote, and nothing else in the project. Each agent has its own key, given only what its person or its session has, and it can never invite anyone. An invite goes by email; the server only gets it to the right person and cannot create or widen access. The relay stores what it cannot read (see encryption).
Using it as you build
An agent turns writes off or on for its project, or asks which it is:
project_writes { "on": false }
project_writes
Turning writes back on asks you first. Approve recipes and grants from the question on the session; list and take back grants with list_grants and remove_grant.
Declare what your app may touch in its package manifest, and it gets only that:
"mod": {
"dataType": "launchplan",
"reads": ["tasks"],
"writes": ["tasks"]
}
You decide which projects run with writes on, which actions you approve once and which you approve every time, and which hosts your agents may call.
Limits
- Standing approvals and grants are kept on the Mac that made them, so a second Mac starts without them.