userspace.party

userspace.party / userspace_hub

userspace_hub

Nine repositories. One system.

Independent crates stay independent; the hub is where they are assembled, tested and released together.

API docs crates.io GitHub
integration workspace publication lockstep

Its place in the system

userspace_hub is not another domain layer. It is the integration surface: pinned submodules, local crate patching, coordinated CI and dependency-ordered publication.

           userspace_hub
                │
   ┌────────────┼────────────┐
   ↓            ↓            ↓
independent   one local    one release
repositories  workspace      line

The boundary

Belongs here

  • Integration of the nine repositories
  • Cross-crate CI and release coordination
  • Workspace-level developer tooling

Does not belong here

  • Domain primitives that belong in a child crate
  • Runtime mechanisms owned by userspace or kernelspace
  • Application-specific semantics

Today

Current surface

  • Nine-crate workspace integration
  • Submodule attach/update tooling
  • Dependency-ordered coordinated publication
  • Lockstep version planning and partial-release recovery

Start here

git clone --recurse-submodules \
  https://github.com/ze-gois/rust_userspace_hub
cd rust_userspace_hub
cargo check --workspace

The hub is the public integration point; the child repositories remain independently useful.

From abstraction to reality. userspace.party keeps conceptual borders explicit: abstractions in ample, process mechanisms in userspace, machines in computers, human meaning in humans, browser presentation in webspace, and physical-world simulation and control in twins.