# Community and social playbook

## Purpose

Enigma community channels exist to help users, developers, enterprises, and future network operators understand and use provider-neutral AI memory/proof infrastructure. The community should make three ideas concrete:

1. AI memory should be portable across tools instead of trapped in one provider.
2. Enigma stores memory in local-first or customer-controlled vaults and emits signed receipts for Enigma-mediated memory lifecycle and boundary events.
3. Optional relay, witness, gateway, governance, and token materials are about network utility and access; they are not company ownership, holder proceeds, or a reason to speculate.

Pinned one-liner:

> Enigma is the memory card for AI: portable context, local-first custody, and offline-verifiable receipts across models and agents.

Pinned paragraph:

> Enigma is provider-neutral AI memory/proof infrastructure. It gives users and organizations portable Memory Passports, local-first or customer-controlled vaults, scoped context injection into AI workflows, and signed receipts for memory lifecycle and boundary events. **Standard proof boundary:** Enigma proves Enigma-mediated state, receipts, gateway/relay/witness artifacts, and verifier results; it does not prove external provider internals, provider-native deletion, hidden logs/caches/backups, model or semantic forgetting, or factual truth.
## Audience map

| Audience | Job to be done | Best channel | Primary CTA |
| --- | --- | --- | --- |
| AI power users | Carry useful memory across AI tools | Discord, Telegram, X, Farcaster | Install locally and verify a receipt |
| MCP and agent developers | Add memory/proof to an agent workflow | Discord, Farcaster, X | Run MCP and inspect receipts |
| Security and enterprise evaluators | Understand custody, policy, and proof boundaries | LinkedIn, Discord, private demo | Request an architecture review |
| Relay/witness/gateway operators | Learn future network roles and rules | Discord, Telegram, Farcaster | Join the operator waitlist |
| Partners and ecosystem builders | Integrate passports, receipts, or gateways | LinkedIn, Discord | Join the builder program |

## Channel strategy

### Discord

Primary use: structured onboarding, support, builders, proof review, events, and contributor programs.

Recommended channels:

- `#start-here`: one-liner, install path, demo loop, FAQ, rules, support hours.
- `#announcements`: official posts only; comments off or heavily moderated.
- `#install-help`: CLI, vault, verifier, and MCP setup.
- `#receipts-and-proof`: sample receipts, verifier output, receipt boundaries.
- `#mcp-builders`: MCP client setup, tool behavior, integration questions.
- `#browser-extension`: explicit-injection browser workflow questions.
- `#enterprise-questions`: custody, deployment, gateway, SIEM, policy, limitations.
- `#relay-witness-gateway`: network-role education; token utility only.
- `#governance-utility`: governance and token utility education; pinned legal caution required.
- `#showcase`: user demos, builder integrations, receipt verification screenshots.
- `#incidents-and-security`: official security notices and phishing alerts.

Pinned start-here flow:

```sh
cd enigma
npm install -g .
enigma --help
```

```sh
enigma init --bundle ./.enigma/bundle.json --subject local-user --display-name "Local user"
enigma remember --bundle ./.enigma/bundle.json --text "Prefers concise release notes." --purpose user_memory --tags preference
enigma context --bundle ./.enigma/bundle.json --query "release notes" --purpose local_answer --out ./.enigma/context-pack.json
enigma export --bundle ./.enigma/bundle.json --out ./.enigma/export.json
enigma verify --bundle ./.enigma/export.json
```

### Telegram

Primary use: lightweight community updates, event reminders, and incident alerts.

Rules:

- Keep Telegram read-mostly during launch week.
- Pin official links, no-DM-token-sales rule, support redirect, and anti-phishing notice.
- Redirect detailed support to Discord `#install-help` or the docs.
- Do not troubleshoot private keys, wallets, seed phrases, or token transactions in DMs.

Pinned Telegram copy:

> Official Enigma team members will never DM first about token sales, special token access, wallet connection, seed phrases, private keys, or paid support. Enigma token materials, if published, are utility/governance/network-access materials and require legal review before publication. Use official links only and report suspicious accounts to moderators.

### X

Primary use: awareness, demo clips, launch threads, public proof challenges, and short technical explanations.

Post style:

- Lead with the demo or mechanism, not adjectives.
- Use concrete verbs: install, connect, create, verify, revoke/tombstone inside Enigma, export.
- Avoid token-first framing. If token is mentioned, state utility/network-access boundaries.
- Never use secondary-market, trading, scarcity, or benefit-promise language.

Default X bio draft, board/legal-review required:

> Provider-neutral AI memory/proof infrastructure. Portable Memory Passports, local-first vaults, MCP, and offline-verifiable receipts. Token materials require legal review.

### Farcaster

Primary use: crypto-native builders, open-source infrastructure discussion, governance education, and proof-network role education.

Post style:

- Make the network useful before discussing token mechanics.
- Frame relay/witness/gateway participation as service roles under published rules.
- Invite receipt-schema review, MCP integrations, and witness/relay design feedback.
- Link back to product install and proof verification first.

### LinkedIn

Primary use: enterprise, security, partner, analyst, and hiring credibility.

Post style:

- Use sober infrastructure language.
- Focus on local/customer-controlled custody, audit support, policy boundaries, and procurement demos.
- Avoid adversarial claims against model providers.
- Say Enigma supports audits and governance with evidence; do not claim compliance certification unless separately obtained.

Default LinkedIn company description draft, board/legal-review required:

> Enigma builds provider-neutral AI memory/proof infrastructure. Teams use Enigma to keep durable AI memory in local-first or customer-controlled vaults, inject scoped context into model/tool calls, and verify Enigma-mediated memory events with signed receipts. Enigma supports MCP workflows, enterprise gateway patterns, and optional relay/witness/gateway network infrastructure.

## Launch phases

### Phase 0 — Private readiness, 2-4 weeks before launch

Goals:

- Prepare safe community surfaces before public attention arrives.
- Recruit the first design partners and moderators.
- Prove that the install → MCP → memory → receipt → offline verification loop is explainable.

Actions:

- Open Discord with the channel structure above.
- Pin start-here, FAQ, code of conduct, anti-phishing policy, support triage, and token boundaries.
- Invite 20-50 design partners: AI power users, MCP builders, receipt/proof reviewers, enterprise security reviewers.
- Run three private demos: local install, MCP connection, receipt failure/tamper demo.
- Collect friction notes in one internal tracker and publish only resolved public guidance.

Required assets:

- 60-second proof-loop video.
- Sample receipt bundle that users can verify.
- Founder AMA outline.
- Operator waitlist description with no token benefit promises.
- Moderator escalation sheet.

### Phase 1 — Category reveal, launch day through day 3

Goals:

- Establish Enigma as AI memory/proof infrastructure, not a chatbot or token-first project.
- Drive the first public installs and receipt verifications.

Actions:

- Publish the launch thread and LinkedIn category post.
- Pin the product demo in Discord, Telegram, X, and Farcaster.
- Host a live install walkthrough using the local commands from the docs.
- Run a public receipt verification challenge: valid receipt, tampered receipt, verifier output.

Primary CTA:

> Install locally, create one memory, export a proof bundle, and verify it.

### Phase 2 — Developer proof, days 4-10

Goals:

- Turn attention into MCP integrations and receipt literacy.
- Make builders confident that the product has a real developer surface.

Actions:

- Host MCP office hours.
- Publish short examples for `enigma-mcp`, `enigma mcp serve`, and client connector commands.
- Feature one builder workflow per day in Discord and Farcaster.
- Run a receipt-schema review session.

MCP commands to feature:

```sh
ENIGMA_BUNDLE="$HOME/.enigma/bundle.json" enigma-mcp
```

```sh
ENIGMA_BUNDLE="$HOME/.enigma/bundle.json" enigma mcp serve
```

```sh
enigma doctor
enigma install --bundle "$HOME/.enigma/bundle.json"
enigma connect claude-desktop --bundle "$HOME/.enigma/bundle.json"
enigma connect cursor --bundle "$HOME/.enigma/bundle.json"
enigma connect generic-mcp --bundle "$HOME/.enigma/bundle.json"
```

### Phase 3 — Enterprise credibility, days 11-17

Goals:

- Translate memory/proof into controlled adoption, governance support, and pilot evaluation.
- Make proof boundaries explicit.

Actions:

- Publish enterprise architecture session invite on LinkedIn.
- Demonstrate gateway policy decisions without claiming the gateway calls providers.
- Show minimized SIEM/export concept and redacted audit bundle structure.
- Offer private architecture reviews for qualified teams.

Gateway commands to reference:

```sh
enigma gateway demo
enigma gateway serve --host 127.0.0.1 --port 8797
curl http://127.0.0.1:8797/health
curl http://127.0.0.1:8797/policy
```

### Phase 4 — Network education, days 18-24

Goals:

- Explain relay, witness, and gateway roles as optional infrastructure.
- Keep token communication factual, utility-oriented, and legally cautious.

Actions:

- Publish relay/witness/gateway explainer.
- Run an operator-readiness AMA focused on requirements, service accountability, and plaintext avoidance.
- Keep token discussion in `#governance-utility` and `#relay-witness-gateway` only.
- Repeat that token materials require legal review before publication.

Relay commands to reference:

```sh
enigma relay demo
enigma relay serve --host 127.0.0.1 --port 8787
curl http://127.0.0.1:8787/health
```

Opaque relay push example:

```sh
curl -X POST http://127.0.0.1:8787/relay/push \
  -H 'content-type: application/json' \
  --data '{"capsule_id":"cap_local_1","opaque_encrypted_record":"age1-example-ciphertext-only"}'
```

### Phase 5 — Habit and contributor growth, days 25-30

Goals:

- Convert users into repeat users, builders, enterprise pilots, and protocol reviewers.
- Showcase real demos without inflated claims.

Actions:

- Run the 7-day portable AI memory challenge.
- Publish weekly shipped/current/next update.
- Feature verified demos and builder integrations.
- Start contributor review cycles for docs, receipts, MCP connectors, browser extension testing, relay/witness design, and enterprise pilot feedback.

## Moderator rules

### Core rules

1. Keep discussion about product utility, proof, support, and network roles.
2. Remove spam, impersonation, phishing links, seed phrase requests, fake support, unauthorized token-sale posts, and fake token forms immediately.
3. Correct inaccurate product claims with a calm public reply when useful; remove repeat misinformation.
4. Move support issues into the correct support channel.
5. Keep token discussion out of product-support channels.
6. Do not allow claims that token ownership grants company ownership, user-data ownership, holder proceeds, priority access, or promised compensation.
7. Do not allow secondary-market speculation or benefit-promise discussion in official channels.
8. Do not claim Enigma proves provider deletion, model forgetting, semantic forgetting, or complete side-channel absence.
9. Do not claim legal or compliance outcomes; say Enigma provides evidence and controls that may support review.
10. Escalate security, legal, press, enterprise procurement, and token eligibility questions to designated internal owners.

### Moderator correction templates

Product proof boundary:

> Small correction: Enigma receipts prove declared Enigma-mediated operations were signed, ordered, and committed under a stated policy boundary. They do not prove model intent, factual truth, uninstrumented side-channel absence, or deletion from external providers.

Token boundary:

> Official Enigma token materials are limited to utility, governance participation, and network access for optional relay/witness/gateway infrastructure. Token ownership is not company ownership, not a claim on assets or user data, and does not grant holder proceeds. Token materials require legal review before publication.

Deletion boundary:

> Enigma can show Enigma-controlled tombstone/delete-request events and current Enigma serving behavior. It cannot prove a closed provider deleted hidden copies, removed provider-native memory, changed model weights, or caused a model to forget.

Relay privacy boundary:

> Relays should receive opaque encrypted records and commitments, not raw memory plaintext. Do not paste personal memory, prompts, transcripts, or private content into relay endpoints or public channels.

## Anti-fraud and anti-phishing policy

### Required pinned notice

> Safety notice: Official Enigma team members and moderators will never DM first to sell tokens, offer special token access, request wallet connection, ask for seed phrases/private keys, provide secret token links, or offer paid support. There are no official DM token sales. Use only official links from pinned channels. Report impersonators and suspicious links to moderators.

### Enforcement

- Ban impersonators, phishing links, fake support accounts, fake token forms, and no-DM-token-sales violations on sight.
- Delete wallet-drainer links and archive screenshots/URLs for internal incident records.
- Post a channel-wide warning if a phishing or impersonation campaign is active.
- Never ask users to reveal seed phrases, private keys, passwords, or private vault content.
- Never ask users to paste raw memory plaintext into public channels for debugging.
- For support debugging, ask for command output with secrets redacted and for proof artifacts only when safe to share.

### Official link hygiene

- Keep a single pinned official-links post in each public channel.
- Update old links instead of adding competing posts.
- Use link previews carefully; remove spoofed domains.
- For token or governance materials, require a legal-reviewed canonical page before moderators link it as official.

## Token communication rules

### Allowed framing

- The planned token, if launched, is intended for utility, governance, and network access within optional relay/witness/gateway infrastructure.
- Local-only Enigma memory, local vault custody, and offline receipt verification should be explained without requiring token ownership.
- Operators may be compensated only for verifiable active services under published network rules; do not describe compensation as a holder benefit.
- Governance is bounded to protocol parameters such as network fees, operator registry thresholds, witness quorum rules, schema upgrades, grants, and verifier requirements.
- Raw memories must not be stored on Solana; only opaque roots, commitments, service metadata, or settlement/accountability records may be used when legally and technically approved.
- SPL tokens use Mint Accounts and Token Accounts. Token-2022 can add optional extensions; most extensions must be planned at mint creation. MetadataPointer points to metadata, and TokenMetadata can store name, symbol, URI, update authority, and custom metadata on the mint.

### Required caution

> Token-related materials are drafts until legal review and technical signoff are complete. Publication requires jurisdiction, eligibility, sanctions, tax, governance, risk, and marketing-claims review.

### Prohibited framing

- No claims that token ownership grants company ownership, holder proceeds, user-data ownership, dividends, or claims on assets.
- No secondary-market, trading, scarcity, or benefit-promise language.
- No promises of special token access or operator benefits unless a legally reviewed official program exists.
- No passive staking language. Use active-service bonding where applicable.
- No statements that token governance can control private user memories, company operations, customer contracts, employee decisions, or retroactively alter receipts.

## Support triage

| Issue | First response | Escalation |
| --- | --- | --- |
| Install failed | Ask OS, Node version, install method, exact command, redacted error | Maintainer if package/bin path issue repeats |
| Vault init issue | Ask for command used and bundle path; remind not to share private vault content | Maintainer if receipt/vault state appears inconsistent |
| MCP client not connecting | Ask client name, generated config, `ENIGMA_BUNDLE` path, and whether `enigma-mcp` runs | MCP maintainer for client-specific config bugs |
| Receipt verification failed | Ask whether receipt was edited, exported from Enigma, or copied through a formatter | Proof maintainer if valid exports fail |
| Browser extension issue | Confirm unpacked extension path, native host name, explicit click flow, provider page | Browser maintainer if reproducible |
| Relay/gateway issue | Confirm local command, port, health endpoint, and that only opaque records are sent | Infrastructure maintainer if server rejects valid opaque payload |
| Enterprise or legal question | Do not improvise legal/security commitments | Enterprise/legal owner |
| Token, governance, eligibility | Provide boundary copy only; no private advice | Legal/governance owner |
| Fraud/phishing | Ban/delete, warn channel, archive evidence | Security owner |

Support response standards:

- Ask for the smallest safe diagnostic output.
- Do not request secrets, private keys, seed phrases, private vault contents, raw memory plaintext, credentials, or customer data.
- Use docs commands exactly when guiding users.
- State when a path is local-only, demo-only, or requires hosted deployment credentials.
- Keep product support separate from token discussion.

## Demo event formats

### 1. Sixty-second trust loop

Flow:

1. Install from checkout.
2. Initialize a local vault.
3. Write one memory.
4. Compile a context pack.
5. Export proof bundle.
6. Verify offline.

Demo command set:

```sh
cd enigma
npm install -g .
enigma init --bundle ./.enigma/bundle.json --subject local-user --display-name "Local user"
enigma remember --bundle ./.enigma/bundle.json --text "Prefers concise release notes." --purpose user_memory --tags preference
enigma context --bundle ./.enigma/bundle.json --query "release notes" --purpose local_answer --out ./.enigma/context-pack.json
enigma export --bundle ./.enigma/bundle.json --out ./.enigma/export.json
enigma verify --bundle ./.enigma/export.json
```

Boundary to say out loud:

> This proves Enigma-mediated vault and receipt events. It does not prove what a closed model provider did internally.

### 2. MCP office hours

Flow:

1. Create local bundle.
2. Start `enigma-mcp` over stdio.
3. Show generic MCP JSON.
4. Connect one supported client.
5. Use MCP tools to initialize, remember, search, create a context pack, delete, and verify receipts.

Tools to name:

- `enigma_init`
- `enigma_remember`
- `enigma_search`
- `enigma_context_pack`
- `enigma_delete`
- `enigma_verify_receipts`

Resource and prompt:

- `enigma://passport/summary`
- `enigma_standard_memory_prompt`

### 3. Receipt failure demo

Flow:

1. Verify an unmodified export.
2. Explain receipt fields at a high level.
3. Tamper with one field in a copy.
4. Run the verifier again and show failure.
5. Explain that a failed receipt is useful evidence, not a product failure.

### 4. Browser extension walkthrough

Flow:

1. Show `apps/browser-extension` as an unpacked Manifest V3 scaffold.
2. Explain native messaging host `com.enigma.native_host`.
3. Visit a supported provider page.
4. Use explicit user approval before inserting Enigma context.
5. Show insertion receipt metadata.

Boundary:

> The browser extension requires explicit user approval before inserting context and does not prove provider-side deletion or model forgetting.

### 5. Relay/witness/gateway education session

Flow:

1. Run relay demo.
2. Show that relay accepts opaque encrypted records, not plaintext memory.
3. Run gateway demo.
4. Show policy decision metadata.
5. Explain witnesses/checkpoints as optional proof-network infrastructure.
6. State token utility boundaries and legal-review requirement.

### 6. Enterprise architecture session

Flow:

1. Explain hosted and BYOC modes.
2. Show gateway policy dimensions: provider, model, region, purpose, sensitivity, memory address, subject.
3. Show minimized SIEM export concept.
4. Explain proof boundaries and non-guarantees.
5. Offer private pilot review.

## Contributor programs

### Design partner program

Audience: serious AI users, developers, and enterprise reviewers.

Contribution:

- Complete install and receipt verification.
- Join one feedback call.
- Report setup friction and unclear claims.
- Share one safe demo artifact.

Recognition language:

- Use recognition, roadmap input, early support, and public showcase.
- Do not promise token access or economic benefits.

### Builder program

Audience: MCP client users, agent developers, receipt viewer builders, import/export contributors.

Contribution paths:

- MCP client recipes.
- Receipt viewer improvements.
- Sample Memory Passport workflows.
- Import/export adapters.
- Documentation fixes.
- Test-vector review.

Safe CTA:

> Build an integration, verify a receipt, and submit a demo for review.

### Proof review circle

Audience: security engineers, applied cryptography reviewers, protocol designers.

Contribution paths:

- Review receipt schema and verifier behavior.
- Identify proof-boundary wording issues.
- Review relay/witness/gateway assumptions.
- Submit adversarial examples and tamper cases.

Boundary:

> Public review helps improve evidence quality; it is not an audit unless an audit is separately contracted and published.

### Operator readiness list

Audience: future relay, witness, and gateway operators.

Contribution paths:

- Learn role definitions.
- Run local demos.
- Review opaque-record and no-plaintext rules.
- Review bonding/slashing drafts when legally approved.
- Join future testnet education sessions.

Required caution:

> Joining the operator list does not imply selection, compensation, token access, or service demand. Operator materials require legal and technical review before publication.

### Enterprise pilot circle

Audience: AI platform, legal, compliance, security, IT, and procurement teams.

Contribution paths:

- Review architecture and deployment fit.
- Run private proof-of-concept.
- Validate policy dimensions and audit bundle needs.
- Provide security questionnaire feedback.

Boundary:

> Enigma supports governance and audit workflows with evidence; it does not provide a blanket compliance guarantee.

## Weekly reporting cadence

Publish one sober weekly update during the first 30 days:

- Shipped: product/docs/events that are live.
- Current: demos, support themes, known setup friction.
- Next: specific upcoming events and docs.
- Proof artifact: one screenshot, receipt verification result, command snippet, or demo clip.
- Safety note: reminder about anti-phishing and no-DM-token-sales rules.
- Token note, only if needed: utility/governance/network-access status and legal-review requirement.

Do not publish vanity metrics, token speculation, or unsupported claims.