--- title: "How PDE Network Works" description: "Controlled operations, Gate, Office and custom Desks for API-backed resources." date: "2026-10-22" updated: "2026-10-30" --- # How PDE Network works PDE is designed to let an external application or AI assistant use digital Resources through Operations selected by the Person who controls them. It is experimental. This page explains the intended architecture and examples, not verified availability of a particular integration. To ask about early testing, email **alex@wiredgeese.com** or read [Participate](/participate). ## Why a Personal Digital Embassy? A connector can give an AI application a way to reach a service. PDE explores a broader approach: a personal place to organize access across Resources, using Desks the Person chooses or builds and Desk-owned Policies for Consumer Access. These are design goals, not a claim that v3 is already available, universally compatible, or superior to existing connectors. ## The path from a request to a Resource ```text Consumer → Gate → Office → Desk → Resource ``` For example, an AI assistant can request an allowed action. Gate authenticates the access, Office routes the request to a Desk, and the Desk checks its policy before acting on the Resource. This describes the intended architecture, not a verified integration. These are responsibility boundaries, not necessarily separate machines: - **Person:** the human who controls Resource authority and decides what to delegate. - **Consumer:** an external application or agent that requests Operations, such as an AI assistant. - **Gate:** the external access boundary; owns Gate Accounts, OAuth and Consumer Access, authenticates requests and routes them. - **Office:** an independent Person-controlled application that organizes Desks and can connect to multiple Gates and accounts. - **Desk:** an independent application that integrates a Resource, holds its credentials, owns Consumer Access Policies, and executes permitted Operations. - **Resource:** a service, data, or capability controlled by the Person. - **Operation:** a Desk-provided action over a Resource, described by an Operation Definition. - **Consumer Access:** one separately approved OAuth authorization associated with exactly one Gate Account. - **Access Policy:** a Desk-local policy specifying permitted Operations and parameter restrictions for a Consumer Access. - **Invocation:** one request to execute an Operation. Each separately approved OAuth authorization creates a distinct Consumer Access for one Gate Account, even when the same application is approved again. It is an authorization identity; it does not establish a globally verified identity for the Consumer application. Desk-owned Access Policies determine the Operations and parameter limits allowed for that Consumer Access. Gate authenticates the access and routes requests; Office coordinates the connection; Desk verifies provenance and checks its current Policy before acting on the Resource. The Person can reduce or withdraw access; this cannot undo an effect already committed. A forwarded request does not prove an operation succeeded, and an outcome may be unknown. ## Independent Desks and discovery PDE is designed to connect an authorized Consumer to the Person’s Resources without requiring Gate to maintain an authoritative persistent catalogue of Desk types, Operations or Resource integrations. During Consumer Access consent, Gate asks connected Offices for currently available Desks so the Person can select Offices and Desks for initial enrollment. This temporary inventory does not establish a permanent Desk catalogue. A compatible Desk can be developed independently and attached through Office, subject to the established trust and approval steps. When a Consumer asks what it can do, Gate queries available Offices; they ask their attached Desks. Each Desk checks the Consumer Access and supplies the Operations allowed by its current Policy; Office aggregates the results and Gate presents them to the Consumer. An unavailable Office or Desk cannot contribute to that discovery; the response indicates unavailable or failed contributors. A previously discovered Operation is not a permanent permission: Desk checks its current policy again when the Consumer requests execution. This describes the v3 design, not verified implementation. ## Create your own Desk A Desk can give a Consumer controlled access to a Resource's API without handing its Resource credentials to the Gate. For example, a developer could create a Desk for [Porkbun's API](https://porkbun.com/api/json/v3/documentation), which provides operations for domain and DNS management. One possible design would expose a selected read operation while leaving other API actions unavailable. This is an illustration, not a claim that such a Desk or integration is currently available, or that all API actions are safe. With a Gate and Office, you can develop a Desk for a custom service or another API you are authorized to use. Define the actions that are useful, implement the API calls, configure credentials in the Desk execution environment, set access policies, and test both allowed and refused requests. AI coding tools can help write and adapt a Desk; you still need to review the generated code, dependencies, credentials, permissions, error handling and effects. The availability of a Desk development kit, examples, and support should be confirmed with Alex. APIs may impose their own authentication and browser access constraints. A Desk can run in your browser, for example on a smartphone, or on your computer, if that Desk and Resource support the environment. It must be running and reachable to execute a request; browser suspension or disconnection can make it unavailable. This is one possible runtime, not a universal requirement. See [Build your own Desk](/desks) for the v1 Telegram and Porkbun examples and how to discuss your own idea. ## Trust and practical limits The provider operating a Gate may see requests and responses passing through it. A compromised Gate may abuse the authority granted to its account relationship, within the limits enforced by Desk; software running Desk must itself be trusted with its credentials and enforcement. Separate providers, policy limits, and revocation support informed choices, but do not promise absolute security or secrecy. Sensitive actions may need direct confirmation. Review the Resource provider's permissions and the consequences of actions as well. The owner reports Telegram and Porkbun integrations working in PDE v1 for his personal use. PDE v3 protocols and software are under development; v3 Telegram and Porkbun Desks are planned examples. The v1 experience does not establish v3 availability or production readiness. See [development status](/status), [participation](/participate), and [About PDE](/about).