Share by Email

Getting information out of someone who doesn't use your tools is the hard part. You send them a doc, they send back a paragraph in an email, and you retype it into the place it was supposed to go. The retyping is where things get lost.

Sharing by email removes that step. You share a brain or a note with an email address. The recipient gets the content in their inbox and replies to it like any other email. Their reply comes back into BlackOps attributed to them, in the right place, without anyone copying and pasting.

They never make an account. They never see BlackOps at all.

Sharing a brain

share_brain(
  brain_id: "Product",
  recipient_email: "dana@example.com",
  recipient_name: "Dana",
  message: "Anything here look wrong to you?"
)

The recipient gets a clean summary of the brain — not a raw dump of every note — plus your message, verbatim if you wrote one. The email comes from a reply-to address unique to that one share.

When Dana replies, the reply is parsed and turned into proposed edits against the brain, held for you to review rather than applied. A brain is a compiled thing that other work reads from, so an outside reply doesn't get to silently rewrite it. You see what she said and what it would change, and you decide.

Sharing a single note

share_note(
  note_id: "Daily Brief",
  recipient_email: "dana@example.com"
)

Same idea, different destination and different write behavior. The recipient gets the note's own content, and their reply is appended directly to the note as a dated entry under a ## Replies heading, created if it isn't there yet.

Appending is deliberate. A note reply is free text with no guaranteed structure, so there's no safe way to merge it into the body — a rule that could overwrite would eventually destroy a note on a stray or malformed reply. Everything else in the note is left exactly as it was, including sections that come after ## Replies. Multiple replies stack up in arrival order.

That makes share_note the right tool when you want a specific thing back from a specific person: a daily brief you reply to with what actually happened, a draft you want one round of notes on, a question attached to the note it concerns.

Which to use: share a brain when you want someone's input folded into a body of knowledge, reviewed by you first. Share a note when you want a conversation attached to one specific document.

Revoking a share

Every share has a live reply address until you turn it off. unshare_brain and unshare_note turn it off.

unshare_note(note_id: "Daily Brief", share_id: "…")

Pass share_id when you have it — it comes back from share_note and share_brain and names exactly one share. If you only have the address, pass recipient_email instead and every active share of that brain or note to that recipient is revoked at once. Partial revocation isn't offered on purpose: leaving one live address behind is the failure the tool exists to prevent.

After revoking, a reply to the old address is dropped, and the sender gets a bounce telling them the address no longer works. Silence would leave them believing they'd been heard.

Revoking does not delete anything. Replies that already landed stay where they are — in the brain's audit trail, or in the note's ## Replies section. It stops what happens next; it isn't an undo.

What happens to replies that shouldn't be there

A few gates run before any reply is written anywhere:

• Unknown address. Logged, then nothing — no bounce. A bounce would tell someone probing addresses which ones used to be real.
• Revoked share. Logged, and the sender gets the bounce described above.
• Wrong sender. A reply has to come from the address the share was sent to. Someone forwarding your share email to a third party doesn't hand that person write access.
• Auto-responders and mailing-list mail. Dropped, with no bounce — bouncing a bot invites a loop. Out-of-office replies aren't input.
• Failed DKIM. Rejected when the signature is present and fails. Mail with no DKIM signature at all is allowed through, since plenty of legitimate senders don't sign.

Every inbound email is recorded either way, including the rejected ones, so "did Dana ever reply?" has an answer even when the reply never made it through.

Email redaction

If your workspace has Redact email addresses on vault sync turned on (Knowledge Settings, off by default), recipient addresses are stripped from everything the reply flow commits to your vault — note bodies, filenames, commit messages. The recipient shows up as their name plus a stable tag instead, so you can still tell replies apart without their address sitting in your git history. With the setting off, replies persist exactly as received.