Skip to content

Current State of the Orbiter Core Project #4

Description

@enok1111

Current State of Orbiter

Orbiter is a mature TypeScript library (orbiter.ts) and accompanying CLI (bin.ts) designed as the backbone of the Pioneer Ecosystem within the Riff Project. It enables the creation and management of decentralized, user-controlled content platforms called Lenses—customizable sites that leverage OrbitDB, IPFS (via Helia), and the Constellation client (@constl/ipa) for distributed data storage and collaboration. Each Lens is both a site and an account (Site = Lens = Account), embodying a single entity with its own identity and control. As of today, April 9, 2025, here’s where we stand:

Core Library (orbiter.ts)

What It Does:
Orbiter facilitates the creation of Lenses where users can store, share, moderate, and collaborate on content (Releases and Collections) in a decentralized environment. It’s built to ensure user sovereignty, allowing individuals to run their own Lenses with full control over content and policies, while supporting federation with other Lenses.

Main Features:

  1. Decentralized Content Management:
    • Releases: Metadata for content (e.g., author, category, IPFS CID) managed via addRelease, editRelease, removeRelease.
    • Collections: Curated groups of releases, managed with addCollection, editCollection, removeCollection.
    • Stored on IPFS (content) and OrbitDB (metadata).
  2. Site-Specific Moderation:
    • Unique moderation database per Lens, with tables for featured releases (featureRelease), trusted sites (trustSite), and blocked content (blockRelease).
    • Dynamic Categories: Customizable content categories created with addCategory, modified via editCategory, and removed with removeCategory. Each category supports tailored metadata schemas (validated via JSON), allowing Lenses to define unique structures for organizing releases (e.g., music with "artist" and "album" fields vs. articles with "publication date").
    • Access control (e.g., makeSitePrivate, makeSitePublic, inviteUser, blockUser).
  3. Federation and Collaboration:
    • Lenses can follow trusted sites (followTrustedSites) and aggregate their content, filtered locally.
    • Real-time updates via listeners (e.g., listenForReleases).
    • Swarm-based data sharing across sites.
  4. Site Identity Management:
    • Each Lens has its own identity, managed via methods like changeName, changeProfilePhoto, addContactInfo, and removeContactInfo. These define the site’s public-facing account details, tracked in real-time with listeners (e.g., listenForNameChange, listenForProfilePhotoChange).
    • Since Site = Lens = Account, these apply to the Lens itself, not individual users within it.
  5. Permissions and Roles:
    • Admins: Full control over the Lens, granted via inviteUser with admin privileges (e.g., CLI’s orb authorise). Admins can manage content, moderation, and site settings.
    • Moderators: Limited elevated access via followIsModerator, allowing specific moderation tasks (e.g., featuring releases) without full admin rights.
    • Contributors: Basic upload permissions via followCanUpload, for users contributing releases without moderation powers.
  6. Setup and Configuration:
    • setUpSite initializes a Lens with moderation, swarm, and data tables.
    • Fully operational with Constellation, OrbitDB, and IPFS/Helia integration.

Status:
The core library is stable and functional, with a robust API covering content management, moderation, federation, and site control. It’s been tested within the Riff.CC context for curating libre media-

Command-Line Interface (bin.ts)

What It Does:
The CLI (orb) provides a user-friendly and programmatic way to configure, run, and manage an Orbiter instance, exposing the library’s functionality via commands.

Main Features:

  1. Configuration Management:
    • orb config: Sets up a new instance with customizable directories and categories.
    • orb export-config / orb import-config: Exports/imports configs for UI or static deployments.
  2. Running the Node:
    • orb run: Starts an instance with real-time network monitoring (interactive or machine-readable mode).
  3. Authorization and Federation:
    • orb authorise: Grants admin access to users/devices.
    • orb subscribe / orb unsubscribe: Manages trusted site relationships.
  4. Content Upload:
    • orb upload-releases: Bulk uploads releases from JSON files.
  5. User Experience:
    • Interactive feedback (spinners, colored output) and detailed error handling.

Status:
The CLI is fully operational, supporting both interactive use and automation. It’s a critical tool for deploying and managing Orbiter nodes.

What’s Left to Do

While Orbiter is production-ready for core functionality, there are areas we’re still refining or could expand based on future needs:

  1. UI Hooks for Frontend Integration:
    • Current State: Orbiter has a fully functional UI called Flagship, which leverages nearly all orbiter-core features.
    • Next Steps: Develop reusable UI hooks or utilities to simplify integration with new frontends wanting to use orbiter-core, enhancing flexibility for diverse deployments.
  2. Performance Optimization:
    • Current State: Works well for small-to-medium scale (dozens of Lenses, hundreds of releases). Previous OrbitDB synchronization issues have been resolved, and it’s currently stable.
    • Next Steps: Stress-test and optimize for larger networks (e.g., thousands of users), ensuring scalability and reliability under heavy load.
  3. Advanced Federation Features:
    • Current State: Basic trust and content-sharing mechanics are in place.
    • Next Steps: Add granular controls (e.g., partial trust, content sync filters) to support more complex collaboration scenarios.
  4. Documentation:
    • Current State: Code-level comments and CLI help exist, but comprehensive user/developer docs are limited.
    • Next Steps: Create detailed guides for users and developers, covering setup, CLI usage, and API integration.
  5. Customization Enhancements:
    • Current State: Orbiter is generic for the Pioneer Ecosystem.
    • Next Steps: Expand support for tailored categories, metadata schemas, or branding options to meet specific use case demands.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions