Introduction
Project Name: SiContacts
Name of the organization or individual submitting the proposal: @manojsrinivasa (discord)
Github - jonumhills (Manoj Srinivasa) · GitHub
Describe your project
SiContacts is a privacy-first, local-first mobile address book app built with Expo (React Native) that stores all contact data in the user’s own Sia bucket via the react-native-sia SDK. It replaces Google Contacts and iCloud Contacts as the sync backend giving users the same familiar address book experience they already know, with their data stored on Sia rather than on a corporate server.
The app is built with Expo SDK 54 and uses expo-sqlite for offline-first local persistence. Contact records are stored as compact JSON objects (under 500 bytes each) and uploaded to Sia via packed uploads an ideal pattern for the small, frequent writes that contact edits generate. A manifest-based sync protocol keeps the address book consistent across devices. The app supports full vCard (.vcf) import and export, making migration from Google Contacts trivial and ensuring users are never locked in to Sia or to SiContacts itself.
Core features in scope: contact creation and editing, vCard import/export, group management, search, multi-device sync via Sia, and publication to the Google Play Store and Apple App Store.
[Demo video]
(https://drive.google.com/file/d/1ZctayPCVD1pYFlfxKYvDfH9HIhKSWQHu/view?usp=sharing)
How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
Your contacts list is the only dataset on your phone that exposes the privacy of people who never consented to being tracked. When your address book lives on Google’s servers, every app granted READ_CONTACTS permission harvests your entire social graph (names, phone numbers, and relationships of your family, colleagues, and friends) without their knowledge or consent. The FTC’s 2024 staff report confirmed that major platforms “engaged in vast surveillance of consumers” by collecting and indefinitely retaining data about both users and non-users of their platforms. The data in your address book describes people who never agreed to participate in any platform, yet their names, phone numbers, and relationships are retained indefinitely on third-party servers.
SiContacts solves this architecturally. Contact data lives exclusively in the user’s own Sia storage bucket, it never touches a third-party application server. Crucially, because the address book is not stored in the Android system ContactsContract database or synced through Google, the READ_CONTACTS attack surface is eliminated entirely. No third-party app can request access to your contacts through Google, because there is no Google copy to request.
This project also directly addresses the Foundation’s stated SDK priority: small files with constant changes. Individual contact records are under 500 bytes, edited frequently, and perfectly suited to packed uploads via the react-native-sia SDK and sia.storage.
We cannot provide grants to residents of jurisdictions under increased FATF monitoring, those that have active OFAC sanctions, or those that fail our bank compliance tests. We also cannot provide grants if your payment bank account is located in those same locations. Please review the following list.
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:
Total $8000 - 2 months of developer fees for @manojsrinivasa
What is the high-level architecture overview for the grant? What security best practices are you following? Please review our Development Guide for further details.
TechStack: Expo (React Native) UI + local SQLite database +
react-native-sia SDK (official Sia Foundation React Native package, MIT licensed).
Contacts are stored locally first for instant offline access, packed into compact JSON objects, and uploaded to the user’s own Sia bucket via sia.storage — the Sia Foundation’s hosted indexer, which requires no SiaCoins. A manifest-based sync protocol keeps the address book consistent across devices, downloading only records that have changed. All reads are served from local SQLite with zero network I/O; Sia is on the write path only, running as a background sync layer that never blocks the UI.
Security Best Practices
- Credential storage: The App Key is stored in expo-secure-store (iOS Keychain / Android Keystore). Never written to any unencrypted location.
- No secrets in code or version control: The App Key is entered by the user at onboarding only. No keys are hardcoded anywhere.
.envfiles are gitignored. - HTTPS enforcement: All calls to sia.storage are made over HTTPS.
- No system contacts database write: SiContacts deliberately does NOT write to the Android
ContactsContractdatabase or iOSCNContactStore. Contacts remain in the user’s Sia bucket only. This eliminates theREAD_CONTACTSpermission attack surface that makes Google Contacts a liability. - Data portability: Users can export their full address book as a standard
.vcffile at any time no lock-in to Sia or to SiContacts. - No telemetry: MIT license. No analytics SDKs, no crash reporters that exfiltrate data, no third-party data collection of any kind.
What are the goals of this small grant? Please provide a general timeline for completion.
The demo runs on mock/hardcoded data in a local dev environment, it’s not connected to a real Sia bucket or a real user flow. Here is what still needs to be built:
Month 1 (by June 20):
- Native build setup with EAS: react-native-sia requires a custom dev build and cannot run in Expo Go
- expo-secure-store integration to safely store the App Key in iOS Keychain and Android Keystore
- Production onboarding flow: step-by-step sia.storage connection with error states and recovery
- Full contact CRUD with validation and edge-case handling
- Offline-first architecture: all reads served from SQLite with background Sia sync that never blocks the UI
- Contact list with search
- vCard import covering Google Contacts and Apple Contacts export dialects
- vCard export for full portability
- Sia sync service (retries, conflict detection, manifest integrity)
Month 2 (by July 20):
- Multi-device sync correctness tested across Android and iOS simultaneously
- Contact groups
- Dark mode and full UI polish to meet App Store / Play Store guidelines
- Purchase Apple and Google developer accounts and submit App to both stores well before the deadline
- App review timelines vary by platform (I will work closely with testers and respond to any feedback promptly to get approved as early as possible)
- Bug fixes, user support, and continued maintenance of the app throughout both months and beyond
Who is the target user for your project?
Privacy-conscious everyday users who currently sync their contacts through Google or Apple and want an alternative that keeps their social graph off corporate servers. No blockchain knowledge required, users connect via the Sia Storage service (app.sia.storage). The vCard import flow means migration from Google Contacts takes under two minutes.
What are your plans for this project following the grant?
Following the grant I plan to maintain the app and continue adding features based on user feedback. If there is enough interest I would apply for a follow-up grant for things like CardDAV support, shared address books, or a web companion app.
Potential risks that will affect the outcome of the project:
-
react-native-siaAPI changes. The SDK is pre-1.0 and under active development. The project will pin to a specific version and the sync layer is isolated behind a single module to contain any breaking changes. -
vCard parsing edge cases. Google and Apple export slightly different
.vcfdialects. Non-critical parse failures will be skipped rather than blocking the full import. -
App store approval timelines. I have published apps before and am not too concerned about this. Submission will be initiated at least one week before the grant end date.
-
User onboarding friction. Connecting to sia.storage requires more steps than Google sync. A step-by-step in-app guide and a Demo Mode for users who want to explore before connecting will mitigate this.
Development Information
Will all of your project’s code be open-source?
Yes, MIT License.
Third-party dependencies (all MIT):
expo/expo-router/expo-sqlite/expo-secure-store/expo-document-picker/expo-sharing/expo-networkreact-native-sia— MIT (Sia Foundation)react-native-paper— MITexpo-dev-client— MIT
Leave a link where code will be accessible for review.
Do you agree to submit monthly progress reports?
Yes.
Contact info
Email: [email protected]
Any other preferred contact methods: @manojsrinivasa on Discord