Skip to main content

​
Requests carry a verified identity

When a visitor reaches your published app through Meradomo, they have already signed in. The agent checks every request before it reaches your app — no sign-in or password handling is needed inside your app. The agent places the visitor’s verified identity into request headers:
  • X-Meradomo-User — a stable, unique identifier for this person’s account.
  • X-Meradomo-Email — their verified email address.
  • X-Meradomo-Name — the owner’s short name.
  • X-Meradomo-App — the name of your published app.
These arrive over the local loopback connection from the agent. Treat them as authoritative.

​
Visitors cannot forge these headers

A visitor’s browser connects to the shared relay, which forwards the encrypted connection to the user’s Mac without reading it. The agent decrypts it locally, strips any X-Meradomo-* headers the visitor supplied, verifies the identity, and only then sets the headers itself before passing the request to your app. The local loopback hop — between the agent and your app — is not reachable from the network, so there is no path for a visitor to inject a forged header.

​
The shared infrastructure cannot read the traffic

The relay forwards sealed bytes. The user’s private key lives only on their Mac. While the Mac is online the relay has no key for that address, so it physically cannot decrypt the traffic. The only exception: when the Mac is offline, the relay briefly shows visitors a short “this computer is asleep” page using a short-lived key held in memory only during that period. As soon as the Mac is back online, the relay returns to forwarding sealed bytes.

​
Revocation takes effect within seconds

If the user disconnects an app (from the menu-bar app or their account dashboard), its access stops within a few seconds. The agent keeps a current list of authorized apps and refuses requests from any that have been removed.

​
What Meradomo does not do

  • It does not log, inspect, or store the content of requests or responses.
  • It does not share the user’s data with third parties.
  • It does not retain copies of the private key.

​
The shared engine’s trust boundary

When you embed the engine, several apps can share one engine on the same machine. The trust boundary there is the local machine and user account, and it is enforced two ways:
  • Loopback only. The engine’s management surface binds 127.0.0.1 — nothing off the machine can reach it. Its private state (credential, cookie secret, keys) is written to the user’s own application-support directory with owner-only file permissions.
  • Same user. Any process running as the same user is already inside this boundary, so the management surface has no secret of its own. This is the same trust level as a config file in your home directory: a hostile process running as you could read it — but such a process has already compromised the account.
What this boundary is not asked to do is decide who may reach the computer from the outside — that is always the signed-identity check above, re-run on every request.

​
Approving apps

Because any local app can ask the engine to publish, the engine separates the app it ships with from the rest:
  • The engine’s first-party app (the app that bundled it, named at spawn) is auto-approved — it goes live without a prompt.
  • Any other app that attaches to a shared engine is pending until the owner approves it in their account dashboard. The approval travels to the engine over the same signed, polled channel as membership and grants, so turning an app off takes effect within one cycle.
The first-party id is a policy knob, not a secret: a hostile same-user process is already past the boundary, so the point of the split is that an honest third-party app declares its own id and correctly lands in pending — never that the id is unguessable.

​
The identity headers stay non-spoofable

Sharing an engine changes none of the identity guarantees above. The agent still strips every X-Meradomo-* and X-Forwarded-* header a visitor supplies and injects only the identity it verified itself, per app. One app attached to the engine cannot cause another’s requests to carry a forged identity.

​
Summary for app developers

Your app receives a verified X-Meradomo-Email on every request. You do not need to implement sign-in, and you do not need to verify signatures or tokens — the agent has already done that. Trust the X-Meradomo-* headers and build on top of them.