Skip to content
Charming Docs
Esc
↑↓navigate↵open⌘Jpreview
On this page

Privacy and sharing

Every app is private by default: one owner, one dataset, and you decide who else gets in and what they can do.

What you can do

Private by default. A new app has one owner and one shared dataset. Sign in from your phone or another computer to open it securely from anywhere. Nobody else can open it until you invite them or make it public.

Invite people. Share the app with specific people and pick what each can do: edit it, use it, or just view it. Change or revoke someone’s access at any time. Need more control? Contact us.

Make it public, deliberately. A separate, explicit step lets anyone with the URL use the app, no sign-in. Everyone shares the same data. Turn it off again any time.

Technical

The charm.ing dashboard lists the apps you own and the ones you’ve been given access to, and charm.ing/dashboard/shares has a per-grant role picker for changing or revoking access without going through your agent.

Copy this prompt for your agent

Set up sharing for my Charming app. Read
https://charm.ing/docs/capabilities/privacy-and-sharing.md first.
Suggest who it makes sense to share it with and what each person
should be able to do, then ask me to reply with email addresses.

How an agent performs this job

To invite a specific person, your agent calls share_app with the app id, the invitee’s Charming handle or email, and an optional role (collaborator, end-user, or viewer; defaults to collaborator). This creates a pending invitation. The invitee has no access until they accept it from their dashboard. Inviting an email with no Charming account still works: it stores the pending invite and emails a sign-up link, and the invite activates once they register and verify that address. Calling share_app again for someone who already has access updates their role in place rather than creating a second grant. Your agent lists outstanding invitations and active grants with list_app_shares, and revokes access with unshare_app.

To open the app to anyone with no login, your agent calls set_public (MCP) or PUT /app/{id}/public with { "public": true } (HTTP). unset_public (or { "public": false }) closes it again. Both are owner-only: an anonymous app has no owner yet, so it must be claimed, linked to a signed-in account, before either call works.

The contract

share_app({ app_id, grantee, role? }); // role: "collaborator" | "end-user" | "viewer", defaults to "collaborator"
unshare_app({ app_id, grantee });
list_app_shares({ app_id });
set_public({ app_id });
unset_public({ app_id });

Access is enforced server-side: every route declares whether it’s read-only, and the platform denies a role that can’t attempt an op regardless of what the app’s code does. Roles stack in one direction only. collaborator can do everything end-user can, which can do everything viewer can:

  • Owner. Full control: edit source, run any op, share, unshare, delete, make public, transfer.
  • collaborator. Open, edit source, and run the app, same as the owner short of sharing or deleting it.
  • end-user. Open the app and run it, including writes to its data, but can’t see or change the app’s source.
  • viewer. Open and run read-only operations only. A well-built app hides or disables its write actions for a viewer instead of letting them fail.
  • Public (no login). Same access as end-user, minus the login requirement, and only after the owner turns it on with set_public.

Limits, access, and deletion

  • Sharing requires a claimed app. An anonymous app has no owner yet, so share_app and set_public fail until you claim it.
  • Ownership can’t be shared away. Sharing, revoking, deleting, transferring, and making an app public or private stay owner-only regardless of anyone else’s role.
  • Public data has no isolation on the main URL. On charm.ing/<id>, every anonymous visitor shares one data pool with no per-visitor separation, so any visitor can overwrite or wipe what another wrote. A confirmed custom domain gives each visitor their own isolated storage instead. Turning public access off does not delete data anonymous visitors already wrote.
  • Revoking access is immediate for new requests. An already-open page can keep working on its short-lived credentials for a short window after you revoke.

Was this page helpful?