# Small Grant: Pulse - An open-source, self-hosted FHIR data mobile app utilizing Sia's indexd packing engine

Grants Proposed
1

Introduction

Project Name

Pulse
An open-source, mobile-first FHIR health data vault utilizing Sia’s indexd packing engine.

Name of the organization or individual submitting the proposal:

Vaibhav Vemula @vaibhavv
Github - vaibhav-vemula (Vaibhav Vemula) · GitHub
Linkedin - https://www.linkedin.com/in/vaibhavvemula

Describe your project.

Pulse is a health data tracking app. The main problem with present wearables is vendor lock in. Big tech companies intentionally trap your fitness metrics inside their own apps to keep you in their ecosystem. They store your sleep and workout history on their corporate cloud servers so you are forced to keep buying their hardware and subscriptions.

Because they hold your history hostage, you lose everything when you switch to a new brand. Your past data is completely gone, forcing you to start over with a blank slate. This makes it almost impossible to monitor your long term health trends over several years.

You can use Pulse to solve this problem. The app fetches your fitness metrics directly from Android Health Connect and Apple HealthKit. It stores the information in a local cache and then sends it straight to the Sia decentralized network. If you switch off the native cloud sync in your phone settings, your data is not stored in the corporate cloud anymore and your personal information stays entirely safe.

When you decide to change your wearable watch in the future, there is no data loss. This works perfectly because all of these apps store and organize the data in the standardized FHIR (Fast Healthcare Interoperability Resources) format under the hood. Pulse brings all your history together so you truly own your health records.

How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?

Pulse serves the Sia Foundation mission of user owned data by turning a standard mobile phone into an independent storage client. It directly aligns with the committee funding priorities by targeting the specific SDK use case for small files with constant changes.The project solves two main problems.

First, it eliminates wearable vendor lock in. Right now, fitness trackers trap your private biometric history inside their corporate cloud databases. When you change your watch to a new brand, your years of historical sleep and heart rate tracking are completely lost because you cannot easily take the data with you. Pulse lets users sync this data directly from their phone local portals and move it onto the Sia network instead of a corporate cloud. Because all wearables format this data into the standardized FHIR format under the hood, your history is kept safe and continuous without any data loss.

Second, it solves the file fragmentation and repacking issue for mobile applications using the Sia SDK. Biometric data is noisy and creates thousands of tiny data points every single day. If an app tries to sync these small files to Sia constantly, it will exhaust the phone battery and clutter the network contracts. Pulse solves this by collecting the constant stream of small data changes inside an on device SQLite cache first. An automated background worker then packs, compresses, and encrypts a full day of records into a single optimized bundle before passing it to the native Sia Mobile SDK. This demonstrates a highly efficient, production ready way for regular consumers to use decentralized storage without any technical friction.

  • 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 $8,400 USD, paid out across a three month development timeline. This budget is allocated to developer fees for $2,800 per month. No additional hardware, equipment, or third party infrastructure costs are requested.

Category Detail Amount (USD)
Milestone 1 Core Ingestion Expo UI, HealthKit integration, Health Connect integration, FHIR serializer (at ingest), SQLite staging cache, biometric gate, SecureStore seed setup $2,800
Milestone 2 Bin-Pack Worker Local uploads directory buffer, bin-pack worker (expo-task-manager), gzip bundler, SQLite flush logic, age-based fallback trigger $2,800
Milestone 3 Sia Sync + Release react-native-sia integration, indexd App Key auth, upload flow, CID metadata index, GitHub release + developer docs $2,800
Total Funding Developer fees for 3 months $8,400

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

image
image2292×398 61.6 KB

Component Breakdown

  • React Native Expo UI Layer delivers a cross-platform dashboard for fitness graphs and permission control while protecting data views using native biometrics via Expo LocalAuthentication.

  • Health Data Frameworks tap directly into native operating system portals using react-native-health and react-native-health-connect to capture background delta metrics from Apple Watch, Wear OS, Whoop, and Garmin.

  • On-Device Processing Layer instantly converts raw incoming biometrics into universal FHIR R4 JSON blobs, stages them inside an Expo SQLite cache, and batches them into sandboxed .ndjson files via Expo FileSystem.

  • Sia Processing Layer manages background automation using an Expo TaskManager loop to run a space-efficient bin-packing algorithm, packing local files until they approach the optimal 4 MiB sector slab size.

  • Sia Decentralized Network leverages the native Rust FFI framework react-native-sia to execute zero-knowledge client-side encryption before offloading file pinning and contract management to an indexd provider.

Data Flow Explanation

First, the user bypasses the biometric security gate using FaceID or a fingerprint scan. This verification unlocks the application runtime and releases the user’s private Sia seed from the hardware-backed Expo SecureStore vault directly to the SDK memory space.

Next, the background health modules query the device fitness registry for fresh metrics using an anchor system to capture only new data changes. The app captures these delta events, immediately standardizes them into FHIR JSON format, and inserts them directly into the local staging cache database.

Once a day, or as soon as data limits accumulate, an automated task manager routine wakes up to flush the database logs out into a local sandboxed directory. The engine counts the total file sizes and runs a bin-packing check to minimize network space waste.

Finally, when the directory collection reaches 90% of a 4 MiB sector slab or hits a 3-day maximum age limit, the files are zipped together. The react-native-sia SDK encrypts the bundle locally using the derived seed keys and uploads the package to an indexd provider, which pushes the encrypted shards to the Sia network and returns a content identifier (CID) for local metadata indexing.

What security best practices are you following?

  • Hardware-Backed Key Isolation (Expo SecureStore & LocalAuthentication) The 12-word Sia seed is safely locked inside the phone’s physical hardware enclave (iOS Keychain / Android Keystore) and is only released to app memory after a successful biometric fingerprint or FaceID scan.

  • Isolated Device Sandboxing (Expo FileSystem & Expo SQLite) All raw health data and temporary .ndjson files are kept strictly inside the operating system’s private app sandbox, preventing any third-party apps from accessing or reading local files.

  • SDK-Level Native Encryption (react-native-sia) To keep the app efficient native Sia SDK automatically handles zero-knowledge, client-side encryption using keys derived directly from the hardware-secured seed phrase before any file touches the network.

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

The primary goal is to build Pulse mobile app that lets everyday users privately own and control their personal health data.

Break wearable lock-in Build a single app that pulls fitness data from any device (Apple Watch, Whoop, Fitbit, Garmin) and stores it in one place the user controls, not a corporate cloud.

Solve the small-file problem for mobile Show how a phone can continuously collect health metrics, batch them efficiently, and sync to the Sia network without draining the battery or wasting storage space.

Make decentralized storage invisible Deliver a simple, consumer-friendly interface so anyone can secure their health records on Sia without any technical knowledge, no command line, no server setup required.

Month 1: Core Ingestion Plane and SQLite Cache

  • Focus: Frontend interfaces and local operating system hooks.

  • Deliverables: Build the primary React Native Expo dashboard screens. Implement system permission handling and establish data extraction pipelines from native iOS HealthKit and Android Health Connect modules. Configure the internal Expo SQLite staging cache to store raw streaming metrics locally on the device partition.

Month 2: Compaction Worker and Local Encryption

  • Focus: Data optimization and on-device cryptographic security.

  • Deliverables: Write the local data mapping scripts to translate incoming raw fitness metrics into universal FHIR JSON files. Build an automated file-bundling routine that compresses a full day’s worth of database tracking logs into single zipped packages. Integrate Expo SecureStore and hardware enclaves to securely manage private keys locally.

Month 3: Packed indexd Sync and Public Validation

  • Focus: Network integration, automation, and open-source release.

  • Deliverables: Integrate the official react-native-sia library into the Expo build pipeline. Configure background workers to automatically encrypt and upload the bundled daily data packages using an App Key pointing to an indexd provider. Deliver comprehensive developer setup documentation and open-source the entire codebase on GitHub for public community audit and maintenance.

Who is the target user for your project?

  • People who want privacy: They want to track their health without big tech companies seeing, selling, or using their personal data.

  • People who change watches: They want to switch fitness tracker brands freely without losing years of past health records.

  • People avoiding monthly fees: They want to look at their long-term fitness trends without paying a subscription just to see old data.

  • People with health conditions: They need a safe, permanent record of their daily body trends without trusting a corporate cloud server.

  • People who want raw data: They want to keep and download their actual health files directly on their phone to use however they want.

What are your plans for this project following the grant?

Following the grant, Pulse will remain open source and freely available with no plans for monetization. The repository will be actively maintained on GitHub, welcoming community contributions and staying current with any changes to the Sia network or mobile health platform APIs.

Potential risks that will affect the outcome of the project

  • FHIR Schema Volatility
    Health data structures shift across device manufacturers and OS versions. Rather than parsing records against a strict schema, the app stores payloads as raw JSON blobs and only indexes basic root-level fields. This means schema changes in HealthKit or Health Connect do not break the ingestion pipeline.

  • Battery and Thread Exhaustion
    Continuous background health updates from the OS can lock application threads and drain battery if handled naively. Ingestion and network sync are kept completely separate. The app writes incoming records to a local queue immediately and the upload worker runs independently on its own schedule, so neither operation blocks the other.

  • Distributed Network Latency
    Uploading to a decentralized host network introduces unpredictable timing. The app never waits on the network before confirming success to the user. Records are committed to the local cache first and the indexd upload runs asynchronously in the background, so a slow host or contract delay is invisible to the user.

Development Information

  • Will all of your project’s code be open-source? Yes.
  • Leave a link where code will be accessible for review: GitHub - vaibhav-vemula/pulse · GitHub
  • Do you agree to submit monthly progress reports? Yes.

Contact Info

2

Hello, welcome.

A bit of feedback that is only opinion.

What security best practices are you following? You likely do not need to state what the Sia sdk itself already does, and you also generally don’t need to double encrypt things anyways.

Thanks.

3

Hi @pcfreak30 ,

Thanks for pointing that out. You are right about double encryption. I have removed the redundant encryption step and have updated the proposal.

4

How much are you making use of the sia sdk, because generally speaking, I would rely on it as much as possible vs doing anything with the indexd API directly, ex Data records are mapped via byte-offsets managed by indexd.

A lot of your proposal I think needs to be made more clear what is leveraging the SDK, and what aspects are custom, and if there is a reason you need to do it custom.

Thanks.

5

My default plan was to custom build the byte-mapping and encryption layers to adhere HIPAA compliance. Your feedback helped me realize I was over-engineering it, since the SDK natively covers those exact storage and indexing mechanics. It changed how I am approaching the architecture and saved me from redundant work.

Here is the breakdown:

Leveraging from the Sia SDK:

  • Client-side encryption
  • Packed uploads and slab allocation
  • Byte-offset mapping and indexing
  • Point-queries for partial downloads
  • In-memory key derivation

Custom Built (The Gateway Engine):

  • Go HTTP Webhook Server to receive device data streams
  • Token Authentication Middleware to block local network spam
  • SQLite Staging Cache to provide a low-latency local buffer so phone apps get a fast response and don’t timeout

Custom components are used to safely ingest device data without performance lag. I have updated the grant application to reflect this accordingly. Please let me know if you see any other blind spots or want to discuss further.

6

Be aware I am asking the below because I feel it is a bit warranted…

Given the nature of this grant (HIPPA and academic?), do you have any early interest in this, and do you have plans, commercially (monetization) for this project post-grant, or will you keep it as purely a public-good/community project. The funding guidelines meant sustainability in terms of funding, not project through active repository maintenance.

Overall is there active interest in this idea, and if not, how do you plan on getting feedback, since I will tell you from experience, the Sia community is small, and getting users for this would definitely require going outside the crypto bubble TBH.

Thanks.

7

Thank you again for the candid feedback and concerns. I have a keen interest in this field from my background building enterprise Electronic Health Record (EHR) applications and implementing HIPAA compliance. I have seen firsthand how fragmented wearable telemetry is, like when switching from a Whoop strap to an Apple Watch, and how frustrated users are by corporate data mining and vendor lock in.

I have no intention of monetizing Pulse. It is a free, open source community project. I am targeting Reddit communities like r/whoop, r/privacy, and r/selfhosted where I have personally read these data sovereignty complaints. I will be actively reaching out to these users to get people onto the platform, gather real user feedback, and welcome future open source collaborators.

Regarding the funding sustainability rule, I am building Pulse as a lightweight utility self hosted by the user via Docker on their own hardware and it requires exactly zero ongoing operational capital after the grant since there are no centralized web servers, SaaS infrastructure bills, or cloud database fees for me to finance long term. I am fully committed to being an active long term contributor to keep the codebase healthy.

Regarding HIPAA, my main concern was securing on the fly encryption from the local hardware to the storage layer, which is why I originally planned a custom encryption setup. Now that I see how the Sia SDK natively handles this, I will be making use of Sia’s built in client side encryption to maintain absolute privacy without duplicating features. Please let me know if you see any other blind spots or want to discuss further!

8

So this will be:

  • A go based web service
  • Ingests medical data of a specific format/standard/spec
  • Will upload and relay this for the user via the sdk

And the sqlite db will just be a temporary way to store all the data, or just metadata, with a go co-routines doing the batch processing?

I think you would be interested and find useful in how the foundation is building s3d at GitHub - SiaFoundation/s3d: A lightweight, S3-compatible Renter for the Sia network · GitHub b/c there is a good amount of overlap as a gateway server. It can likely inform you on what design decisions you should make.

Lastly, if you are able to, it might be a good idea to update your diagram since your understanding of Sia has improved.

Thanks.

9

Also some additional feedback. I am not sure regarding the onboarding friction of this, if its intended to be a drop-in placement server backend for existing apps, or for some new app? I know basically zero about fitness apps and that ecosystem.

But based on what you have said, if you were to want to get wider adoption of something that can upload medical data from X smart device, and send to Sia, is it possible to do the data collection at the edge, on device, and remove the need for a relay/gateway translation server the user has to run, as that will instantly nuke adoption to a fraction IMO, compared to if there is no complexity in getting linked up to a indexer.

Also, please be aware, I am a community member and not a decision maker, so my inputs are my own.

But overall from an adoption standpoint, anything that seems like it would want to give a facebook-type user privacy on their smart watch (I am assuming your going further then academic people based on your mentioning of smart watches), yet needs a docker container, instantly makes this a Linux skill-level type project. And the users you are targeting as early adopters make sense, but I am viewing what your pitching as an idea and cannot help but think that if you wanted to maximize the accessibility of such a thing, you would want to re-think the approach… and do on device :person_shrugging: .

That’s my 2C, and you have criticisms now… for both ways you can execute this :P.

Thanks.

10

I agree asking an everyday consumer to use Pulse (i.e run Docker) is an instant barrier. I am building Pulse to fit into two worlds, the core Go and SQLite engine is designed to support two different deployment models. It can run as a server backend for integration and sync applications, and since the code is portable, it can also be embedded directly on a device for an edge deployment inside a native mobile app. This allows it to serve startups building privacy focused health apps, engineers building third party sync tools, or individual developers who want to escape vendor lock in.

While I am not building a consumer facing mobile app for this initial stage, Pulse could easily compile into an iOS or Android app down the road to eliminate the Docker requirement entirely. When I mentioned reading through Reddit threads, I was tracking the independent developers who were trying to build custom integration fixes for users moving between platforms. I should initially approach these builders and startups to adopt Pulse initially.

I did look into s3d and I feel that staging cache like SQLite is still necessary to avoid file fragmentation (I wanna pack set of FHIR packets instead of creating object for every single minute of raw biometric data) and prevent network timeouts, especially if consumer apps are using Pulse. With a new wearable and health app coming out almost every month, developers shouldn’t have to reinvent the wheel for decentralized storage. Pulse can serve as a reusable framework that handles the heavy lifting and reduces their workload from day one.

I really liked interacting with you. I got more clarity on the Sia Foundation tools and also on what I am building. I am curious to hear what other thoughts or critiques you have. I haven’t updated the grant application yet. Aside from the view of developer adoption, do you see any other underlying issues or technical concerns with this approach before I update it?

11

It has been my subjective experience that if you build a foundation in golang then want to put that on mobile/IoT, the ecosystems & frameworks may just not fit well especially since golang dynamic .so/.dll are still second class citizens (and the ideal way go deals with that is usually https://github.com/hashicorp/go-plugin). It may can be done, but my own experience is golang is just honestly crap when it comes to cross-lang interop or playing nice with others :man_shrugging: .

With that said, I think I would highly recommend designing this in reverse and figuring out what technology stack would best fit for the IoT side of things for end users.

The foundation has created many SDK targets, including react native, and dart. Those all are done via FFI from rust as the source.

If you are wanting to target end users eventually, you don’t want to duplicate the work, if a library, and so rust or dart may be something you want, esp as rust as first class support to create dynamic libs.

As for referencing s3d, I was not suggesting you don’t need a sqlite, but look at what the foundation is doing to understand how they solve problems around needing a local staging buffer as you put it.

I hope this helps.

Thanks.

12

Thanks for the reality check on Go, You completely get what I am trying to do here and helping me analyze to design it better via architecture.

What do you think of shifting Pulse into a mobile application that syncs data under the hood? It would process everything right on the device to bridge data from various wearable platforms like Whoop, Garmin, and Fitbit. This completely removes the adoption friction, turning my direct targets into the actual consumers who raised these privacy concerns rather than the developers building tools for them. I will initially focus entirely on an Android app that utilizes the Sia network directly from the edge of the device. The basic architectural pipeline would flow as:

Android App → Android Health Connect portal → Local SQLite staging cache → Sia Mobile SDK → Sia Network.

I would love to hear your thoughts on this mobile first direction as I explore deeper into architectural details.

13

As stated, I don’t know enough on the health/medical ecosystem, protocols, or file formats/specs to give any domain advice other then if you want something to be reused vs power users and end users, with the end users being on IoT devices, you need use the tech that will work with end users upfront, even if you develop docker 1st.

So, to be clear, I never said to drop the docker idea, but that if you do that as an entrypoint that the underlying tech should be compatible with end-user devices from the start, or your going to have a really bad time.

Its your call on who exactly you want to focus on as a user profile, but you should definitely be doing research on the tech stacks to not shoot yourself in the foot later.

My personal opinion is something for end users is more immediately useful, and Sia needs demand. So if that can be achieved, I would then ask what is the unique benefit of a gateway server, which will have a limited target audience in comparison?

Thanks.

14

Thanks for all your feedback and helping me refine my approach, I took a day to re-evaluate things. After researching the tech stack and the user dynamics, I am convinced that a consumer-facing mobile app is much more practical, will drive faster adoption, and directly solves the problem of protecting health data without losing history when switching watches. I have updated the grant body to reflect a mobile application, but because the platform will not allow me to edit the original title of this post from “gateway” to “mobile app,” should I delete this submission and create a new grant thread altogether? and I am open for any further concerns you have with the mobile app approach.

15

That is something for @mecsbecs to chime in on and decide.

Thanks.

1 Like