Roles & visibility
Peekr has one visibility rule, and the database enforces it on every query — the web app, the API, sync and the MCP servers all go through it. There is no code path that can show someone a capture the rule says they can't see.
The rule
You can see a capture if any of these is true:
- You made it, and it isn't filed anywhere yet.
- It's assigned to you.
- It's in a group shared with everyone, and you're a member or admin of the workspace.
- It's in a group you're on — private, or shared with you as a guest.
A capture that isn't in any group is a private draft: only its author (and whoever it's assigned to) can see it. Filing it into a group shares it with that group's audience — that's the moment sharing happens. Nobody else gets a way in, not even the workspace owner.
Roles
| Role | Sees | Can |
|---|---|---|
| Owner | Groups shared with everyone, private groups they're on, their own drafts, captures assigned to them | Everything an admin can, plus delete the workspace and transfer ownership |
| Admin | The same as a member — plus that every private group exists, and who's on it | Manage members, invites, groups, bots, webhooks, settings; edit and resolve any capture they can see; join a private group (its members are told) |
| Member | Groups shared with everyone, private groups they're on, their own drafts, captures assigned to them | Create groups, share their groups with others, edit captures they can see |
Guests
A guest isn't a role you pick. When you share one group with someone who isn't on the team — private or shared with everyone — they join as a guest of that group: they see it, and any other group later shared with them, and nothing else. Inside their groups they can capture, comment, claim and resolve like anyone; they can't create groups or invite. Anyone on a group can share it this way; an admin can make a guest a member later.
Groups
- Shared with everyone is how a new group starts: every member and admin of the workspace sees it and everything filed into it. A guest sees it only if it was shared with them. A workspace can change the default in Settings.
- Private groups are visible to the people on them and nobody else. Admins can see that a private group exists and can add themselves to it; when one does, the group's members get a notification — quiet accountability rather than a secret.
- Changing a group's visibility re-evaluates who can see every capture in it. The web app tells you how many captures are affected before you confirm. Devices that lose access drop the captures on their next sync; devices that gain access pull them.
- Deleting a group doesn't delete its captures — they become private to their authors again. Admins can restore a deleted group within 30 days.
Agents and bots
- An agent connected by a person (through OAuth or a personal token) sees exactly what that person sees and acts in their name. Tokens can be narrowed to read-only or to specific groups; they can never see more than the person.
- A bot is a workspace identity with a role (member or guest) and group memberships of its own. It sees what a person with those memberships would see. Assign captures to it, make it a group's default assignee, give it a webhook.
- Every action taken through an agent is recorded with both identities, and shown on the board as “Client · Person” or the bot's name.
What admins can't do
Admins can't read private groups they aren't on, or captures that haven't been filed into a group — the database refuses, not the UI. They can see that a private group exists and join it, which the group is told about. They also can't read your captures in other workspaces, your local-only library, or your account's tokens. Removing someone from a workspace leaves their ungrouped captures with them; the captures they filed into groups stay with the group.