Standard Grant: Sia NFS Gateway - indexd & NFSv4

Grants Proposed
1

Project Name:

Sia NFS Gateway - indexd & NFSv4

Name of the organization or individual submitting the proposal:

Roland Rauch

Describe your project.

This project continues the development of sia-nfs, the Sia NFS Gateway. The main goals are:

  • indexd support: Replace the current renterd dependency with indexd, since indexd is where the ecosystem is heading.
  • Partial NFSv4 support: Implement enough of the NFSv4 protocol to support common Linux and macOS clients reliably. NFSv3’s stateless design required workarounds that made write operations brittle; NFSv4’s stateful model (open, read, write, close) is a much better fit for the underlying storage and will significantly improve write stability.
  • Improved modularity: As part of this work, the codebase will be restructured into separate crates. The lower-level components (I/O scheduling, caching, virtual file system) become reusable building blocks that other indexd-backed Sia applications can build on.

The project is entirely written in Rust and will use the official Sia Rust SDK, specifically the indexd client library.

Who benefits from your project?

End users who want to access their Sia-stored data through a standard, OS-native protocol without running any Sia-specific software locally. Developers who may find the modular crates (I/O scheduling, caching, virtual file system) useful as building blocks for their own indexd-backed Sia applications.

How does the project serve the Foundation’s mission of user-owned data?

It makes user-owned data on Sia accessible through NFS, a protocol supported natively by every major operating system. The modular crate structure means other projects can reuse the same VFS, I/O and caching layers without starting from scratch.

Are you a resident of any jurisdiction on the sanctioned/monitored 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:

$5,600/month, covering four months of development work. Total: USD 22,400. 100% developer fees; no additional equipment or infrastructure costs.

What is the high-level architecture overview for the grant?

The project is structured into multiple Rust crates:

sia-io

An I/O library that sits between the indexd client library and higher-level consumers like sia-vfs. It provides two core capabilities:

  • Transparent access & caching: Objects are accessed through a type that is AsyncRead + AsyncSeek. Chunking, downloading, and caching are handled transparently in the background.
  • I/O scheduling: During the previous development cycle, significant time was spent dealing with the high and variable latency inherent to distributed storage over the internet. This led to a custom I/O scheduler capable of handling a wide variety of workloads, especially when facing out-of-order I/O (described in detail here). This scheduler will be extracted from the current sia-nfs codebase and moved into sia-io, making it available to any application built on top of the library.

Both the cache and the I/O scheduler are defined as traits, allowing alternative implementations.

This crate will also subscribe to object-related events from indexd and automatically evict stale cache entries.

sia-vfs

A virtual file system library (not a service or mountable file system) built on top of sia-io. It provides file-and-directory semantics over indexd-managed objects, serving as a building block for applications that need a file system hierarchy on Sia. Key characteristics:

  • File systems can be read-only or read-write.
  • Local state is transient and fully reconstructible from the network (as long as pending changes have been committed). It is stored in a local SQLite database as an operational optimization, not as critical data that needs to be backed up or preserved.
  • In read-write mode, modifications are local-first with eventual consistency. Changes are recorded in a write-ahead log and applied in an overlay fashion; modifications are stored separately and merged during reads. The WAL is eventually flushed and changes are uploaded. Packed uploads are used where beneficial.
  • Files are AsyncRead + AsyncWrite + AsyncSeek, providing familiar open/seek/read/write/close semantics.
  • The VFS targets practical client compatibility: the operations and patterns that real-world applications actually rely on. Full POSIX compliance is explicitly out of scope.

nfsserve

The existing Rust-based NFSv3 server library (nfsserve) that sia-nfs already uses. This crate will be forked and extended with partial NFSv4 support - enough to cover common Linux and macOS client workflows, not full protocol compliance. NFSv3 compatibility will be maintained for Windows clients. Changes will be contributed upstream where possible.

sia-nfs

The standalone application, built on top of the crates above. Because the heavy lifting is handled by the underlying libraries, the application itself is relatively thin. The final artifact is a single native binary running as a single process. The only external dependency is access to an indexd instance. Local storage requirements depend on cache size & WAL configuration; VFS state itself is negligible. A Docker image will be provided for convenience.

What security best practices are you following?

In addition to the practices outlined in the grants development guide:

  1. Memory-safe language: The project is written entirely in Rust, eliminating entire classes of vulnerabilities (buffer overflows, use-after-free, data races).
  2. Type-driven correctness: Rust’s strong type system is used to provide guardrails at compile time; invalid states are made unrepresentable where possible.
  3. Secure handling of sensitive data: Confidential data (mnemonics, key material, credentials) is wrapped in a dedicated secure type that prevents accidental leakage through logging or debug output, makes every access explicit and easily traceable in the codebase, and ensures sensitive data is zeroized (overwritten with 0x00) in memory as soon as it is no longer needed. Sensitive data is never persisted.

Timeline with measurable objectives and goals.

Milestone 1 - sia-io crate
Due: 25 April 2026

  • AsyncRead + AsyncSeek access to indexd-managed objects with transparent chunking and caching
  • I/O scheduler extracted from current sia-nfs codebase
  • Automatic cache eviction via indexd event subscription
  • Trait-based cache and scheduler interfaces for alternative implementations

Milestone 2 - sia-vfs crate
Due: 25 May 2026

  • Read-only and read-write file system modes
  • SQLite-backed transient local state, fully reconstructible from the network
  • Write-ahead log with overlay-based modifications and eventual upload
  • AsyncRead + AsyncWrite + AsyncSeek file interface

Milestone 3 - Refactored sia-nfs, built on sia-vfs
Due: 25 June 2026

  • sia-nfs rebuilt on top of sia-io and sia-vfs, replacing the renterd dependency with indexd
  • Feature parity with the current NFSv3-based implementation
  • Docker image provided

Milestone 4 - Partial NFSv4 support
Due: 25 July 2026

  • NFSv4 support sufficient for common Linux and macOS client workflows
  • Stateful open/read/write/close model replacing NFSv3 workarounds for write operations
  • NFSv3 compatibility maintained for Windows clients

Potential risks that will affect the outcome of the project:

Milestones 1-3: No significant risks identified. The indexd client library crate is already available and has given a clear picture of the expected API surface. Development can proceed even with early preview builds of indexd; the only notable risk would be an extensive delay in the indexd release, which is unlikely given the Foundation’s current priorities.

Milestone 4: NFSv4 is a major protocol change over NFSv3. Full compliance is explicitly out of scope; the goal is to support enough of the protocol for common Linux and macOS clients to work reliably, and to fix the brittle write behavior caused by NFSv3’s stateless design. Even so, the amount of work required is harder to estimate than for the other milestones. NFSv3 compatibility must also be maintained for Windows clients. The main risk is that the work required to support a reasonable NFSv4 subset could exceed the budgeted time. This is also why NFSv4 is scheduled as the final milestone - if the work exceeds the budgeted time, Milestones 1-3 will already be complete and fully usable.

Will all of your project’s code be open-source?

Yes, 100%. All code will be fully open source.

Leave a link where code will be accessible for review.

Do you agree to submit monthly progress reports?

Yes.

Previously completed grants

Contact info

Email: [email protected]