Small Grant: Sia Integration Preflight (MVP) — repo-local QA for SDK/indexd integrations

Grants Rejected
1

Introduction

Project Name:
Small Grant: Sia Integration Preflight (MVP) — repo-local QA for SDK/indexd integrations

Name of the organization or individual submitting the proposal:
Dapps over Apps

Current MVP repo: https://github.com/steven3002/HostaProbe

Demo video: https://drive.google.com/file/d/1m_yuqn2nQr9aNVjqMSPT4WSAppZ7011z/view?usp=sharing

Describe your project.
Sia Integration Preflight is a repo-local CLI with a companion GitHub Action for teams building on Sia with SDKs or indexd. It provides a repeatable pre-release check for the storage flow from the same environment that will actually run the integration.

Compared with the earlier HostProbe submission, this version changes both the project scope and the MVP. The earlier version centered on shortlist host probing as the main workflow. This version centers SDK/indexd integration QA: connect to a chosen indexer, authenticate with a stored App Key, upload a small fixture object, pin it, download it, verify byte equality, and save both JSON and HTML reports. The updated MVP also includes clearer step-level result reporting and a lightweight local diagnostics pass used only after a failed storage step. The earlier host probing work remains only as that supporting diagnostics layer.

Our revised scope is aligned with the Foundation’s current direction: building with SDKs, building on indexd, and QA tooling for integrations. It is not a hosted service, not a dashboard, not a public API, and not a discovery, ranking, or benchmarking product.

How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
This project supports user-owned data by making it easier to ship and maintain applications that store real user data on Sia. The problem it solves is the gap between example-level integration and release confidence. Documentation and example snippets are useful starting points, but teams still need a reusable check they can keep in their own repository and run before release, during migrations, or after SDK or indexd changes.

Sia Integration Preflight answers one practical question: can this integration still complete the storage flow from this environment, and if not, at which step did it fail? By turning that into a small deterministic tool with stable artifacts, the project reduces integration breakage, shortens debugging time, and lowers friction for teams building on Sia.

This project is intentionally narrow. It does not try to replace the SDK, the docs, or a hosted product layer. It turns the documented storage path into a repeatable local and CI check.

Are you a resident of any jurisdiction on that list? Yes/No
No

Will your payment bank account be located in any jurisdiction on that list? Yes/No
No

Grant Specifics

Amount of money requested and justification with a reasonable breakdown of expenses:
$10,000 USD total

Rate: $125/hour
Total: 80 hours

Breakdown:

  • CLI cleanup, config handling, and versioned report schema: 10h = $1,250

  • SDK/indexd preflight implementation and hardening for connect, upload, pin, download, and byte verification: 24h = $3,000

  • Failure classification, reason codes, and supporting diagnostics path: 14h = $1,750

  • JSON/HTML outputs, sample artifacts, and fixtures: 10h = $1,250

  • GitHub Action, CI example workflow, and artifact upload path: 12h = $1,500

  • Tests, docs, packaging, tagged release, and review fixes: 10h = $1,250

Total: 80h = $10,000

This budget is for hardening and formalizing an updated MVP. It does not include hosted infrastructure, public APIs, continuous monitoring, portal work, or a broader platform build.

What is the high-level architecture overview for the grant? What security best practices are you following?

High-level architecture

Inputs

  • indexer URL

  • stored App Key supplied through local config or CI secrets

  • small fixture file

  • optional config for timeouts and output paths

Pipeline

  • validate config

  • connect to the chosen indexer with the stored App Key

  • run the preflight flow

  • upload fixture

  • pin object

  • download object

  • verify byte equality

  • optionally run a lightweight diagnostics pass after a failed storage step

  • emit saved reports

  • exit with a clear pass/fail status

Outputs

  • report.json

  • report.html

  • CI artifacts from the GitHub Action run

Security and operational practices

  • no recovery phrase stored by the tool

  • no secrets committed to the repository

  • App Keys supplied through secure local config or CI secrets

  • reports exclude secrets and include only the data needed to explain pass/fail state

  • explicit timeouts and bounded retry behavior

  • no hosted persistence of user data

  • open-source code and reviewable build steps

CI mode assumes a previously approved app and a stored App Key.

What are the goals of this small grant? Please provide a general timeline for completion.

Goal:
Turn the updated public MVP into a clean, documented, and more reusable preflight tool that lets a builder verify whether a Sia SDK/indexd integration still works from the environment that will actually run it.

Timeline: 2 months

Month 1 — core hardening and report contract

  • finalize CLI input format

  • finalize versioned report schema

  • clean up the current preflight flow

  • add fixture handling and sample outputs

  • finalize step-level failure classification

Acceptance criteria

  • a reviewer can run the CLI locally with sample config

  • the tool writes a valid report.json on both success and controlled failure

  • the schema and reason-code list are committed and documented

  • sample success and failure outputs are available for review

Month 2 — CI support, packaging, and public release

  • finalize the supporting diagnostics pass

  • add GitHub Action wrapper and example workflow

  • finalize artifact generation for CI runs

  • finalize README and review instructions

  • publish a tagged MVP release

  • refresh demo materials

Acceptance criteria

  • with valid config, the tool completes the preflight and exits successfully

  • with an invalid App Key or forced failure, the tool exits non-zero and identifies the failed stage clearly

  • a GitHub Actions run produces saved report artifacts

  • README covers both local and CI usage

  • a tagged public release is available for review

Who is the target user for your project?
The target user is a technical builder already working with Sia, especially:

  • developers building a new application with SDKs or indexd

  • teams maintaining or refreshing an older integration

  • CI or DevOps owners who want a pre-release storage regression check

  • developers who want a small reusable harness instead of one-off debug scripts

What are your plans for this project following the grant?
Following the grant, the project will remain a small public QA tool rather than a one-off grant artifact. The immediate post-grant focus will be maintaining compatibility with current SDK/indexd flows, keeping the report schema versioned, and accepting issues and feedback through GitHub and the Sia Forum thread.

The project will be maintained for at least 3-6 months after delivery for small fixes, compatibility updates, and documentation improvements. If the workflow shows real use, the next stage would be deeper fixture coverage and a broader compatibility matrix while keeping the project repo-local and CI-focused rather than turning it into a hosted service.

Potential risks that will affect the outcome of the project:

  • External indexer availability can create noisy failures
    Mitigation: clearly separate upstream availability failures from auth, upload, download, and verification failures.

  • SDK or indexd changes during development can affect behavior
    Mitigation: keep the flow narrow, use a versioned output schema, and add fixture-backed tests around each preflight stage.

  • CI and local environments can fail differently
    Mitigation: keep both local and CI runs first-class in the MVP, use explicit reason codes, and save artifacts for review.

Development Information

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

Leave a link where code will be accessible for review.
https://github.com/steven3002/HostaProbe

Links

Do you agree to submit monthly progress reports?
Yes.

Contact info

Email:
[email protected]

Any other preferred contact methods:
X/Twitter: @dappsoverapps

2

Hi @DappsoverApps - given your other recent proposal was rejected by the Committee due to lack of stated community need, have you heard from any community members about the problem this MVP is trying to solve?

3

Hello @mecsbecs ,Not through one on one outreach before posting. But there is public community feedback on this exact need.

In the HostScore thread, a community member asked for more granular comparison by location, said uptime, reliability, and longevity matter for host selection, and called this kind of tooling a needed project. That is the same core workflow this MVP targets: checking a shortlist of hosts from one vantage point to see which ones are actually usable and why.That is why the scope is narrow. It is not a HostScore replacement, a portal, or a leaderboard. It is a practical shortlist scanner built around a need the community has already pointed to.

Thank you.

4

The features you mentioned have already been implemented in HostScore.

5

Hi @mike76 , you are absolutely right, and I apologize; mentioning geographic granularity in my last reply was the wrong way to frame our tool. HostScore does a fantastic job of benchmarking from distributed global data centers, and it is the absolute gold standard for network-wide host reputation. Where HostProbe diverges is that it is fundamentally a local, subjective diagnostic CLI, not an objective global leaderboard.

These are how we see them solving two different problems:

  1. Subjective Local Reachability vs. Objective Benchmarks
    In p2p networks, reachability is subjective. A host might have a perfect 100% score on HostScore’s backend, but be completely unreachable from a specific developer’s local machine due to their specific ISP routing, strict NAT, or local firewalls. HostProbe is a stateless, zero-cost CLI that developers can run locally (or bake into their CI/CD) to instantly verify if their exact environment can establish a cryptographic handshake with a shortlisted host before they attempt to spend Siacoins or hang their application.

  2. The Pre-Flight Check for RHP3 (SiaMux)
    While HostScore fully tests RHP3 hosts by funding Ephemeral Accounts and forming contracts, developers often just need to know if their local network can successfully negotiate a SiaMux connection on port 9984. HostProbe acts as a lightweight pre-flight check to validate local SiaMux connectivity without requiring a synced node or a funded wallet.

  3. Built for the RHP4 / WebTransport Future
    This client-side architecture is also critical for where the network is heading. With RHP4 and tools like indexd, web apps will stream directly from hosts via WebTransport. A centralized backend service cannot test if an end-user’s specific local browser/UDP setup can successfully negotiate a WebTransport stream with a host. HostProbe’s architecture is designed specifically to evolve into testing this localized, client-side connectivity.

Our submitted MVP proves this lightweight, local probing architecture using RHP2. Moving forward, we see the tools as highly complementary: builders use HostScore’s API to discover the top global hosts, and then use HostProbe locally to instantly triage which of those hosts are actively reachable from their specific client environment.

Please we will aprreciate your follow on response as it helps clear the air on any overlapping concerns between Hostprobe and Hostscore.
Thank you.

6

If HostScore sees a host online and “100%” OK, that usually means that host is running fine and no further interference is required. It’s usually the other way around, when a host seems to be working fine from a local perspective but can’t be accessed from outside.

After the V2 hardfork, there are no more RHP3 hosts on the network. I’m surprised this is still a topic.

7

Hi @mike76 , HostScore benchmarks hosts across the network. HostProbe is narrower in the sense that, it lets a builder take a shortlist, run a check from their own environment, and save a point-in-time report showing which hosts connected, timed out, or failed the probe. So this is meant as local validation for a specific setup, not another public scoring or discovery tool.

That is the boundary we intend to keep. If you still think it overlaps, we would appreciate where you think the overlap starts. Looking forward to your response. thanks.

8

The gap we are trying to fill isn’t about the host’s configuration; it’s about the developer’s local environment. This is the exact developer experience we are trying to solve:

The “Inside-Out” Network Problem & The RHP4 Future HostScore tests connections from the outside in (from a data center to the host). HostProbe tests from the inside out (from the developer’s specific machine to the host).

As the network fully migrates to RHP4 and WebTransport, this client-side vantage point becomes critical. WebTransport relies on UDP, which is notoriously mangled, throttled, or outright blocked by restrictive corporate VPNs, strict university Wi-Fi, and bad local NATs.
Standard network tools like netcat or telnet are essentially useless for verifying complex WebTransport handshakes. HostScore will correctly show the host is 100% globally healthy, but the developer’s client app will still hang because their own network is dropping the UDP packets. Setting up a full native node just to watch the logs fail is slow and tedious.

HostProbe is a 10-second, zero-cost ‘pre-flight’ CLI that lets the developer instantly check: “Is this shortlisted host dead, or is my local environment just failing the protocol handshake?”
Ultimately, we don’t see HostProbe as a replacement for HostScore at all. We see a workflow where a developer queries HostScore’s API to discover the best 50 global hosts as a shortlist, and then runs HostProbe locally to verify which of those 50 their specific network environment can actually handshake with before writing any contract code.

9

As a team, our standard engineering philosophy is to build for deep backward compatibility to ensure no legacy setups are left behind. That mindset led us to anchor our MVP’s architecture to the RHP2 base layer. However, it was an oversight on our part not to realize that the network had completely deprecated RHP3 and is already aggressively pivoting to RHP4.
That being said, this rapid transition actually makes the need for a client-side probe even stronger. As the network moves toward RHP4 and WebTransport, web apps will be streaming directly from hosts. WebTransport relies on UDP, which is notoriously blocked or throttled by strict client-side firewalls and enterprise networks. A global backend service cannot verify if an end-user’s specific browser setup can successfully negotiate a UDP WebTransport stream.

Our current MVP proves this localized, point-in-time diagnostic architecture using RHP2. We believe evolving this exact architecture will be highly necessary for developers to troubleshoot local WebTransport connectivity in the upcoming RHP4 era.

10

Hi @DappsoverApps - thank you for your explanation. Your proposal comes at an interesting time, however, as we will be releasing new Grants Program funding guidelines next week. This also means the next Grants Committee meeting will be held on April 28th (with April 22 as the proposal submission deadline) to allow for adequate time for these new guidelines to be reviewed & incorporated into proposals.

Please review these guidelines when they’re released next week and then tag me when/if you’ve updated your proposal accordingly to be reviewed.

11

@DappsoverApps - the new guidelines have been posted:

12

Hello @mecsbecs,

We have updated the proposal and rebuilt the MVP to reflect the revised scope.

The project is no longer centered on shortlist host probing. It is now a repo-local QA tool for SDK/indexd integrations. The updated MVP now covers indexer connection with a stored App Key, fixture upload, pinning, download and byte verification, saved JSON/HTML reports, clearer step-level reporting, and a lightweight diagnostics pass after failed storage steps.

The revised scope is now much more closely aligned with the latest guideline and current integration QA need. Please let the reviewers know that the scope has changed materially from the earlier submission and that the current proposal should be reviewed on this updated basis.Also, we wanted to change the title of the proposal to " Small Grant: Sia Integration Preflight (MVP) — repo-local QA for SDK/indexd integrations" but we were unable to edit it.

Thank you.

13

Hi @DappsoverApps - I’ve updated the title of the post, and thank you for these edits.

This will be presented to the Committee next week.

1 Like
14

Hello @DappsoverApps,

The Committee was unfortunately unable to get to your proposal during today’s meeting. Your proposal has now been slotted for review during the next meeting on May 12th.

Thank you for your patience.

15

Thanks for your proposal to The Sia Foundation Grants Program.

After review, the Committee has decided to reject your proposal citing the following reasons:

  • They do not see a valuable use case in this project.

  • The Committee does not believe the scope of the project justifies the budget requested - the proposed scope and budget are inflated in comparison to the work required.

  • The project name includes “Sia” which is not compliant with our brand guidelines.

We’ll be moving this to the Rejected section of the Forum. Thanks again for your proposal, and you’re always welcome to submit new requests if you feel you can address the Committee’s concerns.