The short version: your chats stay in your browser; your account is an e-mail address and a password; we store account records and the list of machines you run — never message content. The long version, per service, is below. Last updated: 15 October 2026.
ZeroPerson LLC, 8 The Green, Suite A, Dover, DE 19901, United States, contact [email protected] (see the Legal Notice), is the controller for the processing described here. For business customers who need a data processing agreement, our DPA applies.
The chat your node serves — on your own machine, in the office or
through the relay — stores your conversations, selected model,
toolbox picks and stacks exclusively in the browser's
localStorage. This data never reaches our servers as
stored data — deleting your browser storage deletes it. For
colleagues, organisation members and visitors of a node, history
lives in their own browser, together with the token that node gave
them.
To register you give us an e-mail address and choose a password. We store: the address, a bcrypt hash of the password (never the password), whether the address was verified, your role, and the dates of registration and last login. A verification link is valid for 24 hours, a password-reset link for one hour; we keep only a SHA-256 hash of each link's token until it is used or expires.
When you log in on the website we set one cookie,
mm_session, for 30 days. For each session we store a
hash of the session token, its expiry, the IP address and the browser
identifier (user agent) it was opened from — so you can recognise
and end sessions, and so we can spot abuse. Logging out or changing
your password ends sessions.
API keys you create for the desktop app or your own tools are shown once; we keep a SHA-256 hash, the label you gave, and when the key was created, last used and revoked.
A machine running MajesticMesh with one of your API keys — the desktop app, a server, an office node — reports to us every few minutes: its peer id (a public key identifier), the name it was given, its software version, the address its chat is shared under (through the relay or in the local network) if you turned on sharing, and which of your keys it used. We store the first and latest report. This is what the Nodes list on your account page shows and what defines your team: your own nodes, which — together with the people you invited to a node and the members of your organisation — may use agents and models you marked "Team". Each node also keeps a local copy of that list for one day. Forgetting a node on the account page deletes its record.
Organisations. You can let other people use your nodes as members of your organisation — by inviting their e-mail addresses, or by naming your company's mail domain, so that everyone with a confirmed address there belongs. We send the invitation mails on your behalf to the addresses you enter; you are responsible for being allowed to invite them. For this we store: each invitation (the invited address, a SHA-256 hash of the link's token, when it was sent, accepted or withdrawn — links are valid for 14 days); each member added by invitation and each member you removed (account id and dates); and your organisation's domain. You see your members' e-mail addresses and last login on your account page; members see your e-mail address and the names and addresses of your shared nodes. When a member opens the chat of one of your nodes, we issue a signed pass for that one node, valid for one hour, carrying their user id, e-mail address and name (the part before the "@"), your account id and the node's peer id; it travels in the address fragment to their browser and on to your node, and we do not store it. Your node checks the pass and knows the member by their name and address while they chat. Your nodes also receive, with every report, the ids of members removed in the last 30 days, so a removal takes effect at a node's next report, within minutes; we stop issuing passes at once.
We operate no language model. The chat runs on your own node, which sends your messages to the model or model provider you configured there — that is between you and that provider, and none of it passes through us (except the relay pass-through described in section g). The chat may call agents as tools, including, over the mesh, agents published by independent operators in the registry; whatever the model decides to send such an agent as input reaches that operator's machine. The chat shows every tool call it makes. Choose the model, and the agents you allow, with that in mind for sensitive content.
Node operators who opt in to being listed publish: their peer id, their node's network addresses (multiaddrs, which contain IP addresses), and the names, descriptions and notes of the agents and stacks they choose to list. This data is public by design — the registry is a search index. Agents marked "Team" are never listed. A node whose owner opens its chat to everyone (section h) is also listed in the public node directory with the name, description and chat address its owner chose, and the number of agents it lists; the entry disappears when the node is no longer public or stops reporting. Listing can be turned off in the app (Settings → registry), which delists the node; entries of nodes that stop reporting are swept after a week.
When you turn on sharing, your node asks our certificate service for
a TLS certificate under lan.majesticmesh.net. The
request carries your node's peer id and is signed with its key; we
relay it to Let's Encrypt and keep, per node, only when a
certificate was issued, to stay within Let's Encrypt's limits. The
certificate's name is a hash of the peer id and, like every public
certificate, appears in public Certificate Transparency logs. Your
node's local IP address is spelled into the DNS name colleagues open
(for example 192-168-1-20.<node>.lan.majesticmesh.net);
our DNS server answers such names by computation and stores nothing.
The names of colleagues you invite, and their tokens, stay on your
node — we never see them.
When you share your node "from anywhere", colleagues open an address
under node.majesticmesh.net. Their browser connects to our
server, which forwards each request over an encrypted connection your
node keeps open to it, and passes the answer back. On our server a
request and its answer — chat messages included — exist in memory for
as long as they are in transit; we do not store or log their content.
We log that a node registered (its node id and your account id) and
operational metadata. Only the chat is forwarded; nothing else on your
node is reachable this way. Sharing in the office network (section f)
does not pass through our server.
A node's owner may open its chat to everyone. Visitors then chat anonymously, without an account and without an invitation, as "Guest", with the agents and models the owner made public. To limit abuse the node counts, in its memory only, how many visitor tokens each IP address asked for and how many messages each visitor sent in the last hour; nothing of this is written to disk and all of it is gone after a restart. When the chat is reached through our relay, the relay passes the visitor's IP address to the node for this purpose. The node, its model and what its public chat does are the responsibility of its owner, who is the controller for the conversations on it; we operate neither the node nor its model.
Verification, password-reset and organisation invitation mails
(sent to the addresses the organisation's owner enters) are sent from
[email protected] through Brevo (Sendinblue SAS, France).
Brevo receives the recipient address and the mail's content in order to
deliver it, and adds a small tracking image that tells Brevo whether and
when the mail was opened (and, if your mail program loads images
directly, from which IP address). We do not use this information; you
can avoid it by not loading images in your mail program.
Mail you send to us lands in a Namecheap Private Email mailbox.
We send no newsletters and no marketing mail.
Contact form. When you use the form on our website, our gateway sends your name, e-mail address, company (if given), message, the page language and the page you wrote from as one e-mail to our sales mailbox, through Brevo; you are the reply address. The gateway does not store the message. Before sending, Cloudflare Turnstile checks that you are human (it receives your IP address and browser data). We use your details only to answer you and keep the mail in the mailbox for as long as the conversation needs it.
Our services run on servers rented from velia.net (a German company) in their data centre in St. Louis, USA. The account and registry databases and our service keys are backed up nightly, encrypted on our server before upload, to DigitalOcean Spaces in New York, USA; DigitalOcean cannot read them. Application logs contain account and user ids, request ids, the IP address at registration and login, and operational metadata — not message content. Rate limiting keeps IP addresses in memory for minutes. Transport is TLS throughout.
Under the GDPR you have the right to access, rectification, erasure, restriction, portability and objection, plus the right to lodge a complaint with a supervisory authority. Write from the e-mail address of your account to [email protected]. Keys and sessions you can revoke yourself on the account page; nodes you can forget there.
| Provider | Purpose | Location |
|---|---|---|
| velia.net Internetdienste GmbH | Server infrastructure (gateway, registry, website, our node, certificate service, relay) | USA (St. Louis) |
| DigitalOcean, LLC | Storage for encrypted backups (unreadable to DigitalOcean) | USA (New York) |
| Cloudflare, Inc. | Network in front of the website, gateway and registry (DDoS protection, TLS, human check with Turnstile on sign-up and the contact form) — sees IP addresses and request data, never relayed chats | USA |
| Sendinblue SAS (Brevo) | Transactional e-mail (verification, password reset, invitations, contact-form enquiries to us) | France |
| Namecheap, Inc. | Mailbox for e-mail you send to us (Private Email) | USA |
| Internet Security Research Group (Let's Encrypt) | TLS certificates for shared nodes — receives the certificate name, not personal data | USA |
Transfers outside the EU/EEA rely on adequacy decisions or standard contractual clauses where applicable. Prompt content does not reach us except in transit through the relay; where it goes is decided by the model provider you configure on your node and the agents you allow. Independent node operators whose agents are called over the mesh are not our sub-processors: they are responsible for their own nodes. The current list also lives in the DPA annex.
This website sets no analytics, no advertising trackers and no third-party cookies. The only cookie is the functional session cookie described in section 2b. The chat on your node uses only the functional localStorage described in 2a.