Cremind Connect overview

Cremind Connect is a small, open-source service that lets your local Cremind app link provider accounts — Gmail, Calendar, and Jira — and receive real-time events, without you having to register your own OAuth credentials or stand up a cloud project, and without the service ever storing or even seeing your data or your OAuth tokens.

It runs on Cloudflare Workers and Durable Objects, is MIT-licensed, and is deliberately tiny and auditable: anyone can read the source to confirm exactly what it does (relay content-free event nudges) and what it does not do (hold tokens or user content).

Why it exists

Linking a provider for real-time events normally forces an end user to provision infrastructure they realistically can't: a Pub/Sub topic and a verified OAuth consent screen for Gmail, a domain-verified webhook for Calendar, or a confidential OAuth app for Atlassian. Cremind Connect owns exactly those organization-level pieces — and nothing else — so you don't have to.

The result for a Cremind user:

• No cloud project. You don't create a GCP project, a Pub/Sub topic, or an Atlassian developer app. You just approve a consent screen in your browser.
• Tokens stay on your machine. The exchange that mints your access and refresh tokens happens locally; the relay is not a place your tokens live.
• Content never reaches the relay. When something changes in your inbox, calendar, or Jira, the relay forwards a content-free "resync" nudge — never the email, the event, or the issue.
• Open and auditable. It's a public MIT repo on Cloudflare's platform, small enough to read end to end.

How it fits with Cremind

Cremind is event-driven: skills push real-world events straight into the agent over a live connection instead of polling on a timer (see Event-driven architecture). Cremind Connect is the piece that makes that possible for cloud providers without per-user cloud setup.

When a provider account changes, Connect nudges your app over a WebSocket; your app then performs its own incremental sync locally, using its own token, and hands the result to a skill's event listener. Connect accelerates delivery — it is not a queue or a store.

The core idea: two planes

Connect cleanly separates who holds your tokens from who relays your events:

• Authorization plane — your local app authenticates directly with the provider and keeps the tokens. For Google, the relay is never in the token path at all. For Atlassian, the relay briefly performs the confidential token exchange and hands the tokens straight back, storing nothing.
• Event plane — the relay verifies the provider's push, derives a routing key from the payload, and broadcasts a content-free nudge to every app that proved control of that account.

This split is what lets the service be useful without ever becoming a custodian of your data.

Linking a provider, end to end

From a Cremind user's point of view, linking an account is a short browser flow:

1. A skill (for example, gmail or jira) surfaces a consent URL.
2. You open it and approve access in your browser.
3. The redirect is caught by Cremind's always-running backend loopback listener, so the link completes in the background — you don't paste anything back.
4. The skill saves your tokens locally on your machine.

From then on, provider events arrive in real time over the relay, and your skills react to them. The exact commands differ per skill; see the Providers page and each skill's own documentation for specifics.