Prox OS Internal Docs
ProductStrategy

Prox OS Platform Vision

GitHub made the Repo a global unit of software collaboration. It solved a

Status Model

LabelMeaning
CurrentExists in the repository or shell today.
PlannedA product direction for near roadmap work.
ExplorationA candidate model that needs validation before implementation.
Long-term VisionStrategic north star, not a promise that the platform already does it.

The Problem After GitHub And Hugging Face

GitHub made the Repo a global unit of software collaboration. It solved a large part of publishing, starring, forking, watching, reviewing, and operating code. But after the repository explosion, builders still face a daily problem:

  • There are too many projects to know what to inspect next.
  • Awesome lists and READMEs remain semi-structured.
  • Star, fork, and watch do not fully answer how to move useful projects into a personal workflow.
  • A repo is excellent for code collaboration, but not always enough to express a full information workspace.
  • AI-native work needs more than code. It needs controlled context that agents and apps can understand and call.

Hugging Face made Model, Dataset, and Space visible platform objects for the AI ecosystem. It solved a large part of publishing, running, cloning, and discovering models, datasets, and AI demos. But many users still need a broader workspace:

  • Models, datasets, and Spaces are strong AI ecosystem objects, but daily work is not always organized around models.
  • A single demo Space is not the same as a personal OS Home or team operating workspace.
  • Users still need to combine GitHub, RSS, cloud services, project docs, profile pages, AI context, data sources, and workflows.

Prox OS explores the layer above those tools: a way to turn cloud tools, information streams, projects, sources, and AI context into an operating workspace.

Core Analogy

GitHub: where code lives.
Hugging Face: where models, datasets, and demos live.
Prox OS: where personal AI-native workspaces, OS apps, data sources, and AI contexts live.

GitHub lets code become a collaborative, discoverable, forkable platform object. Hugging Face lets models, datasets, and AI demos become publishable, runnable, cloneable platform objects. Prox OS explores whether OS Space, OS App, Source, AI Context, and Workflow can become platform objects for developers, creators, teams, and communities.

Strategic summary:

GitHub lets people publish code. Hugging Face lets people publish models, datasets, and demos. Prox OS explores letting people publish their own OS Apps, OS Spaces, source combinations, and AI Context. The App Store is only the curated storefront; the real commercial core is Space + Studio + Connector + Permission + MCP Gateway.

What Prox OS Is Not

Prox OS should not be framed as:

  • A visual Web OS shell only.
  • An iframe bookmark launcher.
  • A direct replacement for GitHub, Hugging Face, Notion, Google Drive, Nextcloud, Eagle, or Apple Photos from day one.
  • A simple App Store.
  • A heavyweight cloud platform that immediately hosts every user's code, files, models, inference, database, and static assets.
  • A product that already provides enterprise privacy certification, automatic global payouts, real autonomous agent execution, or universal hosted data residency.

The correct ambition is to stand on top of ecosystems such as GitHub, Hugging Face, Cloudflare, Vercel, RSS, AI agents, and MCP tools, not to replace all of them at once.

What Prox OS Is

Long-term Vision: Prox OS is a cloud-first, AI-native OS Space platform for developers, creators, teams, and communities.

Strategic sentence:

Prox OS is a personal AI desktop where agents become visible, auditable, data-sovereign apps.

Technical positioning:

Prox OS is not a nostalgic web desktop. It is a data-sovereign runtime for summoning, wiring, auditing, and moving personal agents and micro-apps.

Its long-term goal is to:

  • Bring GitHub repos, Hugging Face Spaces, RSS, Cloudflare, Vercel, Neon, Notion/Airtable-style sources, public data sources, personal knowledge flows, AI Context, and later local data bridges into OS Spaces.
  • Let users create OS Apps and OS Spaces with low setup cost.
  • Let each Space carry README content, Apps, Sources, Dashboards, AI Context, MCP capabilities, public/private visibility, and clone/remix metadata.
  • Let non-traditional developers use AI-assisted publishing to create OS Apps without starting from a blank codebase.
  • Let developers register apps, declare permissions, connect sources, publish templates, and expose MCP-ready capabilities through governed platform layers.
  • Let users bring Airtable, Baserow, Notion, GitHub, and future local data, build a Prox App interface over that data, and own the runtime boundary.

Strategic north star:

Prox OS is not just another generated app tool. It is an AI-native OS Space
platform where apps, sources, permissions, deployments, manifests, and contexts
can be registered, installed, composed, and eventually operated by humans and
AI agents.

Platform Loops

The early platform loop is a foundation target, not a completed backend:

GitHub SSO
-> Profile
-> Space
-> App registration
-> App source/deployment metadata
-> App installation
-> Open in OS shell
-> Permission declaration

The future AI-operated loop is a long-term direction:

Ask AI to build an app
-> AI creates or updates Space
-> AI generates code and manifest
-> BYO GitHub / BYO deployment
-> Prox records app/deployment metadata
-> App is installed into a Space
-> App declares permissions
-> Sources and Views provide data/context
-> MCP Gateway and audit arrive later

v0.2 is foundation work. It should prepare these platform objects without pretending that AI Builder, MCP Gateway, billing, or full permission enforcement already exists.

v0.1 should remain public-preview plus waitlist and invite-only beta. It validates the narrative, early builder fit, privacy/data/export/agent permission mental model, and visible OS shell rather than opening broad global paid signup.

Post-generator OS Layer

Prox OS can position itself as a post-generator OS layer. The opportunity is not to out-generate every AI app builder or out-host every deployment platform. The early wedge is to register, install, compose, permission, and run generated apps, BYO repos, BYO deployments, Sources, and AI Context inside OS Spaces.

This is not implemented yet as a full platform. The current shell and /app-os and /app-hub prototypes make the direction visible; v0.2.x starts the control plane planning.

PlatformStrong atProx OS should learnProx OS differentiation
GitHubCode identity, repo graph, collaborationOwner/repo mental modelOS Space + runtime + installation layer
Hugging FaceTyped resource hubs, datasets, Spaces, discoveryType-first resource URLsPersonal/community OS Spaces and app runtime
v0AI app generation, Vercel deploymentNatural language creation flowPost-generator registry, permissions, OS shell
LovablePrompt-to-app, publish/live app flowCreator-friendly app lifecycleBYO app control plane and Space composition

For a broader module-by-module comparison, see Competitive Landscape.

Platform Object Model

Exploration: the following is a concept model, not a current database schema or API contract.

Primary objects:

User
Profile
Space
App
Source
Collection
Context
Workflow

Platform objects:

Manifest
Connector
Capability
Permission
MCP Endpoint
Template

Space

A Space is not a single app. It is an accessible, shareable, cloneable, and remixable workspace.

A future Space may contain:

  • README
  • Apps
  • Sources
  • Dashboards
  • Datasets
  • GitHub repos
  • RSS feeds
  • AI Context
  • MCP endpoint
  • Public/private/unlisted visibility
  • Clone/remix metadata
  • Stars and watchers

Example public path ideas, not final routes:

prox-os.com/@esmadrider/prox-os-roadmap
prox-os.com/@alice/ai-tools-radar
prox-os.com/@bob/cloudflare-dashboard
prox-os.com/@team/frontend-os

App

An App is an application unit that runs in Prox OS. The current app registry and app contract are early foundations for this direction and should evolve gradually instead of being redesigned in one pass.

A long-term app manifest may include:

  • App id
  • Name
  • Icon
  • Publisher
  • Runtime type: iframe, route, local module, external, future isolated app
  • Entry URL
  • Permissions
  • Sources
  • Capabilities
  • MCP declaration
  • Version
  • Status

Source

A Source is an external or internal data origin. Future sources may include:

  • GitHub repo
  • RSS feed
  • Cloudflare project
  • Vercel project
  • Neon database
  • Notion database
  • Airtable base
  • Hugging Face model, dataset, or Space
  • Google Drive folder
  • Obsidian vault
  • Eagle library
  • Local folder
  • Manual JSON or Markdown source

Context

Context is a controlled collection of information that an AI agent or app can use. Future context may contain:

  • Sources
  • Summaries
  • Allowed apps
  • Allowed models
  • Permissions
  • User-approved rules
  • Export format
  • MCP resources, prompts, and tools

Workflow

Workflow turns information into action. Future examples:

  • RSS update -> Space update
  • GitHub release -> notification
  • Cloud alert -> task
  • Dataset update -> AI summary
  • App publish -> profile activity
  • Space clone -> new project

Future OS App Portfolio

Planned and Exploration: these are platform capability surfaces, not promises that every app exists today.

The current shell includes static /app-os and /app-hub UI prototypes for these surfaces. See Platform Core App Prototypes for the route map and prototype boundaries.

OS AppRoleStatus
Prox StudioAI OS App and Space Builder: create apps, spaces, dashboards, sources, MCP tools, templates, and drafts.Exploration
App StoreCurated discovery layer for featured apps, spaces, templates, collections, installed apps, and concepts.Current/Planned
Space GalleryBrowse featured spaces, trending spaces, AI tool radars, developer dashboards, and clone/remix examples.Planned
Profile AppPublic identity, pinned Spaces, apps, dashboards, repos, AI contexts, follow graph, and activity.Current mock / Planned
Developer ConsoleApp registration, manifest validation, URLs, webhooks, MCP registration, analytics, submissions.Planned
Connectors HubNotion, Airtable, Coda, Google Sheets, GitHub, Stripe, ClickUp, monday.com, Smartsheet, Baserow, NocoDB, Softr, Glide, AppSheet, Power Apps, Retool, Appsmith, Budibase, RSS, Cloudflare, Vercel, Neon, Supabase, Hugging Face, Figma, Linear, Slack, APIs.Planned
Launcher HubNotion Sites, Obsidian Publish, Cloudflare Pages, Vercel, Netlify, GitHub Pages, v0, Lovable, Bolt, Claude Artifacts, personal landing pages, docs sites, demo sites.Planned
Design System HubProx Native, Bit.dev, Storybook, shadcn, Material Design, Fluent UI, Ant Design, Liquid Glass, style packs, AI-readable recipes.Planned
Permission CenterSource access, AI Context access, public/private visibility, tokens, read/write scopes, audit.Planned
MCP GatewayUnified authorization, scopes, rate limits, audit logs, and user approval for MCP resources/tools.Exploration
Business and Growth OS AppsLanding, templates, analytics, upgrade, onboarding, feedback, referrals, CRM, proposals, pilots.Exploration

Prox Studio is not just an app generator. It should combine ideas from GitHub New Repo, Hugging Face New Space, Vercel New Project, and AI app generation into an OS App and Space creation surface.

The App Store is not the whole platform. It is a curated discovery layer. The platform core is Space + Studio + Connector + Permission + MCP Gateway.

BYO GitHub, BYO Deploy, Prox Metadata Control Plane

Planned: Prox OS should not start by hosting every user's code, files, databases, AI inference, and static resources.

Early strategy:

BYO GitHub + BYO Deploy + Prox Metadata Control Plane

Meaning:

  • User code lives in GitHub.
  • Static frontends deploy to Cloudflare Pages or Vercel.
  • Data can start from GitHub READMEs, JSON, RSS, and third-party APIs.
  • Prox OS stores metadata, manifests, Space index, profile, stars, watches, and install relations.
  • Prox OS registers iframe/external/registered app URLs into the OS.
  • Prox OS starts as control plane and discovery layer before becoming a heavyweight hosting platform.

Candidate creation flow:

1. User clicks Create App or Create Space in Prox Studio.
2. User selects a template.
3. AI drafts manifest, README, layout, and data config.
4. User creates or connects a GitHub repo.
5. User connects Cloudflare Pages or Vercel deploy.
6. User returns the deployed URL.
7. Prox OS registers the app or Space metadata.
8. User publishes to Profile, Space Gallery, or App Store draft.

Social Objects

Long-term Vision: GitHub's star, watch, fork, and profile mechanics made repos social objects. Prox OS should explore making App, Space, Source, and Context social objects.

Future social and distribution primitives:

  • User profile
  • Public OS Home
  • Follow user
  • Star app
  • Star Space
  • Watch Space
  • Clone Space
  • Remix app or Space
  • Activity feed
  • Public gallery
  • Featured Spaces
  • Community templates
  • Made with Prox OS badge

MCP Strategy

Exploration: App, Space, Source, and Context can be MCP-ready, but individual apps should not open unmanaged MCP servers by default.

Principle:

OS App declares MCP capabilities.
Prox MCP Gateway enforces auth, scopes, rate limits, audit logs, and user approval.

Future mapping:

  • Space exposes MCP resources.
  • App exposes MCP tools.
  • Context exposes MCP prompts and resources.
  • Source becomes MCP-readable under permission.
  • Permission Center and MCP Gateway govern access centrally.

Competitive Landscape

Prox OS has a multi-layer competitive context. It should not define itself as a simple replacement for any one product.

LayerReference productsProx OS posture
Ecosystem object platformsGitHub, Hugging FaceExplore OS Space, OS App, Source, AI Context, and Workflow as new platform objects above existing ecosystems.
AI app buildersReplit, v0, Bolt, StackBlitz, Lovable, Cursor, CodexDo not compete only on generating one app. Organize what happens after apps are generated: Space, Profile, Sources.
Work entry and app groupingRaycast, Arc, WebCatalog, Rambox, StationDo not become an advanced bookmark page. Iframe/external app is only the first integration layer.
Knowledge and data spacesNotion, Airtable, Coda, Anytype, ObsidianTreat these tools as Sources where useful; do not start by out-editing or out-database-ing them.
Automation and agent layern8n, Zapier, Make, Pipedream, MCP platformsEmbed Workflow and MCP inside Space context with Permission Center and MCP Gateway governance.

Summary:

Prox OS is not trying to out-code GitHub, out-model Hugging Face, out-generate Replit/v0/Bolt, out-note Notion, or out-automate n8n.

Prox OS explores the OS layer that lets people combine these tools into personal, team, and community AI-native Spaces.

On this page