Abstract
Portable creation requires a clear distinction between the document a creator edits, the package a visitor runs and the service that connects participants. This report examines those boundaries in Guassia’s September 2026 workflows. Public release records describe local editable projects, separate website exports and optional self-hosted presence and voice. They support a bounded portability account while leaving independent-host compatibility, physical-device performance and synchronized multiplayer outside the demonstrated result.
Context: a saved world has several destinations
A creator may want to resume editing tomorrow, give a collaborator a recoverable document, or let another person play a short scene. Each intention requires a different package. A browser draft is convenient on the current machine, but dependence on that browser’s storage makes it a weak substitute for an explicit project file. A playable website has another purpose: it presents a runtime experience rather than the complete authoring interface.
Guassia’s development history records this distinction becoming more explicit between the first browser hub on September 19 and the portable-project release on September 24. Ashley Kalkowski supplied the product direction and requirements for local saving and creator-controlled hosting. AI-assisted engineering and established browser and networking technologies supported implementation. The contribution discussed here is the arrangement of creator workflows and their verification boundaries.
Creator approach: keep the editable document complete
The September 24 release describes a browser project archive containing the referenced Gaussian assets and selected original soundtrack and spatial-audio bytes. Keeping required source material together reduces dependence on the draft state of a particular tab. Save project, Save As and Open project express the intended document operations. Browser recovery remains useful, but serves a separate convenience role.
The browser archive is data for authoring. The website export is the separate package used for private playtesting. The native editor also has its own world-document workflow. Sharing a product name does not make the browser and native formats interchangeable. A creator should choose the format for the destination and retain an editable original rather than assuming that any exported file can restore every editor state.
Public observations: portability includes refusal and cancellation
The public project notes describe preservation of current work when a picker is canceled or a write fails. They also distinguish a requested browser download from confirmation that a file was written. That distinction matters on browsers with restricted file access: a download fallback can be useful without the application claiming knowledge of a completed disk operation.
The same history reports project round trips and checks around document changes during an outstanding save. These observations address a practical hazard: a late save result should not attach an older file destination to a newly opened project. Such checks establish bounded behavior for the tested workflow. They do not establish that every browser, oversized project or damaged archive will recover successfully.
Self-hosting: presence and voice have their own scope
Guassia’s public self-hosting guide describes an optional service for trusted exported worlds, small-group presence and opt-in voice. A participant must deliberately join voice and allow microphone access. Push-to-talk, mute, deafen and leaving provide familiar controls. Reading the guide alone does not connect the reader or request a microphone.
This service shares presence and voice while gameplay runs independently for each visitor. It therefore does not establish synchronized avatars or authoritative multiplayer game state. Internet access also requires operator configuration beyond a local preview, and some networks require a relay. These are material deployment conditions rather than incidental setup details. Public distribution additionally remains subject to Guassia permission and the relevant asset licenses.
Limits of the present evidence
The first public hub notes record inspection of an exported prototype while explicitly withholding a claim of execution on a separate host. Later project and self-hosting descriptions expand the workflow, but a release note is still first-party evidence of scoped development. It is not an independent interoperability study, a measured ten-person internet trial or proof that hosting is free of hardware, network and relay costs.
Source preservation and local saving also do not imply cloud synchronization, collaborative editing or unlimited project size. A portable archive can contain material that the creator has no right to redistribute. Technical completeness and distribution permission must therefore be assessed separately. This report describes private creation and testing capabilities without treating them as unrestricted commercial publishing rights.
Next validation: test the complete journey on independent hosts
A useful follow-up would prepare rights-cleared small, medium and near-limit projects with documented asset and audio expectations. Independent testers would save them, clear draft storage, reopen them and compare the recovered document. Cancellation, interrupted writes and deliberately damaged archives should be included, with the existing project preserved as the expected failure behavior.
A second study should serve the same playable export from two independent environments and exercise voice across home-network conditions and physical devices. Record connection success, latency, reconnect behavior and participant controls separately from gameplay. Publish exact supported versions, failures and host requirements. That evidence would improve portability guidance without turning a local workflow into an unsupported general multiplayer claim.
