Introduction
Project Name: OpenWeights
Name of the organization or individual submitting the proposal:
Salih Toruner
Salih Toruner is an infrastructure engineer with a background in Linux administration, blockchain infrastructure, and developer tooling. His most recent grant-funded project, Stellar Command Insights, was a real-time CLI monitoring tool funded by the Stellar Community Fund. He has shipped full-stack developer tools from concept through release as a solo developer.
Previous work: Arbisight (real-time CLI telemetry for Stylus on Arbitrum), Stellar Command Insights (Stellar Community Fund–backed CLI monitoring), Hashirama (Kubernetes operator for Starknet Madara L3 chains).
Describe your project.
OpenWeights will be a self-hostable, Hugging Face–compatible model hub whose object bytes live on the Sia decentralized storage network instead of Hugging Face’s Amazon S3 backend. Pointing the standard hf CLI at an OpenWeights deployment with HF_ENDPOINT=http://localhost:8080 produces byte-identical round-trips against unmodified huggingface_hub and hf_xet clients. No fork of the client, no patched binary, and no cooperation from Hugging Face is required.
A reference implementation is reachable at https://siahub.app (rebranding to OpenWeights), with a walkthrough video at YouTube and source at GitHub (rebranding to openweights). The reference is offered as evidence the technical claims are tractable; the grant’s deliverables are the production system described below.
The system will ship as a Docker Compose stack of two services. openweights-cas, written in Rust with Axum, will implement the part of the Hugging Face Hub API surface that hf upload and hf download actually call, together with the Xet content-addressable storage protocol — Hugging Face’s content-addressed transport for large weight files. openweights-gateway, written in Go, will serve byte ranges over HTTP from signed URLs, backed by a whole-xorb disk LRU cache. Both services move bytes through the official Sia SDK against a self-hosted indexd daemon. An operator console (sign-in, API keys, model and asset views) closes the loop so an operator can run the round-trip from their browser.
Reference implementation:
How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
Hugging Face stores its large model and dataset files on AWS S3 in us-east-1, fronted by CloudFront. Both the legacy Git-LFS path and the current Xet path back onto a single CloudFront-fronted bucket. This concentrates open-weight AI distribution into a single jurisdiction, legal entity, and cloud region.
OpenWeights addresses this without asking users to leave the toolchain they already use. By implementing the Hub and Xet wire contracts that the unmodified hf CLI already speaks, redirecting HF_ENDPOINT becomes a one-line change. Bytes that previously flowed to S3 instead flow through indexd to shards held by independent Sia hosts.
The user-owned property is enforced at the key layer. Recovery requires only the operator’s BIP-39 recovery phrase, the standard mnemonic from which the Sia App Key is derived. The operator holds the keys, controls the contracts, and can move or migrate the data without depending on any intermediary. The project plugs into Sia exclusively through the official indexd daemon and Sia SDKs, aligning with the Foundation’s grant-thematic focus on building with SDKs and on indexd.
Are you a resident of any jurisdiction on that list? No.
Will your payment bank account be located in any jurisdiction on that list? No.
Grant Specifics
Amount of money requested and justification with a reasonable breakdown of expenses:
The total requested amount is $10,000 USD, paid out across the two-month development term against the milestone schedule below. The full amount covers development labor.
| Category | Detail | Amount (USD) |
|---|---|---|
| Development labor | One developer, full-time, two months — Rust CAS, Go gateway, operator console, Compose stack, integration tests | $10,000 |
| Total | $10,000 |
What is the high-level architecture overview for the grant? What security best practices are you following?
The system runs as a Docker Compose stack of two OpenWeights services and two supporting services.
openweights-cas, built on Rust and Axum, is the control plane and the only service that writes to Sia. It validates authentication, persists the catalog and Xet metadata in Postgres, calls sdk.upload followed by sdk.pin_object against indexd, and mints HMAC-signed URLs for the gateway to serve.
openweights-gateway, built on Go, is the data plane. It validates those signed URLs, serves byte-range responses against a whole-xorb disk LRU cache, and on cold miss issues an offset-and-length Sia download. The supporting services are a digest-pinned indexd and Postgres for the catalog and Xet metadata.
An operator console is served from the same CAS process, providing GitHub OAuth sign-in, API key management, a model list, and an asset list with pin-state badges.
The split between the CAS and the gateway is the system’s primary protection. The CAS holds the Sia App Key and is the only service with write authority. The gateway runs read-only and only serves bytes for URLs the CAS has signed.
API keys are stored as SHA-256 hashes and shown to the user only at creation. Xorb upload bodies are hash-verified before any Sia call, so bad payloads are rejected immediately. The Sia recovery phrase stays in the operator’s environment file, read once at startup to derive the App Key, and never reaches the database or logs.
What are the goals of this small grant? Please provide a general timeline for completion.
The goal is a working open-source release of OpenWeights that an operator can clone, configure, and run locally to host Hugging Face–compatible model uploads on Sia. Development is split into two monthly milestones at $5,000 each.
Milestone 1 — Stack, Sia integration, and write path (Month 1, $5,000)
The first milestone establishes the foundational stack and proves the write path end-to-end.
Deliverables:
- A
docker-compose.ymlbringing upindexdand Postgres under healthcheck-gateddepends_onchains. - A bootstrap binary that performs the
indexdconnection handshake, derives the App Key from the operator-supplied recovery phrase, and writes it back to a shared.envfile. - A readiness probe blocking CAS startup until consensus is synced, the wallet has a confirmed balance above a configured threshold, and the account holds a sufficient contract count.
- The Rust CAS implementing the part of the Hugging Face Hub API surface that
hf uploadcalls (repository creation, preupload classification, the Xet write-token mint, and commit parsing) and the Xet upload protocol (xorb upload with body hash-verification, the/shardsendpoint, and chunk dedup queries). - The Sia write path moving xorbs through
uploading → pinning → pinnedstates. - API key creation and SHA-256 storage.
Acceptance criteria: A scripted run executes hf upload of a small model file against the local CAS, the upload completes successfully, and the resulting xorbs appear as pinned on Sia.
Milestone 2 — Read path, console, and end-to-end round-trip (Month 2, $5,000)
The second milestone closes the read path, ships the operator console, and proves the byte-identical round-trip claim.
Deliverables:
- The Go gateway implementing signed-URL verification, byte-range responses with correct
Content-Rangeheaders, and a whole-xorb disk LRU cache that hash-verifies on every write. - The CAS read path including the V1 reconstruction endpoint and the
resolveredirect to signed gateway URLs. - An operator console covering GitHub OAuth sign-in, API key management with one-time plaintext display, a model list, and an asset list showing xorb pin-state.
- A README with quickstart instructions for
docker compose upbring-up and thehf upload/hf downloadcommands. - An end-to-end integration test that uploads a model via
hf upload, downloads it back viahf downloadfrom a fresh cache, and asserts byte-identical SHA-256 hashes across all files.
Acceptance criteria: An external tester clones the repo, runs docker compose up, signs in to the local console, generates an API key, runs the documented hf upload and hf download commands, and confirms round-trip bytes via sha256sum.
Who is the target user for your project?
The proximal user is an operator running OpenWeights on their own infrastructure, whether an individual researcher, a self-hosting team, or an organization with data-residency requirements. The operator interacts with the system through the console, the bootstrap binary, and the .env file, and is responsible for the recovery phrase, OAuth client secret, and Sia wallet balance.
The downstream user is an existing Hugging Face user, such as a researcher, MLOps engineer, or quantization-farm maintainer, who has installed huggingface_hub and hf_xet and runs hf upload and hf download in their workflow. For this user, OpenWeights appears as a one-line configuration change to HF_ENDPOINT, after which the CLI commands they already know continue to work and the bytes they upload land on Sia rather than S3.
What are your plans for this project following the grant?
The repository remains Apache 2.0 and openly developed.
OpenWeights at this stage is infrastructure that operators run themselves. The natural next step, beyond this grant, is to make it accessible to users who do not run their own infrastructure, through a hosted deployment with public sign-up, browser-based onboarding, a richer operator console, and the bridge proxy that lets users keep their existing huggingface.co accounts while routing bytes through Sia. Reaching that audience is the subject of a future Standard Grant proposal.
Potential risks that will affect the outcome of the project:
The most consequential risk cluster lives in xet-core protocol details and stability. The repository explicitly disclaims stability on its internal crates, and the hf_xet wheel often changes ahead of the OpenAPI spec. Specific failure modes include a hash-encoding subtlety where a custom implementation produces silent corruption, and the dual /shards and /v1/shards registration where missing one breaks production. Mitigation pins xet_core_structures at exact versions, registers both shard paths explicitly, and uses the upstream merklehash crate as the single source of truth for hash conversion.
A second risk is indexd first-run sync time. Chain sync, contract formation, and host approvals can run from minutes to multi-hour windows, and declaring the service ready prematurely produces failing CAS startups. The readiness probe gates explicitly on consensus sync, a confirmed wallet-balance threshold, and a sufficient contract count, and the documentation sets the expectation explicitly. Operators who do not want to fund a wallet can point at the hosted sia.storage indexer instead.
Development Information
Will all of your project’s code be open-source?
Yes. The entire codebase will be released under the Apache License 2.0. This includes openweights-cas, openweights-gateway, the operator console, the bootstrap utility, and all Compose, migration, and operator scripts.
Third-party runtime dependencies are all OSI-licensed and Apache-2.0–compatible. The xet_core_structures crate from Hugging Face, licensed Apache 2.0, is used for hash encoding and shard parsing. The official Sia Go and Rust SDKs from the Sia Foundation, licensed MIT, are runtime dependencies in the gateway and CAS respectively. The indexd daemon ships as a digest-pinned upstream container image.
Leave a link where code will be accessible for review.
Source code will be available at https://github.com/bytemaster333/openweights. The repository is licensed under Apache 2.0.
Do you agree to submit monthly progress reports?
Yes. I will submit a monthly progress report on forum.sia.tech covering that month’s milestone deliverables, links to merged commits and tagged releases, and any pitfalls or scope adjustments encountered.
Contact Info
Email: [email protected]
Any other preferred contact methods:
- Discord: @salihtoruner
- LinkedIn: https://www.linkedin.com/in/salih-toruner-4919b3212/