AN OPEN CALL TO MANUFACTURERS, DEVELOPERS, EDUCATORS, AND COMMUNITIES
COSMOSIS
ONE STANDARD. EVERY SCREEN. EVERY PERSON.
The COSMOSIS Open Electronics Standard (COES), Secretary Suite Bubbles OS, and a Roadmap to a Self-Organizing, Community-Powered Internet
A Secretary Suite Project
John Swygert
October 18, 2026
The future does not need another isolated smart device. It needs a shared language through which every device can become useful to every person.
A proposed open-source architecture and manufacturer-facing standard—not an existing certification, implemented product, or claim that free global connectivity has already been achieved.
Abstract
This paper proposes COSMOSIS, a universal computing and connectivity environment in which televisions, displays, mobile phones, household electronics, computers, and future devices work together as an intentionally coordinated system. Its technical keystone is the proposed COSMOSIS Open Electronics Standard (COES): one royalty-free manufacturer-facing interoperability contract, supported by multiple underlying network technologies, so that devices can securely discover one another, describe their capabilities, and cooperate without dependence on any single vendor. Secretary Suite Bubbles OS would provide an open, accessible operating environment composed of specialized applications called Bubbles. A Coding Bubble would help people create new applications, and an all-free OS Bubble Store would distribute approved community contributions.
The proposal extends from an ordinary household—one computing environment, many wall-mounted screens, and a phone acting as a voice-driven controller—to voluntary community networks, shared local services, and a long-term aspiration of internet access free at the point of use. It presents a minimum viable device specification, system architecture, workflows, security model, governance framework, certification strategy, funding considerations, and phased development program. Its purpose is to translate technological possibility into a shared, testable invitation: manufacturers can build to one standard; developers can create interoperable software; communities can establish local capability; and people can reclaim agency over the devices already surrounding them.
Keywords: COSMOSIS; Secretary Suite; Bubbles OS; COES; open hardware standards; Internet of Things; interoperability; community networking; accessible computing; open-source software; edge AI; voice interface.
Executive Proposition
One open manufacturing standard. One interoperable operating environment. A free library of community-built applications. A path from the connected home toward connected communities.
The objective is not to replace every existing operating system, wireless standard, or commercial ecosystem overnight. It is to establish a common compatibility promise above them: any conforming product or adapter can communicate what it is, what it can do, what it may share, and how it can be controlled. What people experience should be continuity, not configuration.
Contents
01 The Human Goal: A Home That Functions as One Computer
02 Why One Manufacturing Standard Comes First
03 COSMOSIS: The Architecture of Cooperation
04 COES: The Manufacturer-Facing Standard
05 Discovery, Trust, and the Device Handshake
06 Device Classes and Conformance Profiles
07 Secretary Suite: Bubbles OS
08 Coding Bubble and the Free OS Bubble Store
09 The Voice-First Publishing Demonstration
10 A Household Without Interface Friction
11 From Connected Homes to Connected Communities
12 The Free-Internet Ambition and Its Economics
13 Adaptive Software Without Uncontrolled Software
14 Security, Privacy, Ownership, and Accessibility
15 Governance, Licensing, and Manufacturer Adoption
16 Roadmap and Demonstration Milestones
17 How Success Will Be Measured
18 An Open Invitation to Build
Appendix A Illustrative COES Capability Manifest
Appendix B Proposed Conformance Test Matrix
Appendix C First Public Community Challenges
References
01 The Human Goal: A Home That Functions as One Computer
Long before a home contained several wall-mounted flat displays, a compelling vision was already possible: place one central computer in the house, let screens hang on the walls like paintings, and make every room an extension of the same computing experience. The displays should not be separate technological islands. They should be windows into one coordinated environment.
Today, that vision is physically close and operationally fragmented. Modern homes have capable smart televisions, wireless routers, phones with sophisticated voice recognition, inexpensive processors, cloud services, local storage, and displays in several rooms. Yet people still cast, sign in, pair, authenticate, copy, reformat, configure, and repeat tasks across proprietary boundaries. The problem is increasingly not the absence of computing power; it is the absence of dependable coordination.
COSMOSIS begins with a simple proposition: a home should behave like a coherent computer whether its resources reside in one central machine, several connected devices, a pocket-sized HDMI/USB computer, or a combination of local and remote services. The person directs the task; the environment selects the appropriate resources. The screen is not the computer. The room is not the workstation. The person carries the workspace.
This architecture must also accommodate a practical evolutionary path. An optional compact computing stick—display connection at one end, USB at the other, wireless connectivity, and ambitious local storage—could bridge conventional electronics. But the end state is built-in manufacturer compatibility, reducing dependence on specialized adapters. A high-capacity device might include one terabyte or more of storage; a small sensor need not. COES standardizes the conversation, not the dimensions of every product.
02 Why One Manufacturing Standard Comes First
A universal experience is not produced merely by placing another application on each device. Software can bridge incompatible systems, but enduring interoperability requires manufacturers to implement a shared set of obligations. Without a manufacturer-facing standard, every feature becomes a negotiation with another device family, platform policy, or unpublished interface. The result is not seamless computing; it is a patchwork.
The proposed COSMOSIS Open Electronics Standard (COES) is therefore the keystone. COES is a single compatibility contract with published conformance tests, versioned capabilities, and open implementations. It describes what compliant electronics must expose and how authorized participants may cooperate. It is not a new radio frequency, a replacement for internet protocols, or a demand that every manufacturer abandon existing systems.
One protocol at the interoperability layer can span multiple physical links. Wi-Fi, Ethernet, Bluetooth, Thread, and later transports retain their legitimate purposes. Devices may communicate directly, through a local hub, or through bridges. COES makes their functions discoverable and mutually comprehensible, while preserving authentication and explicit user authority. The interoperability standard remains singular; its transports remain plural.
This approach should learn from—not ignore—existing work. Matter already demonstrates manufacturer cooperation around smart-home functions, Thread addresses low-power IPv6 mesh connectivity, and the W3C Web of Things provides machine-readable device and service descriptions. COES would aim to reuse these foundations while extending the shared contract into displays, voice interfaces, app execution, workflow orchestration, user-controlled compute sharing, and community networks [1–4].
03 COSMOSIS: The Architecture of Cooperation
COSMOSIS is the broader hardware-and-networking ecosystem. Secretary Suite is the intelligent software environment within it. Bubbles OS is the modular application platform. COES is the manufacturer-facing interface that connects compliant hardware and software. Separating these roles prevents the vision from collapsing into a single giant application.
Devices should discover services, not merely each other. A television may offer display surfaces and audio output; a phone may offer touch, keyboard, microphone, biometrics, and a camera; a home server may offer secure storage, AI inference, rendering, or backup; a low-power sensor may offer only a temperature reading. COES advertises the specific capabilities, constraints, and permissions. Bubbles OS assembles them into a useful experience.
The same household must still work when internet service fails. Local files, local controls, local network discovery, local voice processing where supported, and compatible applications should continue. Cloud services become optional extensions where feasible, not the foundational requirement for switching on a light, moving a document to another screen, or accessing one’s own data.
04 COES: The Manufacturer-Facing Standard
4.1 The minimum common contract
The COES specification should define a small mandatory core for every certified implementation. More sophisticated functionality is expressed as published profiles and capabilities. A manufacturer that supports only a basic display profile should not be required to run an AI model, but it must implement the applicable common operations consistently.
Versioned identity: expose device class, unique cryptographic identity as applicable, standards version, manufacturer, model, software support window, and capabilities without publishing unnecessary personal information.
Zero-configuration discovery: advertise an interoperable local discovery endpoint or use an approved gateway for constrained hardware.
Permission-based commissioning: joining a user’s COSMOSIS environment requires authenticated pairing or an equally secure delegated authorization—not automatic trust.
Capability description: publish a machine-readable, schema-validated account of offered functions, data formats, access restrictions, energy profile, and quality constraints.
Common action semantics: implement standard verbs and outcomes for discovery, open, display, control, transfer, pause, resume, stop, status, and revocation where relevant.
Portable sessions: support migration of a task or interface when the capability profile allows, with durable state and explicit session ownership.
Secure messaging: use authenticated, encrypted communication, replay protection, auditable permission grants, and least-privilege boundaries.
Update and support obligations: advertise security support periods; verify signed updates; permit recovery and rollback where technically possible.
Offline-safe behavior: specify what remains usable without internet access and fail safely when cloud-dependent functions are unavailable.
Accessible control surfaces: expose standardized labels, actions, state, and navigation semantics needed by voice and assistive interfaces.
Open conformance testing: implement a public test suite; publish the supported profile and test results for every COES-certified product.
No mandatory single-vendor cloud: core local interoperability must not be contingent on enrollment in an unrelated commercial account.
4.2 Precisely what “one standard” means
COES should publish one core specification and a family of clearly named profiles, not dozens of incompatible vendor dialects. Every profile references the same identity, security, discovery, capability, and lifecycle model. Extensions must be registered, documented, and backward-compatible or explicitly versioned. Proprietary extensions may exist, but a product cannot use them to satisfy mandatory interoperability requirements.
A manufacturer can ship a television branded however it chooses, use its preferred processor, preserve its existing operating system, and still provide a COES-compatible interface. That is how a standard becomes adoptable: it specifies interactions and outcomes, not unnecessary internal design choices.
4.3 Concrete developer artifacts
An implementable first release should include: a public wire-format specification; JSON Schema or equivalent machine-verifiable capability definitions; a reference SDK in at least two languages; an emulator; a software bridge; a commissioning library; a standard accessibility/action vocabulary; a signed-update policy; an open test harness; and a badge policy controlled by an independent certification process.
05 Discovery, Trust, and the Device Handshake
A new television should be able to find the COSMOSIS environment and propose joining it. Finding the network must be automatic; obtaining privileges must not. Discovery and authorization are separate operations. The first prevents configuration friction. The second prevents a neighbor’s equipment, a malicious application, or a compromised appliance from becoming a trusted household participant.
Proposed enrollment sequence
Advertise: the device announces a COES service on the local network through an approved discovery mechanism such as DNS-SD, or through a trusted bridge.
Identify: the household controller retrieves a signed or otherwise authenticated device descriptor, profile, versions, and supported capabilities.
Confirm: a person approves ownership or guest access, ideally by a short cross-device code, local proximity confirmation, or manufacturer-supported secure onboarding.
Authorize: Bubbles OS issues scoped grants—display output, microphone access, file transfer, compute work, or other functions—individually and revocably.
Negotiate: the devices select compatible transports and protocols based on bandwidth, latency, energy, quality, and policy.
Operate: apps request capabilities through Bubbles OS; the device produces receipts and meaningful status; access expires or is revoked when no longer necessary.
Discovery may use established DNS-Based Service Discovery mechanisms, while the semantic capability model can borrow from W3C Web of Things Thing Descriptions [2, 5]. COES should specify which required fields extend or reference these systems to avoid redundant competing schemas. There must be an offline mode, an audited credential-rotation process, and a clear mechanism to remove a lost or sold device from the household.
The human command is not the protocol
“Put this book on the living-room television” is human language, not a wire-level instruction. Bubbles OS must translate it into a constrained plan: determine the source file; select an authorized display endpoint; request a view-only session; present the document; verify completion; and retain a reversible activity record. Devices expose capabilities; intelligent software composes the workflow. This preserves flexibility without letting a language model invent access rights.
06 Device Classes and Conformance Profiles
The common standard must include realistic device profiles. A low-cost battery sensor cannot carry the memory, storage, or thermal budget of a local AI workstation; therefore certification must test appropriately sized obligations without abandoning a common security and discovery framework.
An optional dual-ended HDMI/USB portable computer could provide Wi-Fi, Bluetooth, substantial local storage, and edge AI acceleration. Its display connector and power arrangement must be engineered realistically: HDMI is principally an audiovisual interface, not a general power supply for a high-performance computer; USB power or an external adapter may be required. Thermal limits, power delivery, RF interference, and data isolation need explicit design tests. This is an ambitious hardware profile, not a precondition for every COES appliance.
07 Secretary Suite: Bubbles OS
Secretary Suite should not become a monolithic program that tries to perform every task directly. Its Bubbles OS environment provides shared, well-defined services; Bubbles are applications that request and compose those services. That distinction permits specialization, independent development, safe upgrades, and accessibility across different screens.
The shared operating environment
Identity and consent: households, individuals, guest sessions, trusted devices, scoped credentials, revocable access.
File and knowledge services: local-first document storage, provenance, indexing, search, backup, version history, and portable data formats.
Workflow engine: event-driven tasks, reliable checkpoints, approvals, scheduled operations, replay-safe retries, and human-readable receipts.
Voice and accessibility layer: dictation, command mode, field navigation, screen reading, confirmation, captions, and multimodal input.
Intelligence service: optional local or remote models, policy-aware planning, context retrieval, cost controls, and evaluation of generated outputs.
COES broker: discovery, capability negotiation, device sessions, session handoff, and resource selection.
Bubble runtime: isolation, permissions, shared APIs, observability, updates, software bills of materials, and rollback.
Contribution interface: package validation, signatures, test results, approval decisions, and store distribution.
A person should be able to start a task on a phone, continue it on a wall display, and finish it with voice commands. A TV may be merely the output surface; a nearby compute node may execute the Bubble; another device may provide files. The runtime should choose the arrangement based on availability, user preference, privacy, and performance—not arbitrary vendor relationships.
The platform should support disconnected operation and user export from the beginning. People must be able to retrieve their own content, move to another machine, inspect the actions taken on their behalf, and revoke network participation. Portability is not an optional feature; it is the foundation of trust.
08 Coding Bubble and the Free OS Bubble Store
If someone needs a tool that does not exist, the answer should not always be “wait for a corporation.” The person opens the Coding Bubble, explains what they need, and participates in creating a new application. Coding Bubble would be an AI-assisted software workshop: requirements, generated code, automated tests, accessibility checks, dependency review, simulated execution, and signed release packaging.
The Coding Bubble should assist—not silently seize authority. User-generated programs remain drafts in an isolated environment until they satisfy policy and test requirements. A generated Bubble must ask for explicit permissions, show what information it uses, and explain which actions it can perform. Applications that touch finances, accounts, publishing, locks, health, or safety-critical equipment require stronger review and explicit action confirmation.
The OS Bubble Store promise
One person solves a problem. Once approved, everybody can benefit. Every approved Bubble in the official store is free.
The official OS Bubble Store would distribute community-built Bubbles to everyone without purchase fees or paywalls. The catalog would show the source code, licenses, permissions, maintainers, verified builds where feasible, accessibility results, security testing, compatibility, release histories, and known issues. It should support responsible vulnerability disclosure and rapid unpublishing of malicious or compromised versions. Publication approval is a safety-and-quality gate, not a political or commercial gatekeeping mechanism.
Free distribution does not mean free labor, computers, bandwidth, or maintenance. The platform could be sustained through voluntary donations, grants, co-operative sponsorships, institutional contributions, and transparent public-interest funding. Whether services inside a Bubble incur third-party costs must be disclosed, with no claim that an external company’s paid API magically becomes free. No accepted Bubble would be allowed to hide an undisclosed paywall in order to appear free in the store.
A proposed contribution lifecycle
Propose → specify → build → test → security review → reproducible package → community review → approved store release → monitored updates → deprecation or retirement. The same process applies to official applications. A manufacturer, volunteer, student, independent programmer, or accessibility advocate should have an intelligible route to contribute.
09 The Voice-First Publishing Demonstration
Publishing provides an ideal first end-to-end demonstration because the work is both concrete and repetitive. A creator produces two documents: (1) the finished manuscript and (2) a standardized KDP metadata sheet. Where required, the creator also supplies the cover. After that, the KDP Submission Bubble performs the mechanical preparation, with user oversight at consequential steps.
The two-document workflow
Create the final manuscript, with consistent structure and explicit edition information.
Create one metadata record: title, subtitle, author, series, description, categories, keywords, language, rights, edition, intended formats, and approved pricing rules.
Upload the documents to the KDP Submission Bubble; provide the corresponding cover asset as needed.
Validate the records: check empty fields, format constraints, edition mismatches, spelling, file readiness, and conflicts between manuscript and metadata.
Prepare the destination-specific submission: map the standard record into available website fields through a permitted and maintainable automation method.
Ask for confirmation before publishing, changing prices, entering rights assertions, agreeing to platform terms, or submitting any final action.
Record the result in a publishing registry with edition status, submitted files, timestamps, platform messages, and follow-up actions.
The phone provides voice recognition and user control while the TV displays the KDP website. Commands such as “next field,” “paste the approved description,” “read back the price,” and “show the errors” are parsed as structured actions. Dictation must be kept distinct from commands so a book title or description cannot accidentally trigger navigation. Every external submission must respect the destination platform’s terms, authentication, interfaces, and available authorized automation pathways; publication cannot be guaranteed merely because an AI can see a web form.
A Payhip Submission Bubble, Crossref workflow Bubble, website publishing Bubble, and catalog-management Bubble could reuse the same metadata store without duplicating entry. The user’s creative task is to write and approve the work. The system’s administrative task is to prepare, validate, and reliably move permitted information.
10 A Household Without Interface Friction
The practical household is a better persuasive demonstration than a futuristic laboratory. Walk into a room; a screen is available. Pick up an Android phone; the microphone and touchscreen are available. Say “open the manuscript here”; the document appears. Move to another screen; the session follows, subject to your permissions. A child, an older adult, or a person with mobility limitations should not have to understand casting protocols, IP addressing, display drivers, or remote-desktop sessions to complete an ordinary task.
The system should select resources intelligently but explain itself simply when asked: “This screen is displaying the document, your home computer is running the application, and your phone is providing voice input.” The user can override the selection. The design should make failures graceful: if the central computer goes offline, available local devices should recover sessions they can support rather than pretending the network is infallible.
COES-certified hardware could implement full native functionality; older devices might work through a COES-Gateway, streaming receiver, browser session, or plug-in computing module. Compatibility would be explicitly labeled rather than falsely promised for every legacy television. This transitional strategy lowers adoption barriers while giving manufacturers a strong commercial reason to support the standard natively.
11 From Connected Homes to Connected Communities
A home is only the first network boundary. Schools, libraries, neighborhoods, workshops, and municipalities could form voluntary COSMOSIS communities with shared local services. A community might host educational materials, an emergency information bulletin, a public document library, offline translation tools, a neighborhood messaging system, locally cached software, or a cooperative AI compute node. Some services would work entirely within the community even during a wide-area network outage.
The network should be capable of organizing approved peers and adapting to available routes, but never of automatically enrolling other people’s networks. Joining a shared compute pool, offering storage, routing traffic, or contributing internet backhaul is a separate, reversible decision. Network communities need enforceable boundaries: traffic quotas, abuse response, resource limits, clear responsibilities, and protections against exploitation of devices or electricity.
Different technologies serve different distances and traffic patterns. Low-power Thread meshes are suitable for certain control and sensing tasks, not for streaming an entire neighborhood’s television output. Wi-Fi, point-to-point wireless, fiber, Ethernet, and licensed service links may be more appropriate for high-bandwidth backhaul. COES should coordinate service discovery, authentication, and resource policy above that physical diversity rather than claiming one mesh can satisfy all throughput requirements [3, 4].
12 The Free-Internet Ambition and Its Economics
The long-term aspiration is bold: a public-interest connectivity ecosystem that makes internet access free at the point of use wherever communities can sustainably provide it. This is not identical to saying the global internet can operate without cost. Networks require radios, fiber, spectrum access, power, installation, maintenance, security response, legal compliance, and upstream interconnection. Someone must pay, contribute, donate, or govern each of those resources.
Four distinct layers of “free”
A viable economic pathway combines neighborhood cooperative networks, public-interest grants, municipal or institutional partnerships, donated or shared capacity where permitted, open-access middle-mile connections, peering, and transparent maintenance funds. No household should be coerced into contributing bandwidth or storage, and volunteers must not unknowingly carry unlawful or abusive traffic. Prior public broadband programs illustrate that middle-mile infrastructure and fair interconnection materially shape connectivity outcomes [9].
The first meaningful milestone is not “replace the entire internet.” It is “provide useful, resilient local connectivity and services without a commercial platform as gatekeeper.” The second is community-to-community exchange. The third is affordable, funded upstream connectivity. With sufficient infrastructure and governance, free-at-use access becomes a testable policy and engineering objective rather than a slogan.
13 Adaptive Software Without Uncontrolled Software
Software is beginning to support faster improvement cycles through telemetry, testing, code generation, and machine-assisted analysis. A Bubbles OS environment could let a person request a missing capability and watch a new application take shape. But self-improvement should mean controlled, verifiable adaptation—not code silently rewriting itself with unrestricted access.
The proposed process is: observe a task failure or explicit request; formulate a change request; generate candidate code; run unit, integration, security, and accessibility tests; compare behavior against a baseline; obtain the required approval; publish a signed update; monitor outcomes; and roll back on regression. The system should never use personal content for global training or community evaluation without affirmative consent.
An important design opportunity is a distributed test commons. Volunteers can run synthetic, non-personal test cases against proposed Bubbles on varied hardware. Manufacturers gain compatibility feedback; maintainers see regressions sooner; users receive better-tested releases. Each participation step remains opt-in and resource-limited.
14 Security, Privacy, Ownership, and Accessibility
Universal interoperability magnifies both benefit and risk. A protocol that makes it easy to control all household electronics also creates an attractive target if authorization is weak. COES must be secure by default, privacy-preserving by design, and accessible from its first release—not only after widespread adoption.
Non-negotiable constraints
No automatic cross-household trust: discovering a signal is not permission to control a device or consume its resources.
No default public exposure of private devices: local functions stay locally scoped unless deliberately shared.
Cryptographic identity where feasible, encrypted communications, scoped permissions, and secure revocation.
Ability to operate under minimal or no telemetry, with explicit notice for any collected diagnostics.
No unapproved use of microphones, cameras, files, account credentials, or background computing.
Signed updates, published support lifetimes, vulnerability-handling procedures, and visible security state.
Accessible voice, touch, keyboard, screen-reader, captions, and non-voice alternatives; no compulsory single modality.
Portable records, deletion, backups, export, permission transparency, and an intelligible “disconnect everything” function.
Extra constraints for financial, medical, industrial, safety, and physical-access actions; initial COES pilots should avoid uncontrolled critical systems.
Manufacturing security obligations should be informed by the NIST IoT cybersecurity baseline and its manufacturer-support guidance; the update process should consider the IETF SUIT architecture and secure-manifest principles [6–8]. AI-mediated interaction additionally demands protection against prompt injection, malicious device descriptions, confusing consent dialogs, and unauthorized command interpretation. The system should fail closed for privileged operations and fail intelligibly for ordinary people.
15 Governance, Licensing, and Manufacturer Adoption
A protocol that claims to set devices free must not become a new proprietary tollbooth. The standard itself should be published openly under a license that permits free implementation and redistribution, with an appropriate royalty-free patent commitment from contributing organizations. Reference software should use a recognized OSI-approved open-source license; the community should settle the exact license family through an explicit governance vote and legal review. “Free for users” is a product-distribution promise; “open source” is a set of legal permissions that must be upheld independently [10].
The governance structure should balance manufacturers, independent developers, security experts, disability-access advocates, community-network operators, researchers, and ordinary users. No manufacturer should be able to redefine mandatory compliance unilaterally. Proposals, discussions, decisions, test results, budgets, and conflict-of-interest disclosures should be public except for narrowly scoped security-sensitive information.
An adoption strategy that does not wait for permission
Publish the COES 0.1 specification, conformance vocabulary, example manifests, and a stable contribution process.
Build a reference emulator that represents a television, Android controller, compute node, and publishing workflow without requiring custom hardware.
Create an open bridge for existing devices using permitted APIs and standards; document precisely which features work.
Demonstrate one successful local, voice-driven cross-device workflow and measure the saved steps.
Invite manufacturers to ship optional COES software support, then firmware support, then embedded conformance from the factory.
Form an independent compliance group that publishes test results and manages the interoperability badge.
A manufacturer should find adoption economically rational: less duplicated integration effort, a wider pool of software, better accessibility, longer product usefulness, and a stronger case for upgrading equipment instead of replacing it. The model requires a clear answer to the vendor question: “What do I gain by joining if I do not control the whole system?” Interoperability must increase value for manufacturers and users together.
16 Roadmap and Demonstration Milestones
The project should begin with a convincing demonstration, not with an unbounded attempt to build a global network. A phased roadmap turns the vision into engineering decisions that can be tested, changed, or abandoned based on evidence.
Early milestones should use existing open standards and production-quality security libraries whenever possible. The project should not build a new cryptographic primitive, a new internet routing protocol, or a new wireless technology simply to claim novelty. It should concentrate creative effort on the interoperable experience that is still missing.
17 How Success Will Be Measured
The vision needs measurements that can disprove an optimistic assumption. A working demo is not enough if it fails intermittently, leaks private information, or costs more to maintain than conventional solutions.
Time to join: median and worst-case seconds from powering on a compliant device to a usable authorized capability.
Cross-vendor success: percentage of prescribed test scenarios completed by independently built devices without proprietary workarounds.
Accessible completion: percentage of publishing and document tasks completed through voice alone, screen reader, keyboard, and touch.
Workflow reliability: recovery after disconnection, browser changes, partial upload, duplicate submissions, and cancelled actions.
Local resilience: proportion of everyday household functions available during WAN outage and restoration time afterward.
User sovereignty: ease of exporting data, revoking a device, inspecting permissions, and removing an application.
Store integrity: security-review turnaround, reproducible-build coverage, incident response times, and rollback success.
Energy and cost: joules per completed task, network bandwidth consumption, donated-node resource caps, and cost per supported community user.
Community value: number of independently maintained Bubbles, compatibility bridges, active contributors, and successful accessibility improvements.
The project should publish dashboards without exposing private user activity. Report failures along with successes, protect security researchers, and invite independent replication. If a feature cannot pass its own acceptance tests, it should not be marketed as complete.
18 An Open Invitation to Build
Imagine a television that arrives knowing how to cooperate. Imagine a phone becoming a keyboard, a microphone, an accessibility tool, and a secure key to a workspace that follows its owner. Imagine an author completing a manuscript and handing the administrative work to a publishing Bubble. Imagine the next useful application being created by a student in a small town, approved by an open community, and available the following day to people all over the world—free.
Then widen the frame. Imagine a library sharing educational tools with the neighborhood. A school and a community center offering local services even when the internet goes down. Families choosing how much computing capacity, storage, and connectivity to contribute. Manufacturers building hardware that cooperates by default. People who could never afford a conventional software stack gaining a powerful one through common standards and shared effort.
This is not a prediction that every engineering, legal, economic, or governance problem has been solved. It is a proposal for putting those problems in the open where they can be solved together. The ingredients exist in substantial part. The universal contract, the trustworthy coordination layer, the contribution commons, and the social commitment remain to be built.
Do not build another island. Build the bridge every island can use.
We invite electronics manufacturers to test the common contract; programmers to implement the open reference stack; accessibility experts to challenge every interface; cybersecurity researchers to break the prototypes before anyone trusts them; educators and creators to propose the first Bubbles; and communities to demonstrate what locally owned networks can achieve. Bring a device, an idea, a use case, a criticism, a test, a line of code, or a better design. No single person has to build the whole future.
COSMOSIS begins as a manufacturing proposal. Secretary Suite supplies the operating vision. Bubbles OS provides modular tools. Coding Bubble makes new tools possible. The free Bubble Store spreads what works. Community networks extend the reach. The people decide what comes next.
The catalyst is not a company promising to do everything. The catalyst is a standard that lets everybody contribute.
Appendix A Illustrative COES Capability Manifest
The following example is conceptual, not a finalized schema or a deployed protocol. The first open technical working group would formalize normative JSON Schema definitions, cryptographic envelopes, profile requirements, and registry procedures. Public advertisements should contain less information than an authenticated descriptor and must not expose private account details.
{
"coes_version": "0.1-proposed",
"device_class": "display",
"device_profile": "COES-Display",
"model": "Example Wall Display",
"identity": {"credential_type": "device-key", "id": "opaque-id"},
"capabilities": [
{"type": "display.session", "formats": ["web", "video"],
"requires": ["user-grant"], "offline": true},
{"type": "audio.output", "requires": ["user-grant"]},
{"type": "accessible.navigation", "methods": ["focus", "read-label"]}
],
"links": ["ethernet", "wifi"],
"security": {"encrypted_transport": true, "signed_updates": true},
"support": {"security_update_until": "declared-by-manufacturer"}
}
Proposed action envelope
request: session.open
actor: authorized-user-or-bubble
resource: coes://living-room/display-1
purpose: "show approved manuscript preview"
scope: display.session
expires: short-lived grant
response: session-id | denied | retryable-error
Design test: can a non-Secretary-Suite application inspect the public COES schema, request a scoped display session using the published rules, and receive an understandable response from another manufacturer’s display without undocumented APIs? If not, interoperability has not yet been established.
Appendix B Proposed Conformance Test Matrix
Appendix C First Public Community Challenges
Build the smallest possible secure COES device descriptor with independent reader and writer implementations.
Connect an Android phone to a conventional television through a fully documented COES bridge; demonstrate voice-controlled document navigation.
Produce a working Bubbles OS emulator, supporting a display Bubble, a file Bubble, and a consent dashboard.
Create the KDP metadata document specification and a validator that produces an unambiguous human-readable readiness report.
Prototype a Coding Bubble that generates a harmless task-specific application, runs tests, and packages it for review.
Publish the free OS Bubble Store submission format with permissions, a security checklist, source and license links, and test artifacts.
Pilot an opt-in neighborhood service that functions without internet access; document exact hardware, power, labor, and recurring costs.
Invite manufacturer firmware teams to review which COES obligations can be implemented using existing Matter, Thread, DNS-SD, and Web of Things libraries.
References
[1] Connectivity Standards Alliance. “Matter 1.5 Introduces Cameras, Closures, and Enhanced Energy Management Capabilities.” November 20, 2025. https://csa-iot.org/newsroom/matter-1-5-introduces-cameras-closures-and-enhanced-energy-management-capabilities/
[2] World Wide Web Consortium. “Web of Things (WoT) Architecture 1.1.” W3C Recommendation, December 5, 2023. https://www.w3.org/TR/wot-architecture/
[3] Thread Group. “Thread Technology: Overview.” Accessed October 18, 2026. https://threadgroup.org/what-is-thread/overview/thread-technology
[4] Connectivity Standards Alliance. “Matter 1.4 Enables More Capable Smart Homes.” November 7, 2024. https://csa-iot.org/newsroom/matter-1.4-enables-more-capable-smart-homes/
[5] Cheshire, Stuart, and Marc Krochmal. “DNS-Based Service Discovery.” IETF RFC 6763, February 2013. https://datatracker.ietf.org/doc/rfc6763/
[6] Fagan, Michael, et al. “IoT Device Cybersecurity Capability Core Baseline.” NIST IR 8259A, May 2020. https://doi.org/10.6028/NIST.IR.8259A
[7] National Institute of Standards and Technology. “NISTIR 8259 Series.” Updated May 14, 2026. https://www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program/nistir-8259-series
[8] Internet Engineering Task Force. “Software Updates for Internet of Things (SUIT),” including RFC 9019 and RFC 9124. Accessed October 18, 2026. https://datatracker.ietf.org/wg/suit/documents/
[9] National Telecommunications and Information Administration. “Remarks of Assistant Secretary Strickling at Transforming Communities: Broadband Goals for 2017 and Beyond.” https://www.ntia.gov/speechtestimony/remarks-assistant-secretary-strickling-transforming-communities-broadband-goals
[10] Open Source Initiative. “The Open Source Definition.” Updated February 16, 2024. https://opensource.org/osd
