Multiplayer by Default
Section titled “Multiplayer by Default”In Hoody, anything running in a container is multiplayer by default. When two people open the same terminal URL, both type into the same shell session, and the same holds for displays, browsers, and file editing. This is simultaneous control of the same running programs rather than screen sharing.
Screen sharing imposes turn-taking: one person drives while everyone else watches. Video calls start with confirming that the screen is visible, pair programming becomes watching someone else type, and customer support becomes describing a problem instead of fixing it. Shared sessions remove that layer.
One URL per service
Section titled “One URL per service”Every service a container exposes is a URL, and every URL accepts more than one participant. When you spawn a container, anyone who has a service URL can join: several people can type in the same terminals, control the same browser, watch the same display, and edit the same files in real time. The model is Google Docs, applied to an entire computer.
https://PROJECT_ID-CONTAINER_ID-terminal-1.node-us.containers.hoody.comhttps://PROJECT_ID-CONTAINER_ID-display-1.node-us.containers.hoody.comhttps://PROJECT_ID-CONTAINER_ID-files-1.node-us.containers.hoody.comEach service has one URL, and sharing that URL is the whole joining procedure. There is no invitation or setup step on either end.
A bug fix over a shared terminal
Section titled “A bug fix over a shared terminal”A junior developer hits a bug and asks for help. Over screen sharing, that means scheduling a call, confirming the screen is visible, sharing the right terminal (then the other terminal), and the senior developer dictating commands while the junior developer types them, mistakes included. A small fix can absorb twenty minutes this way.
With a shared terminal, the junior developer sends the terminal URL, the senior developer opens it, and both see the same session and type into it at once.
Shared state, not a shared screen
Section titled “Shared state, not a shared screen”Screen sharing transmits a picture of one person’s session. A shared container puts everyone inside the same session, with the same processes, the same logins, and the same state.
One environment for twenty brand accounts
Section titled “One environment for twenty brand accounts”Five marketers manage twenty brand accounts. Done traditionally, each person logs into accounts from their own machine, credentials live in a shared password manager, and the coordination is manual: whose turn it is to post, whether someone forgot to log out of the wrong Instagram account, which account the current session belongs to.
On Hoody, one container runs twenty browser instances, one per account, and all five marketers open the container’s display URL. Everyone sees all twenty browsers with their logged-in sessions. One person drafts a tweet in browser tab 1 while another reviews Instagram stories in tab 5 and a third posts to LinkedIn in tab 12, all at the same time. The sessions belong to the container rather than to any one person, so nobody shares credentials and nobody has to ask whose session it is.
Any program, on any device
Section titled “Any program, on any device”None of this requires programs designed for collaboration. VS Code needs no collaboration feature of its own; run in a container and reached through its URL, it is shared like anything else. The same applies to custom internal tools, legacy desktop applications, terminal sessions with several people typing, shared file editing, and the twenty logged-in browsers above. The collaboration comes from the environment being web-native, not from the applications.
Because displays are URLs, the device also stops mattering. A phone opens the URL and gets full VS Code, the desktop application rather than a mobile version. A tablet gets LibreOffice, a TV gets an entire development environment, and smart glasses get terminals and dashboards. Any browser anywhere renders full desktop applications. And because every URL is multiplayer, a team can join from phones, tablets, and laptops at once, all controlling the same VS Code, the same browser, the same environment.
AI agents in the same environment
Section titled “AI agents in the same environment”Sessions are shared with software as well as people. An AI agent joins a terminal by opening the same URL you did, and then both of you type into the same shell. While you read logs in terminal 1, an agent reads stack traces in terminal 2, both acting on the same container and each seeing the other’s actions as they happen.
This is different from an assistant suggesting code for you to copy and paste: the agent works in the environment directly, as a peer. It also scales past a single agent. One agent writes tests in terminal 1 while a second refactors code in terminal 2 and a third updates docs in terminal 3. All of them work in the same environment and can see each other’s changes, and you move between terminals to coordinate.
Open by default, permissions when needed
Section titled “Open by default, permissions when needed”Containers start collaborative; you add restrictions when you need them.
Default state
Section titled “Default state”https://PROJECT_ID-CONTAINER_ID-display-1.node-us.containers.hoody.comAnyone who has this URL can join, and everyone who joins can type. That is the right default for development, where sharing a session should be as fast as sending a message. The two 24-character hex IDs in the hostname are the credential: they are long enough that nobody discovers a session by guessing. That covers blind discovery only. A URL can still leak through a screenshot, a chat log, or a referrer header, so treat it as a secret and set proxy permissions before sharing anything sensitive.
Production state
Section titled “Production state”When an environment moves toward production, add permissions:
- IP restrictions: allow or deny by client IP or CIDR range
- Password: HTTP Basic Auth with a username and password
- Bearer tokens: API-style token validation
- JWT: token validation against a secret, with claims
- Per-program access: restrict which programs each group can reach, such as a guests group that can open displays but not terminals
The default stays collaborative; restricting access is a choice you make when an environment calls for it.
Collaboration without turn-taking
Section titled “Collaboration without turn-taking”Shared sessions remove the coordination that screen sharing requires. You send a URL instead of starting a share and confirming that everyone can see it. Input is simultaneous, so nobody waits for someone else to finish typing. And because everyone is in the same session rather than watching a copy of it, the question of whether the other person sees the right window never comes up. The collaboration is architectural, a property of every session being served as a URL rather than a feature added to individual programs.
What shared sessions enable
Section titled “What shared sessions enable”Traditional computing gives each person a private machine, and every act of collaboration means building a channel between machines. When the environment itself is shared, that step disappears. None of the following is a roadmap item; it is how every container behaves by default:
- Remote work where the team operates in one environment rather than presenting to one another
- Pair programming that does not require being in the same room
- Teaching where instructor and students operate the same environment
- Customer support that acts on the problem directly in seconds, instead of describing steps
- AI and human teams working in the same environment as peers
- Desktop applications on any device that runs a browser
- Shared accounts and sessions for marketing and operations teams
Next: Security Model →