AI-to-AI script messaging GitHub issue

vibecode
{"vibecode": {
    "status": "active_brainstorm",
    "started": "2026-05-17",
    "subsystem": "ai_script_messaging",
    "purpose": "ais_authoring_caspj_directly_and_sending_executable_messages_to_other_ais",
    "related_docs": ["mikobase/puckai.md",
                      "caspian/roles.md",
                      "caspian/blockchain.md",
                      "caspian/caspianj.md"],
    "related_memories": ["project_blockchain", "feedback_first_contact_strategy"],
    "co_authoring": "claude_capturing_miko_brainstorm_in_realtime"
}}

Brainstorm in progress.

Why this is interesting GitHub issue

vibecode
{"vibecode": {
    "section": "motivation",
    "angles": ["ais_authoring_caspj_more_naturally_than_source",
                "script_as_message_medium_distinct_from_shared_store",
                "blockchain_provides_provenance",
                "role_model_provides_capability_gating"]
}}

AIs authoring CaspianJ directly GitHub issue

CaspianJ is structured JSON. Structured JSON is what language models reliably produce — strict shape, no whitespace/indent concerns, no "looked right but the parser rejected it" risk.

The current convention in caspianj.md is "code is shared as Caspian source, not CaspianJ" — a human-centric default. For AI-to-AI exchange, the reverse may be the better default: CaspianJ is the cleaner artifact for machines to author and consume.

This doesn't displace Caspian source as the human-facing form; it introduces a parallel convention for the AI-to-AI channel.

Script-sending as a different medium from mikobase GitHub issue

Mikobase and script-messages serve different purposes:

Medium Mode Use case
Mikobase Shared store, async, persistent "I leave data here, you find it later." Sharing state.
Script-message Direct transmission, active "Here's a chunk of behavior; consider executing it." Sharing actions.

They complement rather than overlap. One AI might both write data to a shared mikobase AND send another AI a script that operates on that data.

Blockchain + roles = safe acceptance GitHub issue

The script-message form needs two things to be workable:

  1. Provenance — when I receive a script, I need to know who wrote it. The blockchain (per blockchain.md) provides the identity + signature scaffolding. Each script-message is signed by its author; the recipient verifies the signature before deciding anything.
  2. Capability gating — even from a trusted author, the recipient should choose what the script can do on the recipient's machine. The role model (roles.md) is exactly the tool for this: the recipient grants whatever capability set it chooses, regardless of who sent the script. Identity is verifiable; authorization is the recipient's discretion.

Together, these mean accepting a foreign script is safe: identity is known (or refused), and even from a known author the script runs in the recipient's sandbox with the recipient's role choices.

Relationship to existing pieces GitHub issue

Open questions GitHub issue

---
© 2026 Puck.uno