Stickies 0.1 (draft)

A small, open format for moving sticky notes between apps by copy and paste, drag and drop, or an agent's tools.

Status: draft. Anything here can change before 1.0.

Works with Murmur.

1. Goals

• Works today. A copied note pastes as readable text or a styled box into apps that have never heard of this format.
• Keeps what matters. Between apps that support it, a note keeps its text, colour, state, size, author and where it came from.
• Small. One note with just its text and position is a valid document.
• Builds on JSON Canvas. Every Stickies document is a valid JSON Canvas 1.0 file, so Obsidian and other JSON Canvas tools can open it.

Not goals for 0.1: live sync, comments, permissions, or images inside notes.

2. Document

A Stickies document is a JSON Canvas document with one extra top-level field, stickies, that gives the version.

{
  "stickies": "0.1",
  "source": { "app": "Murmur", "url": "murmur://conversation/c_8f2" },
  "nodes": [
    {
      "id": "n_41a",
      "type": "text",
      "text": "Sticky notes as an open standard",
      "x": 0, "y": 0, "width": 240, "height": 160,
      "color": "#fdf6c8",
      "colorName": "yellow",
      "state": "progress"
    }
  ],
  "edges": []
}

A receiver MUST ignore fields it doesn't know. A receiver SHOULD accept any document whose major version it knows (0.x for now) and do its best with the rest.

3. Notes

Each note is a JSON Canvas text node. JSON Canvas requires the first group below; this spec adds the second.

From JSON Canvas

Added by Stickies

Positions are relative. A receiver places the group wherever suits it, such as under the cursor, and keeps the notes' positions relative to each other.

4. Colour

Colour is for display only. It never carries meaning; that's what state is for.

Named colours:

• A sender SHOULD send both colorName and color.
• A receiver that knows the name SHOULD use its own version of that colour, including its dark-mode version, not the hex.
• A receiver that doesn't know the name, or has a different palette, SHOULD use the hex, or the nearest colour it has.
• A note with no colour is yellow.

color stays a hex so the document is still valid JSON Canvas. JSON Canvas's numbered presets ("1" red to "6" purple) don't match sticky-note palettes, and a number says nothing about the colour across apps.

5. Source

Where notes came from, so a receiver can link back ("Open in Murmur") and an app can recognise its own notes when they come back.

"source": {
  "app": "Murmur",
  "url": "murmur://conversation/c_8f2/note/n_41a",
  "id": "n_41a"
}

The document-level source applies to every note. A note's own source overrides it field by field.

6. State

A note can say where it is in a simple workflow:

State is kept separate from colour. A note that's done keeps its own colour; a receiver chooses how to show the state, for example a tick, a column, a strikethrough, or a colour of its own.

• A receiver that doesn't support state MUST still show the note, in its own colour.
• A receiver that only supports open and done SHOULD treat progress as open, and SHOULD send it back as progress if the note comes back unchanged.
• A receiver MUST treat an unknown state as open.

7. Extensions

App-specific data goes under ext, keyed by a short name the app owns:

"ext": {
  "murmur": { "workItem": true }
}

• Receivers MUST ignore extensions they don't know.
• Receivers SHOULD keep unknown extensions when they store a note, and send them back on copy, so data isn't lost passing through an app.
• An extension MUST NOT change what a core field means.

Extensions that several apps adopt can move into the core in a later version.

8. Clipboard and drag and drop

When a person copies or drags notes, the sender puts several versions on the clipboard at once. The receiver takes the richest version it understands.

8.1 Format names

8.2 HTML

Browsers don't let every page read custom clipboard types, so the HTML version also carries the document. The outer element has a data-stickies attribute with the full JSON document, HTML-escaped:

<div data-stickies="{&quot;stickies&quot;:&quot;0.1&quot;,…}">
  <div style="background:#fdf6c8;color:#3b3214;padding:12px 14px;border-radius:6px;width:240px;margin:0 0 8px;font:14px/1.4 system-ui,sans-serif">
    Sticky notes as an open standard
  </div>
</div>

• Notes go in reading order (top to bottom, then left to right).
• Styles are inline so they survive pasting into documents and email.
• A receiver that finds data-stickies SHOULD use it instead of the visible HTML.
• Receivers MUST find the element by its attribute, not by position: browsers may wrap pasted HTML in <html><body>, and other apps may add their own markup around it.

8.3 Plain text

Each note's text, in reading order, separated by a blank line. No markers or metadata.

8.4 Receiving

A receiver SHOULD:

1. Read the Stickies JSON if it's there.
2. Otherwise, look for data-stickies in the HTML.
3. Otherwise, fall back to its usual paste.

If the document's source shows it came from the receiver itself and the notes still exist, the receiver MAY offer to move or link them instead of making copies.

8.5 On the web

Web pages SHOULD write all three versions in a copy (or cut) event, with event.clipboardData.setData(), and read them in a paste event, with event.clipboardData.getData(). What browsers allow, tested in October 2026 with Chromium, WebKit and Firefox:

So the HTML version is the only one that reaches every receiver, and it's required for pages (§8). Pages SHOULD NOT rely on navigator.clipboard for copying notes. A page that has to copy outside a copy event, such as from a "Copy" button, SHOULD write text/html and text/plain with navigator.clipboard.write(), and rely on data-stickies.

Browsers may store custom types in their own private clipboard format, which native apps can't read. Native apps receiving from a browser SHOULD therefore check public.html (or CF_HTML on Windows) for data-stickies.

9. Agents (MCP), non-normative

The same note shape works for agent tools. An app that offers MCP tools for notes SHOULD accept and return notes in this shape, so an agent can move notes between apps without converting them. A suggested set:

For tool input, x, y, width and height are optional; the app places notes itself when they're missing. Full tool definitions are for a later version.

10. Security

• text is Markdown from someone else. Receivers MUST sanitise any HTML it renders to, and MUST NOT run scripts from it.
• Receivers MUST NOT open source.url or links in text without the person asking.
• Receivers SHOULD set a size limit (for example 1 MB per document, 1,000 notes) and refuse anything larger.

11. Implementations

12. Open questions

1. Name. "Stickies" is also the name of Apple's Stickies app. Fine for a format, but search results will be crowded, so docs should say "the Stickies format" or "stickies.live".
2. Time format. ISO strings are easier to read; milliseconds are what Murmur and many apps store. ISO is the current pick.
3. More colours. Is a seventh, such as orange, worth it? Unknown names already fall back to hex.
4. Plain-text state. Should done notes copy as - [x] text in plain text? It helps Markdown apps but adds noise everywhere else.
5. Anchors. Murmur notes sit beside a message (nearNode). Is "attached to something" general enough for the core, or should it stay an extension?
6. Groups and frames. JSON Canvas has group nodes. Should a group of notes travel as one?