Skip to content

feat(cli): publish Projects, Branches and Forks to a Hub #1749

Closed
#1759
#1756
Closed
feat(cli): publish Projects, Branches and Forks to a Hub#1749
#1759
#1756
Labels
coreCore source code changesenhancementNew feature or request
Milestone
M13: Coordinated GraphForge v0.6.0 Release

Description

@DecisionNerd
DecisionNerd
opened on Oct 2, 2026

Problem

gf clone can read from a Hub, but nothing can write to one. Today only an operator with a control-plane token can publish a Project. Forks, Branches and owner-published Projects therefore can't appear on graphforge.sh, and the Hub's lineage connections stay empty.

Objective

Define and implement a Rust-owned, provider-neutral publish contract and gf publish command that uploads an exact Project Version or Branch head (including a Fork) to a conforming Hub.

Requirements

  • The client derives the package and descriptors with the existing exporter and verifier. The Hub never re-derives semantics.
  • Hand off authentication through a short-lived, scoped publish credential obtained by a browser/device flow. No long-lived secrets in project files, config participants or logs.
  • Upload large objects directly to the data-plane location the Hub provides (resumable, digest- and length-verified, bounded), never through the control plane.
  • Make publication idempotent: the operation identity and exact request commitment are retried safely; changed content under the same identity fails (GF_IDEMPOTENCY_CONFLICT).
  • Advance a ref only on an expected-revision precondition (no blind last-writer-wins). Treat Fork publication as a new repository identity that carries its origin citation.
  • Specify stable errors for auth, quota/entitlement denial, conflict, unsupported version and integrity failure.
  • Add conformance fixtures and a reference in-memory Hub for tests. Python, Node and the CLI expose the same Rust behavior.

Acceptance

  • Publishing the same Version twice yields one Hub version and the original receipt.
  • An interrupted upload resumes, and a corrupt object is refused before the ref moves.
  • A published Fork clones back with its origin citation intact.

Non-goals

  • Proposal submission into another owner's Project (needs Hub moderation design first).
  • Private repositories, billing enforcement and Hub UI.

Related

#906, #1357, #1748; CurateLabs/graphforge-nextjs M3.

Activity

  1. DecisionNerd
    added
    enhancementNew feature or request
    coreCore source code changes
    on Oct 2, 2026
  2. DecisionNerd
    added 4 commits that reference this issue on Oct 2, 2026

    feat(hub): add hub publish wire contract stub and memory registry (#1749

    95bac20

    feat(hub): resumable upload and idempotent publish session (#1749)

    f8a6d81

    feat(hub): publish HTTP mapping, reference Hub, and conformance corpus (

    3739ba9

    docs(hub): publish HTTP mapping, credentials, and crate registration (#…

    6b87c3f
  3. DecisionNerd
    closed this as completedin #1756on Oct 2, 2026

  4. DecisionNerd commented on Oct 2, 2026

    @DecisionNerd
    DecisionNerd
    on Oct 2, 2026
    ContributorAuthor

    Reopening: a gap in the merged gf publish (#1756) breaks the Hub page of every published research repository.

    The Project package was exported with the DataComponents profile. That profile drops the workspace/research_metadata and workspace/configuration participants, which count as settings components. The Project summary is derived from that package (ADR 0051), so a published research repository's summary has no title, licence or ontology mode. A probe that published a real research Project with metadata through gf publish to the reference Hub served title=None, license=None and ontology_mode=none.

    Fix: export the Project package as every committed participant except the research capability. Exporting Complete is refused for a Project with research Branches only because its research registry carries operational heads. With that selection the probe returns the metadata, and the existing publish, clone and fixture suites still pass. The decision is recorded as an ADR 0053 amendment. A PR with a regression test follows.

  5. DecisionNerd
    reopened this on Oct 2, 2026
  6. DecisionNerd
    closed this as completedin #1759on Oct 3, 2026
  7. DecisionNerd
    added this to the M13: Coordinated GraphForge v0.6.0 Release milestone on Oct 3, 2026
  8. IgorOffline
    added 2 commits that reference this issue on Oct 10, 2026

    feat(hub): publish Projects, Branches and Forks to a Hub with gf publ…

    798beca

    fix(cli): publish the Project package with its metadata and configura…

    933ab71
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    coreCore source code changesenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions