Open app →
Documentation

Public sharing

Publish boards, pages, saved views, and meetings to no-login links backed by revocable, unguessable tokens, with anonymous comments, page export, and a guest Ask scoped to shared content.

The sharing model

Most of Elliptic lives behind a login, scoped to your organization and your project memberships. Public sharing is the deliberate exception: a handful of surfaces you can open up to people who do not have an account, so a board, a page, a saved view, or a meeting can be read by anyone holding the link. Every one of these surfaces works the same way under the hood, which makes the model easy to reason about and easy to undo.

When you publish something, Elliptic mints a secrets-based token, a long, unguessable random string, and that token becomes the public URL. The token is the only thing standing between the world and the content, so the link is the secret. Nothing about the public surface is searchable or listed: the only way in is the link itself. Share it with the people who should see it, and treat it like a password.

Public surfaces are read-only or narrowly scoped by design. A public board shows only the task attributes you choose. A public page renders your note as HTML and accepts anonymous comments, nothing more. A public view is a read-only list of tasks. A shared meeting shows the summary and, only if you opt in, the transcript. No public surface lets an anonymous visitor change anything inside your org.

And every public surface is revocable. Publishing is reversible at any moment: unpublish a board, page, or view and the token is cleared, so the old URL stops resolving and returns a not-found page. Revoke a meeting share and the link goes dead. There is no separate cleanup step, the link simply stops working the instant you pull it.

Visibility caveat
A public link is a capability, not a wall. Anyone who has the URL can open it, and they can forward it. Elliptic does not log anonymous readers in, so you cannot tell who has visited. If something must never leave the org, do not publish it. If you published and changed your mind, unpublish or revoke immediately. Note that re-publishing the same thing mints a brand-new token, so the previous link stays dead.
Air-gapped instances
If your Elliptic is self-hosted on a private network, public links resolve only to people who can reach that network. A public board on localhost or an internal host is public only to those already inside the perimeter. On the hosted instance at elliptic.sh, a published link is reachable from the open internet. Know which one you are on before you share.

Because agents are first-class members of your org, the same publish and revoke actions are available to them over the company-brain MCP. An agent can mint, change, or revoke a meeting share through create_meeting_share, update_meeting_share, and get_meeting_share, on your org's own key, exactly as a person would from the web app.

Public boards

A public board publishes a project's Kanban board to a no-login URL. It is the right tool when you want an external partner, a client, or the whole company to follow a project's progress without giving anyone a seat in your org. Visitors see the board grouped into status columns exactly as your team sees it, but as a read-only snapshot they can never edit.

What makes a public board safe to share is that you decide, attribute by attribute, how much of each task is exposed. A task always shows its identifier (like WEB-42) and its title. Everything beyond that is opt-in. You choose from four extra visible attributes, plus status, which is always the column grouping:

  • Priority, the task's priority level. A task whose priority is none shows no priority badge.
  • Assignee presence, whether the task is assigned or not. The board shows an assigned badge, never the person's name or identity, so you can signal that work is owned without exposing who owns it.
  • Due date, the task's due date.
  • Labels, the names of the labels attached to the task.
  • Status, which is always how the board is organized: tasks are grouped into one column per status, so status is shown whether or not you select anything else.

The board only ever shows real, active work. Archived tasks are excluded, and so are triage items (inbound, unaccepted work waiting in the triage queue). Tasks appear in the same order your team sees them on the board, and the public page hides any status column that has no tasks in it, so the link stays tidy.

  1. Open the project board
    Go to the project whose Kanban board you want to share.
  2. Publish the board
    Choose to publish the board. Elliptic mints a token and gives you a public path of the form /public/boards/<token>.
  3. Pick the visible attributes
    Select which of priority, assignee presence, due date, and labels should appear. Anything you do not select is simply absent from every card. Status is always shown as the column grouping.
  4. Share the link
    Send the URL. The reader lands on a page headed "Public board · read-only". They see your columns, cards, and only the attributes you chose.

You can change your mind without re-sharing. Updating the board's privacy keeps the same token and the same URL, it only changes which attributes are visible. So you can tighten a board (drop labels, hide due dates) or loosen it later, and everyone holding the existing link sees the change the next time they load it.

Unpublishing a board clears its token. The old link returns a "Board not found" page that tells the reader the link has been unpublished or does not exist. If you publish the same board again later, it gets a fresh token, so the previous URL never comes back to life.

Attribute changes are filtered
Only the five recognized attributes (status, priority, assignee, due date, labels) are ever honored. Anything else you pass is dropped on the way in. There is no way to expose task descriptions, comments, assignee names, or any other field through a public board, the surface is intentionally limited to these five.

Public pages

A public page publishes a note as a rendered web page anyone can read. It is the way to turn a spec, a changelog, an announcement, or a policy into a clean public document without copying it anywhere. Publishing mints a token and a path of the form /public/pages/<token>, and the reader sees your note's title, its icon, and its body rendered as HTML.

Rendering uses a small, safe subset of Markdown: headings, bold, italic, inline code, links, bullet lists, code fences, and paragraphs. Your note's content is run through that converter into the page, and the text is escaped first, so what you write in the note is what readers see, formatted and readable, with no raw HTML injection.

Anonymous comments and abuse reports

A public page accepts anonymous comments. Any reader can leave a name (optional, it defaults to "Anonymous") and a comment body, with no account and no login. New comments appear oldest-first under the page. This makes a public page a lightweight way to collect feedback on a draft or an announcement from people outside your org.

Because comments are anonymous, every comment carries a report control (a flag icon that appears on hover). Anyone can report a comment they consider abusive. A reported comment is hidden from the public page right away, it no longer appears to readers, so the community can keep an open page clean without waiting on a moderator.

Open the gate deliberately
A published page is readable and commentable by anyone with the link. If you only want feedback from named teammates, keep the note private and use in-app sharing instead. Publish a page when you genuinely want it open to the world.

Unpublishing a page clears its token, and the old link returns a "Page not found" page. There is one more rule worth knowing: an archived page 404s even while a token is set. If you archive a note that was published, its public link immediately stops resolving and returns not-found, so archiving doubles as a fast way to take a page offline. Un-archive it and, if the token is still set, it resolves again.

Exporting a page

Separate from publishing, you can export any note as a file to take it out of Elliptic. Export does not create a public link, it just downloads or opens the content. There are two formats, plus print-to-PDF:

FormatWhat you get
MarkdownA .md file whose first line is the note's title as a top-level heading, followed by its raw Markdown content. Ideal for moving a note into another tool or a repo.
HTMLA standalone, self-styled HTML document with the title, the rendered body, and clean built-in typography (a readable column width and styling for headings, code, and links). It opens in a browser, and because it is a complete document it also opens in a word processor.
PDFThere is no separate PDF export. Open the HTML export and use your browser's print-to-PDF. The HTML is styled to print cleanly, with a readable column width, so the printed result looks like a proper document.

Public views

A saved view is a named, filtered slice of your tasks (by status, assignee, label, or search). A public view publishes that saved view as a read-only link. It is the lightest of the public surfaces: where a public board shows a whole project's columns, a public view shows exactly the filtered list of tasks the view defines, and nothing more.

Publishing a view mints a token and a path of the form /public/views/<token>. The reader sees the view's name and its tasks, each with its identifier, title, status, and priority. As with public boards, archived and triage tasks are excluded, and the view's own filters are applied, so the public list mirrors the view's definition. There is no editing and no per-reader gating: anyone with the link sees the same read-only dataset.

Only someone who can modify the view can publish or unpublish it. Personal views are publishable by their owner, teamspace views by a team member or an admin, and org-wide team views by an admin. Unpublishing clears the token and the old link returns a "View not found" page.

Board or view?
Reach for a public board when you want partners to see a project's full Kanban with columns and chosen attributes. Reach for a public view when you want to expose one focused, filtered list, for example "open bugs labeled customer" or "everything in review", without the rest of the board.

Shared meetings with guest Ask

A shared meeting publishes a single meeting to a tokenized link at /share/meetings/<token>, so someone who was not in the room, and who has no account, can catch up. The guest view leads with what matters: the meeting title, the AI summary, the action items, and the decisions, pulled from the meeting's latest summary. It deliberately surfaces what was decided and who owns what, rather than replaying the whole conversation.

The full transcript is optional. When you mint a share you choose whether to include it, and the default is off. With the transcript off, guests see only the summary, action items, and decisions. With it on, the guest view adds the timestamped, speaker-attributed transcript below the decisions. This lets you share an outcome without exposing every word that was said.

Guest Ask

Every shared meeting carries a guest Ask panel, headed "Ask about this meeting". A visitor can type a question and get an AI answer, with no login. The answer is scoped strictly to the shared content. If the transcript is included, the model answers from the transcript. If it is not, the model answers from the summary instead. Nothing else in your org is ever in scope, the guest cannot reach other meetings, tasks, or notes.

If there is no shared context to answer from (no transcript and no summary), the guest Ask says so plainly rather than guessing, returning a message that there is not enough shared context to answer. Each answer also carries a grounded flag under the hood, signalling whether it was actually backed by a transcript or a summary. The page reminds guests, in a line below the Ask box, that AI answers are scoped to the meeting and that anything important should be verified.

Whose key runs the guest answer
There is no anonymous AI budget. A guest's question runs on your organization's own model key (BYOK), on behalf of the meeting's owner. The guest never sees or supplies a key. Your org pays for, and controls, the model that answers, the same key that powers every other AI feature in Elliptic.

You stay in control of a share after you mint it. You can toggle the transcript on or off at any time, which changes both what guests see and what their Ask can draw from, and you can revoke the share entirely. A revoked link goes dead immediately and the guest page shows "This link is no longer available", suggesting they ask the owner to share it again. Re-sharing the same meeting re-enables the existing token, and the transcript setting you pass takes effect. Only the meeting's creator or an org admin can create, change, or revoke a meeting share.

  1. Open the meeting
    Go to the meeting you want to share. Make sure it has been summarized, the summary, action items, and decisions are what guests see first.
  2. Create the share
    Mint a public share and decide whether to include the transcript (it is left out by default). Elliptic generates the /share/meetings/<token> link.
  3. Send the link
    Share the URL. Guests land on the summary, action items, and decisions, plus the transcript if you included it, and can ask questions in the guest Ask panel.
  4. Adjust or revoke
    Later, toggle the transcript or revoke the share. Revoking kills the link at once. Toggling the transcript reshapes both the view and what guest Ask can ground on.

Public intake

The public surfaces above are all about letting people read your work. Public intake forms are the inbound counterpart: a no-login link where someone outside your org can submit a request that lands in a project's triage queue. The boards, pages, views, and meeting shares push information out, an intake form pulls work in.

An intake form lives at a tokenized link (under /intake/<token> or /intake-forms/<token>) and asks only for a short summary, optional details, and an optional name and email, no account required. On submit, the request is logged as a triage task in the target project, tagged as inbound, and the submitter gets back a reference number to track it. From there it flows through your normal triage and automations, just like any other inbound task.

Where to set intake up
This page covers intake only as the inbound public surface. Creating a form, choosing its target project, and managing submissions live with the triage and automations features that route inbound work, where you can also see how a submitted request becomes a triage task and gets sorted onto a board.

At a glance

SurfacePublic URLWhat's exposedDirection
Public board/public/boards/<token>A project's Kanban grouped by status, with the task attributes you chooseRead-only out
Public page/public/pages/<token>A note rendered as HTML, with anonymous comments and abuse reportsRead + comment out
Public view/public/views/<token>A saved view's filtered task list (identifier, title, status, priority)Read-only out
Shared meeting/share/meetings/<token>Summary, action items, decisions, optional transcript, plus a scoped guest AskRead + ask out
Public intake/intake/<token>A no-login form that submits a request into a project's triage queueSubmit in

Every row above mints a revocable, secrets-based token, and every one can be pulled back the instant you no longer want it open. Page export is the one exception that is not a link at all, it just hands you a file. When in doubt, publish narrowly, share the link only with the people who need it, and revoke the moment the work is done being public.