Unified Protocol Browser and Workstation Runtime
Browse resources. Run apps. Work with the network.
ENTENCY UP brings browsing, application workspaces, and protocol runtime services into one desktop environment. Browser and Workstation share a shell, session lifecycle, and access to the local ENTENCY GNS runtime.
Desktop browsing, managed app installation, and diagnostics exist in development. Native protocol execution and production security remain under development; no public installer is offered here.
UP is a protocol workstation with two connected spaces. The Browser opens web and protocol-addressed resources. The Workstation hosts installed app views and tools for sessions, permissions, and network inspection. The runtime coordinates how a request is routed, which adapter handles it, and what access it may use.
One environment coordinates different protocol handlers and a shared session lifecycle. It does not mean every protocol has the same execution backend: HTTP/HTTPS browsing, gateway-assisted access, and GNS-native handler foundations have different capabilities and readiness.
IMPLEMENTED IN DEVELOPMENT
The desktop browser has HTTP/HTTPS navigation and IPFS/IPNS adapters that resolve through HTTP gateways. Its Store uses a local development catalog; launching an installed app opens its view in Workstation. A public GNS app marketplace is future work.
IMPLEMENTED IN DEVELOPMENT
Installed applications register views in the workstation launcher and tabs. A central session state machine owns routing, activation, backgrounding, and teardown. App installation, permission review, and diagnostics give the workspace responsibilities beyond page navigation.
IMPLEMENTED IN DEVELOPMENT
The desktop host starts and packages the GNS daemon alongside UP. Protocol and service adapters connect the workspace to it. Bundling the runtime simplifies local setup; joining other nodes still depends on bootstrap configuration, reachable endpoints, and the network environment.
UP separates the interface, app host, Electron native host, and GNS runtime. Installed app views use a sandboxed iframe and a host API; untrusted web content uses a separate isolated renderer. A capability request crosses a policy boundary before it reaches a service or native operation.
An app package declares its identity, version, entry bundle, views, and requested capabilities in up.app.json. Installation validates and imports runtime files into managed profile storage, registers the views, and restores the bundle on later launches. It does not depend on the original source folder after installation.
Declaring a capability is not a grant. Consent and active session grants are tracked separately, with review, revocation, expiry, and manifest-change checks. Missing consent allows startup but blocks the affected host API calls. These controls are implemented foundations, not a claim of complete production app security.
The host API exposes tabs, theme, local toast notifications, service status, file read/write, compute requests, communication, and streaming/media entry points. File services include local adapters. Communication contracts, delivery evidence, and stream handling remain foundations; an API entry point does not guarantee distributed storage, reliable messaging, or production media delivery.
Routing foundations distinguish storage, stream, identity, and compute requests. UP-native gns-storage:// and gns-stream:// handlers have limited scope. Identity routes do not authenticate users. gns://compute admission evaluates readiness without executing the job; canonical content/stream routes still include deferred paths. Unsupported routes are blocked.
Untrusted browser renderers have context isolation, sandboxing, no Node integration, and no privileged preload bridge. Native filesystem, process, capture, and ID operations pass through explicit desktop capability guards. ENTENCY ID supplies the identity and authority model. Current runtime foundations validate sensitive-operation intents and deny untrusted signing requests. Local signature evidence uses deterministic test signing: it is not production key custody, login, or permission authority, and a proof alone cannot execute an operation or grant a capability. The wider native runtime and GNS Web Runtime sandbox are still foundation-level.
ENTENCY ID is the identity subsystem built into ENTENCY UP. It handles your identity, profile, recovery, signing, and ENT Wallet integration — all inside the UP environment. It is not a separate product. It contains the ENT Wallet for ENT-only operations. Canonical network state, capability grants, and reputation remain in GNS.
Untrusted browser renderers have context isolation, sandboxing, no Node integration, and no privileged preload bridge. Native filesystem, process, capture, and ID operations pass through explicit desktop capability guards. ENTENCY ID supplies the identity and authority model. Current runtime foundations validate sensitive-operation intents and deny untrusted signing requests. Local signature evidence uses deterministic test signing: it is not production key custody, login, or permission authority, and a proof alone cannot execute an operation or grant a capability. The wider native runtime and GNS Web Runtime sandbox are still foundation-level.
Node Map presents node/link topology from network view models. System diagnostics expose runtime, peer, bootstrap, reachability, and capability status. The GNS explorer projects blocks, events, reputation, delegated capabilities, and compute jobs. These are derived views of runtime or canonical state; they do not create network authority.
Implemented means supported by repository code and evidence. Foundation means working building blocks with explicit limits. Neither label means a production release or an open public network. Content reviewed 10 September 2026.
Desktop browser/workstation spaces, managed app installation and restore, app-host APIs, permission review, local renderer/native guards, and network diagnostics are present in the development repository.
Multi-protocol routing, GNS service integration, consent hardening, sandbox enforcement, and wallet-signature authority have implemented foundations with explicit limits. Full native protocol IO, production custody, and end-to-end distributed app/service execution are not established.
Future work includes production runtime/security closure, a GNS-backed app catalog, and broader public testing. ENTENCY AXI remains planned. Release availability will be stated separately from implementation progress.
Windows is the primary desktop packaging path, with Linux packaging scripts also present. Separate Android GNS node-console work includes a foreground service and bundled runtime packaging. That mobile work is not evidence of full UP browser/workstation parity or a verified public Android release.
Start with the Litepaper for the ecosystem model and current direction. The Technical Whitepaper destination explains the planned technical coverage and its publication status.
Read the available introduction to GNS, UP, identity, and the relationship between the components.
READ THE LITEPAPER →Detailed protocols, security and implementation documentation are not yet published. Follow the existing documentation page for its status.
VIEW DOCUMENTATION STATUS →No public installer is linked here yet. Follow Early Access for development updates and public-test announcements. Verified releases and their installation information can be published here when they become available.