Project overview
Project name: Cardinal
Applicant: Creatives Onchain
Grant type: Small Grant
Amount requested: $8,800
Timeline: 8 weeks
Category: Developer tooling / infrastructure / user-owned data
Cardinal is an open-source, self-hosted CardDAV gateway that stores contact data through Sia’s current indexd and SDK stack while allowing users to continue using standard contacts clients.
The project is not a standalone contacts app, calendar app, hosted SaaS, or groupware suite. It is a narrow infrastructure layer for syncing contact records through existing CardDAV-compatible clients.
The first version will focus on a single-user, self-hosted deployment. The goal is to demonstrate a practical pattern for small, frequently updated personal data on Sia using standard client protocols rather than a custom user interface.
Problem
Contacts are important user-owned data, but most contact sync today depends on centralized account providers or conventional self-hosted servers backed by local or cloud storage.
A new contacts app would create adoption friction because users would need to change their existing workflow. Cardinal avoids that problem by exposing a CardDAV-compatible interface. Users can continue using clients such as Apple Contacts, Thunderbird, and Android CardDAV clients, while the durable contact state is stored through Sia.
This makes Sia useful in an existing workflow instead of requiring a new application to win adoption from scratch.
Why this fits the Sia grants program
Cardinal is designed around Sia’s current grant priorities:
- It uses the current
indexdand official Sia SDK stack. - It targets small files with frequent updates, including vCards, address book metadata, revision state, and sync records.
- It is infrastructure-first rather than a dashboard, marketing project, or documentation-only project.
- It uses existing client standards instead of requiring users to adopt a custom app.
- It avoids deprecated renterd/S3-based architecture.
- It is scoped for a small grant and does not attempt to become a full groupware platform.
The project directly supports user-owned data by letting the user or operator control the Sia account, App Key, deployment, and storage path.
Target users
Cardinal is intended for:
- Sia users who want self-hosted, user-owned contact sync.
- Developers who want a reference implementation for small mutable data on
indexd. - Self-hosters familiar with CardDAV workflows who want Sia-backed persistence.
- Sia ecosystem builders looking for a practical example of standard-client integration using the current SDK/indexd stack.
Scope
The grant will deliver a single-user CardDAV-compatible gateway for contacts.
In scope
- Self-hosted CardDAV gateway
- Single-user address book
- Sia SDK /
indexdstorage adapter - Pinned address book state
- Local SQLite cache for lookup and sync metadata
- vCard create, read, update, delete, import, and export
- ETag-based update handling
- Basic conflict handling for stale client updates
- Docker Compose setup
- Documentation for supported clients and known limitations
- Compatibility testing with selected standard clients
Architecture
Cardinal has four main components.
1. CardDAV gateway
A lightweight HTTP service exposes the CardDAV-compatible endpoints needed for selected client compatibility.
The MVP will support the method and endpoint set required for practical contact sync with selected clients, including:
- service discovery paths
OPTIONSPROPFINDGETPUTDELETE- required
REPORTflows for address book retrieval - ETag handling
If-Matchhandling where supported by the client
The documentation will clearly state which CardDAV methods and client flows are supported in v1.
2. Sia/indexd storage layer
The durable address book state is stored through Sia using the current SDK/indexd stack.
Cardinal will store:
- address book manifest
- contact object records or packed contact snapshots
- vCard object references
- revision metadata
- deletion markers where needed
- sync cursor state
The Sia/indexd-backed state is the durable source of truth. SQLite is used only as a local cache and query index.
3. Local cache and rebuild logic
A small SQLite database keeps local lookup and sync metadata for fast responses to CardDAV clients.
The cache will track:
- contact UID
- vCard resource path
- current ETag
- revision number
- deletion state
- last known sync cursor
If the service restarts or the cache is removed, Cardinal will rebuild local state from the Sia/indexd-backed manifest and object records.
4. Compatibility test harness
The project will include tests and documentation showing how to connect supported clients and verify sync behavior.
Compatibility testing will target:
- Apple Contacts on macOS or iOS
- Thunderbird address book
- one Android CardDAV client such as DAVx5
The goal is practical compatibility with documented clients, not a claim of universal CardDAV support.
Security model
Cardinal is self-hosted and does not operate a hosted service.
Security choices for v1:
- App Key is loaded from local configuration or environment variables.
- App Key is never exposed to CardDAV clients.
- CardDAV clients authenticate to the gateway with a local username and password.
- Passwords are stored hashed, not in plaintext.
- The gateway is designed to run behind HTTPS using a reverse proxy such as Caddy, Traefik, or Nginx.
- vCard inputs are validated before storage.
- No third-party analytics are included.
- No non-Sia blockchain integration is included.
Deliverables
Creatives Onchain will deliver an open-source repository containing:
- A self-hosted CardDAV-compatible gateway.
- A Sia SDK /
indexdstorage adapter. - A local SQLite cache for lookup, ETags, and sync state.
- Address book manifest and contact-state persistence through Sia/indexd.
- Docker Compose setup for local deployment.
- vCard import/export utility.
- Supported-client setup documentation.
- Compatibility notes for Apple Contacts, Thunderbird, and one Android CardDAV client.
- Integration tests for create, read, update, delete, restart, and cache rebuild flows.
- README with build, run, test, configuration, and troubleshooting instructions.
Milestones
Milestone 1 — Core gateway and indexd-backed contact state
Timeline: Weeks 1–4
Budget: $4,500
Deliverables:
- Project repository and build setup
- Docker Compose development environment
- CardDAV gateway skeleton
- Local authentication
- Single-user address book
- Sia SDK/indexd connection layer
- Address book manifest persisted through Sia/indexd
- Contact create/read/update/delete flow
- ETag generation for vCard resources
- SQLite cache for lookup and sync metadata
- vCard import/export command
Acceptance criteria:
- The repository builds from the documented setup steps.
- The gateway can run locally through Docker Compose.
- A contact can be created, edited, retrieved, and deleted through the gateway.
- Contact state is persisted through the Sia/indexd storage layer.
- Restarting the service does not lose address book state.
- SQLite can be rebuilt from Sia/indexd-backed state.
- The README documents configuration for App Key/indexd access.
Milestone 2 — Client compatibility and release hardening
Timeline: Weeks 5–8
Budget: $4,300
Deliverables:
- CardDAV discovery paths for supported clients
- Supported
OPTIONS,PROPFIND,GET,PUT,DELETE, andREPORTflows - ETag and stale-update handling
- Compatibility testing with Apple Contacts, Thunderbird, and one Android CardDAV client
- Integration tests for multi-client create/edit/delete behavior
- Error handling for invalid vCards, stale ETags, failed Sia/indexd writes, and interrupted sync
- Supported-method matrix
- Final release tag
- Final documentation and progress report
Acceptance criteria:
- At least two supported clients can connect to the gateway using documented steps.
- A contact created in one supported client can be retrieved or synced by another supported client.
- Editing and deleting contacts from supported clients works as documented.
- Invalid or conflicting updates return clear errors.
- The gateway can be stopped and restarted without losing address book state.
- Known limitations and unsupported CardDAV features are documented.
- All grant-funded code is open source and buildable from the README instructions.
Budget breakdown
| Item | Amount |
|---|---|
| CardDAV gateway implementation | $2,100 |
| Sia SDK/indexd storage adapter | $1,700 |
| Manifest, ETag, cache, and rebuild logic | $1,400 |
| Client compatibility testing | $1,200 |
| Docker Compose, setup docs, and examples | $800 |
| Integration tests and release hardening | $1,100 |
| Final documentation and reporting | $500 |
| Total | $8,800 |
Differentiation
Cardinal does not claim that CardDAV servers are missing. Existing CardDAV servers already exist.
The contribution is a Sia-native CardDAV gateway that uses the current SDK/indexd stack as the durable storage layer while preserving compatibility with existing contacts clients.
The project is also separate from calendar-focused Sia work. Cardinal does not implement CalDAV, calendar events, recurring events, reminders, app-store distribution, or shared calendars. It is a contacts-only protocol gateway.
Risks and mitigations
Risk: CardDAV compatibility becomes too broad.
Mitigation: v1 will support a documented compatibility subset tested against selected clients. Unsupported methods and clients will be clearly listed.
Risk: SQLite becomes the real storage layer.
Mitigation: SQLite is only a cache and query index. The durable address book state is stored through Sia/indexd and can be used to rebuild local state.
Risk: Sync behavior differs across clients.
Mitigation: the project will test against selected clients and document client-specific setup notes and limitations.
Risk: Sia/indexd write latency affects user experience.
Mitigation: the gateway will use local cache state for fast client responses while persisting durable updates through Sia/indexd. Known latency expectations will be documented.
Risk: Scope expands into groupware.
Mitigation: CalDAV, tasks, web UI, mobile apps, hosted SaaS, team sharing, and migration features are explicitly out of scope for this grant.
Maintenance plan
After the grant, Creatives Onchain will maintain the repository, review compatibility issues, and make small fixes related to the delivered v1 scope.
Maintenance will focus on:
- bug fixes
- supported-client compatibility notes
- dependency updates
- documentation improvements
- community issue triage
Large new features such as CalDAV, team sharing, or hosted deployments would require separate scoping and are not part of this grant.
Open source and reporting
All grant-funded code will be open source.
Creatives Onchain will provide progress reports with:
- completed work
- links to pull requests
- testing notes
- known issues
- updated documentation where applicable
ill all of your project’s code be open source?
Yes, 100%.
Leave a link where code will be accessible for review
Available soon
Do you agree to submit monthly progress reports?
Yes.
Do you agree to participate in a demo at a community call at a significant milestone or after completion?
Yes.
Contact info
Email: [email protected]
Creatives Onchain is a builder collective focused on developer tooling, protocol infrastructure, and operator-facing systems for blockchain ecosystems.
A recent example of our work is Stylus Trace Studio in the Arbitrum ecosystem. It is a profiling and trace inspection tool for Arbitrum Stylus that helps developers inspect execution traces, analyze gas and ink usage, generate flamegraphs, and catch performance regressions during development and CI. This is relevant to this proposal because it reflects direct experience building low-level developer tooling with structured outputs for real engineering workflows.
Links:
https://crates.io/crates/stylus-trace-studio/0.1.11
Why this project is relevant now
This project addresses a concrete integration problem in the part of the Sia ecosystem where active work is already happening: software built on top of indexd that keeps local state above the object and event model.
As more integrations build file views, local catalogs, and replay-based update logic on top of indexd, recovery correctness becomes a release requirement, not a later improvement. This harness gives those integrations a practical way to verify that local state can survive interruption, replay, and cleanup without drift.
That makes it useful immediately to the kind of indexd integrations already emerging on Sia, while staying separate from product development, protocol gateway work, and core Foundation roadmap work.
Prove of Work:
Creatives Onchain is a builder collective focused on developer tooling, protocol infrastructure, and operator-facing systems for blockchain ecosystems.
A recent example of our work is Stylus Trace Studio in the Arbitrum ecosystem. It is a profiling and trace inspection tool for Arbitrum Stylus that helps developers inspect execution traces, analyze gas and ink usage, generate flamegraphs, and catch performance regressions during development and CI. This is relevant to this proposal because it reflects direct experience building low-level developer tooling with structured outputs for real engineering workflows.
Links:
https://crates.io/crates/stylus-trace-studio/0.1.11
Summary
Cardinal is a focused infrastructure project for user-owned contact sync on Sia. It uses the current SDK/indexd stack, avoids deprecated Sia architecture, and works through existing CardDAV-compatible clients instead of introducing a new contacts app.
The grant will deliver a self-hosted, contacts-only CardDAV gateway with Sia/indexd-backed durable state, local cache rebuild support, compatibility testing, and clear documentation. The scope is intentionally narrow so the project can be delivered within an $8,800 small-grant budget and used immediately by reviewers and self-hosters who follow the documented setup.Also, we have previously worked with Sia.tech on the MVP we buit for our previous proposal: