Xcursi

Embed Xcursi

Add an Xcursi thread to any site with one div, one script tag, strict CSP support, and authenticated posting.

Add Xcursi to an existing page.

Paste a tiny widget into an article, docs page, or project site and give that page a real conversation space. The embed is framework-free, does not ship React to the host page, and works under a strict CSP without inline styles or eval.

<div id="xcursi-root"></div>
<script
  src="https://app.xcursi.com/xcursi.js"
  data-page-slug="my-article"
  data-api-url="https://api.xcursi.com"
></script>

Use the production Xcursi domains exactly as shown. Do not leave placeholder hosts such as example.com or community.example.com in production embeds. The script loads from the app host, while data reads go through the API host.

data-page-slug should be stable, URL-safe, and unique for the page being embedded. Changing it later makes Xcursi look for a different page context.

What the embed shows

Website setup

You do not need to install an Xcursi package or run Xcursi on your own server. Add the snippet to the page where the discussion should appear.

Use the same pattern in any web framework:

• Static HTML: paste the div and script where the discussion belongs.
• Astro, Jekyll, Hugo, Eleventy, or Markdown sites: put the snippet in the page template or page body after the article content.
• React, Next.js, Vue, Svelte, or Nuxt: render the div, then load the script with your framework’s script component or a normal script tag after hydration.
• WordPress or CMS pages: add the snippet in a custom HTML block or theme template.

Choose one stable slug per page. Good examples:

icdevs-home
motoko-getting-started
blog-2026-07-xcursi-launch

Avoid slugs that change on every build, such as random ids, timestamps, or preview URLs.

Before launch

1. Sign in at https://app.xcursi.com.
2. Create or open the Xcursi Page for the URL where the embed will appear.
3. Use the Page slug in data-page-slug.
4. Add the snippet to the host page.
5. Add the CSP rules below if your site uses a Content Security Policy.
6. Open the page in a private browser window and confirm that threads load.
7. Click sign in, register, reply, and start thread. They should open inside an Xcursi panel without navigating your site away.

Visitors cannot post anonymously. They sign in through Xcursi before replying or starting a thread.

Hosted Xcursi handles the API side for you. If you see references to BCHATTY_ environment variables in developer notes, those are historical self-hosting/development settings, not steps for embedding Xcursi on your website.

CSP friendly by design

The widget needs the Xcursi app and API origins in your host page CSP:

script-src 'self' https://app.xcursi.com;
style-src 'self' https://app.xcursi.com;
connect-src 'self' https://api.xcursi.com https://app.xcursi.com;
frame-src 'self' https://app.xcursi.com;

It injects one stylesheet link, emits no inline style attributes, and talks to the API over ordinary fetch calls to the tRPC endpoints.

The CSP belongs to the site that embeds Xcursi. If that site blocks app.xcursi.com in frame-src, the in-page sign-in panel cannot open. If it blocks api.xcursi.com in connect-src, the widget cannot load pages, threads, or posts. Some browsers may also fetch Xcursi assets from the app host, so include https://app.xcursi.com in connect-src.

Current support

The embed works through the API-backed deployment path today. Public reads go through https://api.xcursi.com; authenticated writes happen inside the Xcursi app panel. A browser-only embed that talks directly to the IC canister is still a future feature.

For self-hosting and development details, see the repository guide at docs/embed.md.