Standard Grant : Dobsia Vault

Grants Rejected
1

Project Name: Dobsia Vault

Name of the organization or individual submitting the proposal: Dartsia Team

Project Description :

The Dartsia project was originally created to provide the Sia community with a smooth, scalable mobile interface to easily access their renterd installations and perform all available operations found in renterd.
In its initial design, Dartsia used middleware installed on the same machine as renterd, ensuring communication between the mobile app and the Sia network via renterd, with an encryption protocol to secure all exchanges.

The project received support from the Sia Foundation and was developed in two phases.

Phase 1 delivered a functional MVP with:

  • Login – Connect to renterd using its IPv4/DNS address and password.
  • Network Overview – Real-time display of Sia network status and metrics (active hosts, total storage, used storage, storage price per TB).
  • Host Search – List all available and active hosts.
  • Host Information – Display detailed information and scoring for each host.
  • My Host Overview – View operational data and status of your host.
  • Modify renterd Parameters – Easily change renterd configuration settings.
  • Buckets & File Management (70%) – Manage buckets, files, and folders (create, upload, rename, delete, move).
  • Communication Middleware – Developed in Go to handle communication between the app and renterd, manage connection initialization, and encrypt traffic with SSL + AES256.

Phase 2 resulted in a more production-ready app with:

  • File encryption.
  • Phone file backup (similar to Google Drive).
  • Notifications.
  • Multi-format file viewer (documents, videos, etc.).
  • SQLiteDB backup system for the renterd server.

Following this phase, we encouraged Sia users to install and try the app. Feedback revealed that requiring middleware installation on the same renterd instance was overly complex for non-technical users.

DobSia: Decentralized Storage for Everyone

DobSia is a next-generation mobile app combining two key features of the Sia blockchain:

  • A full-featured wallet to interact with the Sia chain.
  • A file hosting and sharing service using vault technology to secure user data through indexd.

It offers a seamless, simple, and highly secure mobile user experience.

Core Principles:

  • Privacy-First: Create private digital vaults with end-to-end encryption. You control the keys.
  • Web3 Power, Web2 Simplicity: Sign up with a BIP39 wallet seed phrase, or use Google/Twitch login. No tokens required to start – enjoy 1 GB free storage.

Key Features:

  • Generate BIP39 keys using email and password.
  • Transfer files from Google Drive or Dropbox into DobSia.
  • Share end-to-end encrypted data with magic links (view/upload, permissions, storage allocation).
  • View media in a gallery, play audio/video, and stream directly from the Sia network.

image
image750×1624 105 KB

image
image750×1624 21.2 KB

image
image750×1624 58.8 KB

image
image750×1624 127 KB

Advantages:

  • Simplified account creation using email/password to generate BIP39 keys via enhanced PBKDF2 derivation – combining Web2 ease with Web3 security.
  • All app–middleware communication encrypted with reinforced SSL/TLS + client-side AES256. Metadata is also encrypted.
  • Vault System: Each vault has its own key pair. The vault’s public key encrypts Data Encryption Keys (DEKs), while its private key (encrypted with the user’s public key) decrypts them.
  • Secure Sharing: For each shared file, a temporary DEK is generated, used to encrypt the file, then encrypted with the vault’s public key. Anyone with the vault’s private key can decrypt the DEK and access the file.
  • Secure Wallet: Private keys are stored only on the user’s device, never elsewhere.

Who benefits from your project?

DobSia is designed for both the Sia community and Web3 users in general, addressing the need for simple, mobile-friendly decentralized storage and wallet management.

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

The project supports the mission of user-owned data by providing an efficient, secure way to store files and manage Sia wallets from a mobile device.

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

Budget :

To be able to carry out this project, we are requesting a total budget of $41100. As indicated in the terms of the Sia Foundation, the budget will be used monthly and at each Milestone.

Timeline with milestones

Milestones Milestone / Deliverable / Duration Budget
1 Milestone 1: Dartsia Light – Wallet Setup & Key Management (4 weeks) - Implement wallet creation with local encryption (seed, password) - Build local secure key storage - Design and integrate onboarding UI - Validate Siacoin address generation 6850$
2 Milestone 2 : Dartsia Light – Wallet Import & Transactions (4 weeks) - Implement wallet import from seed phrase - Develop transaction UI (send / receive SC) - Integrate real-time balance updates - Integrate transaction history via explorer 6850$
3 Milestone 3 : Dartsia Light – Wallet Security improving (4 weeks) - Wallet security auditing and testing - Wallet & Key Management Analysis - Compliance analysis - Security report - GPlay/Apple Play Publicing 6850$
4 Milestone 4: Dartsia Light – Indexd Integration & File Encryption (4 weeks) - Integrate Indexd protocol for file storage - Implement file encryption (AES, local pre-upload) - Develop file/folder management UI - Secure storage of metadata - Deliverable: Basic encrypted file storage 6850$
5 Milestone 5: Dartsia Light – File Sharing & Sync Features (4 weeks) - Generate and manage time-limited file streaming links - Implement folder synchronization (local ↔ indexd) - Set up permissions & visibility options 6850$
6 Milestone 6: Deployment & Launch (4 weeks) - Finalize Play Store and App Store publishing - Complete documentation (user + dev guides) - Publish final code on GitHub - Onboarding users - Grant report submitted 6850$

Will all of your project’s code be open-source?
Yes all the project code will be OpenSource and under MIT-License

Leave a link where code will be accessible for review.

Contact informations :

Email: [email protected]

2

Hello, some criticisms that immediately stand out.

  • Unless you are messing with indexd in late Q4 at minimum, I view it as high risk to plan for something when you do not have the proper information about it. There is not much public yet about indexd so it is a bad idea to plan based on it unless you are very conservative in your timeline.
  • I am confused on what a wallet is used for if you plan to build on indexd. The goal of it is to outsource needing to deal with the blockchain to a 3rd party. That will mean money as well.
  • Launch small marketing campaign for onboarding users the foundations stance on marketing has not changed AFAIK, and your entire budget should be itemized outside the milestones. It is not clear if you are requesting a marketing budget.

I would ask you clarify if you are trying to have a system where the user needs to manage their own SC, or where that gets abstracted. This feels like a mashup from your previous renterd based ideas that im not sure fully makes sense?

Kudos.

3

Thank you for your very helpful feedback. I will try to answer as clearly as possible.

  • For the previous grant application, we had chosen to use S5 as the channel for managing user files. However, after learning that the library was going to be rewritten in Rust and that the current Dart version would become obsolete, we decided to switch to IndexD. This choice was made after consulting the foundation’s roadmap, and it has been adapted into the development schedule. We prioritized developing the wallet part in the first few months, using WalletD, which is already functional, as a base.
  • The wallet is completely independent of the vault storage and functions like https://wallet.siacentral.com/. It will have all the features found on Sia wallets and will also allow users to generate a seed using an email and a password as an entry point, making it easier for users to back up their seed.
  • Talking about a marketing campaign here would be an overstatement because it’s really just about encouraging community members to adopt the solution for their operations on the Sia blockchain to make it easier for them to use. This doesn’t require a budget, so we didn’t add it to the project’s budget.

What you should understand is that there is no direct correlation between the wallet and the vault system. In the second phase, once the vault is validated, a billing system will be put in place to allow users to purchase storage space through simple solutions like credit cards or crypto purchases to replicate the same user experience they are used to in Web2. We really wanted to simplify the user journey by not creating two separate applications and by setting up a secure, all-in-one application for users, as these were the main feedback points we received after the release of Dartsia.

4

IIRC The dart version of S5 will get updated to use the rust but you would need to talk to @redsolver on when that would happen, as it would use the flutter rust bridge library.

Both S5 and indexd are valid means of storing data. However, again, you kind of did not address the fact you are pitching use of indexd before it is out… If you are aiming to start on that later, you should make your timeline more explicit with the months.

As for the wallet… you want to create your own web wallet… cool. However, I don’t see how that is connected to a storage app… especially since you said they aren’t related. So, why are you pitching to do R&D on wallet related things for something intended to be managed? I am confused still on your plans there.

Lastly, you state that your eventually going to tackle billing. Is it your long term intention to run a paid, managed service as a business ontop of Sia, or are you only saying that b/c you think its needed to get adoption?

Kudos.

5

I think that in the grant application timeline, the first three months were expressly dedicated to creating the wallet, and the following months to creating the vault. The initial choice remains to use indexd for its production launch, but if the S5 library in Dart is maintained, we will use it initially to have a viable system for users.
Note that at the File Vault level, the majority of the features for media streaming and file encryption had already been created in Dartsia, which is why the timeframe for creating this new app is reduced.

The goal of creating a wallet on the application is to address a problem expressed by several users in the Sia Discord forum, as well as external users who would like to be able to use SC crypto from their mobile without necessarily going through a CEX.

We are considering implementing a billing feature in the future for users who would like to have more storage space than what will be allocated after creating their account. This is mainly to encourage adoption of the system and not to create a lucrative business selling storage space.

Thanks.

6

I think that in the grant application timeline, the first three months were expressly dedicated to creating the wallet, and the following months to creating the vault.

You should put the months themselves in your timeline then as it can be confusing when you intend for things to be done or start.

The goal of creating a wallet on the application is to address a problem expressed by several users in the Sia Discord forum, as well as external users who would like to be able to use SC crypto from their mobile without necessarily going through a CEX.

My personal opinion is im not sure that mixing wallet functions into this project makes much sense… I also think that is something better suited for the core team to tackle which will make sense as a dedicated walletd-like mobile app after the database gets dropped EOY.

Based on that, I feel in whole… this grant may want to just sit for a few months as we are in a very flux situation where 2 important paths to building, both of which will use Sia’s RHP4 protocol internally, are not yet ready. It would not be wise to pitch a project on things not finished or not public.

We are considering implementing a billing feature in the future for users who would like to have more storage space than what will be allocated after creating their account. This is mainly to encourage adoption of the system and not to create a lucrative business selling storage space.

Also, I am not sure if you will need to have the billing feature, if you aren’t trying to become a business as there will be others who can take on that role, and the foundation, based on their roadmap, will run a community service for indexd so that experimentation can be done. But I am glad to see you are thinking about adoption :).

7

Thank you very much for your detailed feedback and guidance.

  • Regarding the timeline, you are absolutely right: we will specify the months in order to make the schedule clearer and avoid any confusion about when phases should start or be delivered.
  • On the wallet aspect, we still believe it is better to have a single “all-in-one” application that serves as a Swiss Army knife (wallet management, storage, contracts, etc.) rather than splitting features across multiple apps. Fragmenting the experience would create longer and more complex user journeys, which could negatively impact adoption.
  • Concerning the timing, we understand that the introduction of RHP4 brings major changes and that it is wise to align with stable technological building blocks. However, we also think it is important to produce something tangible and testable during the development phase, even if this means later adjustments in the underlying technology. This iterative approach will allow the community to experiment, provide feedback, and validate the direction of the project.
  • Finally, regarding billing, this part is still vague in our current reflections. We prefer to first validate adoption of the app’s model before investing further in this feature. We will take the time to develop it more thoroughly later if user adoption justifies it.

In summary, we remain flexible and aligned with the evolution of the ecosystem, while advocating for an integrated and user-centric approach. Our goal is to deliver a rich and accessible mobile experience that can truly drive adoption.

8

So my current opinion is that the wallet shouldn’t be in this grant, and if the grant committee ends up agreeing with that the domino effect is this grant would need to be delayed until you can actually use RHP4 via indexd or S5.

Kudos.

9

To support my point, I would refer to the current version of renterd, which already integrates a wallet. This wallet not only serves to pay for storage fees but also allows sending and receiving operations on the Sia network. We can clearly see that these functionalities coexist perfectly together within one application.

Why then should it not be possible to achieve the same on mobile? Having users switch between multiple different apps for basic operations would create unnecessary friction and risk slowing down adoption. A unified mobile experience — where users can manage both storage and wallet functions seamlessly — is far more likely to drive engagement, especially for newcomers to the Sia ecosystem.

Additionally, the time invested in developing the wallet component will also give us the necessary window to evaluate and decide which underlying storage system (indexd or S5) will ultimately serve as the foundation for the vault. This ensures that while users get a tangible and testable product, we still maintain the flexibility to align with the most stable and future-proof technology stack once it is fully ready.

For these reasons, I remain convinced that it would be a valuable alternative for the Sia community to have a third-party mobile application providing both wallet and storage functionalities in a unified and accessible way.

Really tthanks for all your feedbacks

10

Its fundamentally an issue of scope:

renterd as it stands is a power user application, and in some cases acts as the backend for L2 layers. So the wallet is there because it has to be. Additionally, to-date, that also means holding the full database.

Your previous request was trying to do 2 things in one request and you still seem to be conflating concerns. What I see right now is the following in two theoretical directions:

  • You create an app that offloads management in some way to a 3rd party via indexd/S5. While S5 historically and technically can talk to renterd in the v1 dart, the direction it is going is to support RHPv4 as well to support the further decoupling of the contract management vs uploading.
    • By doing this… a wallet is pretty moot if your not needing to manage your own contracts. And that is the primary purpose of SC on the network.
  • You create an integration targeting renterd, potentially create your own wallet, though you may be creating un-neededly complexity here. Additionally if you do this, assuming its not covered by your prior work… it will remain a power user level tool and not be ready for the direction the ecosystem is moving in.

Creating a wallet assumes that you need the wallet to upload data, and if that is going to get abstracted… and you don’t need to push users to renterd, then the whole idea of a wallet is moot unless you are explicitly targeting power users.

So from my pov, the logic tree is: adding a wallet unneeded, and due to that you would not be able to start on the app because the ecosystem isnt ready for you to build on the needed legos yet.

Kudos.

11

I’d like to clarify a few points and better explain the reasoning behind our approach.

On your first point:
You are right that my previous request combined two things, but to be precise, it was more a case of two distinct applications bundled into the same grant request. That indeed could create confusion. In this new proposal, however, the focus is on a single application with multiple features (Wallet + Storage Vault).

The purpose of including the wallet directly in the same application is not to conflate concerns, but to address a different user problem without requiring a separate grant for a completely new “wallet app.” This way, we create a unified mobile experience for users while remaining efficient with development resources.

Unlike DartSia, which was tied directly to renterd and was primarily aimed at more technical users, this new application explicitly targets support for RHP4 through indexd or S5 making it much more aligned with the ecosystem’s evolution. The wallet and storage features are distinct but complementary, and coexist within the same app to improve usability and adoption.

On your second point:
It’s important to note that our integration does not aim to target renterd directly - I simply used renterd as an illustrative example where wallet and storage functionalities already coexist successfully.

Our previous work on DartSia gave us a lot of insight into the challenges of storage management and, most importantly, the onboarding of new users into Sia. These learnings are what led us to pursue a two-in-one application instead of two separate apps. Splitting them would increase friction, while combining them directly addresses the problems we observed: simplifying the user journey, reducing barriers, and increasing adoption.

12

This is the issue I personally see. I do not see the point of having a user wallet inside or beside a storage app where the contract management would be delegated to a 3rd party, and so the user would not need to use their own SC to upload data.

In case you are not fully understanding, RHP4 enables the separation of contracts and uploading such you can delegate the contract admin to a 3rd party, and just give whats called an EA, which in very simple terms can be seen as a off-chain, prepaid card, that is tied to a specific host. renterd inherently uses EA’s already (it existed in RHP3/Skynet era), and it is how Sia doesn’t need fast block times. But RHP4 enables more, and both indexd and S5 are being made/evolving to support this. The end result is said 3rd party deals with both the crypto and the contracts, so the user doesn’t have to, while staying blind to the data as its no longer proxied, like in renterd.

So, I feel, if you want to pitch creating a wallet app as a grant, and can create something with a USP not filled by what the foundation is creating, that can warrant a separate grant request, IMO.

But I don’t see the point in adding it to a design where it isn’t needed for uploading data. And if isn’t needed, then the whole grant request would start before it can actually be executed.

Kudos.

13

Thanks for your proposal to The Sia Foundation Grants Program.

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

  • The grant is dependent on the success of a software not yet available for use (indexd). This puts you at risk of not being able to meet your milestones, especially if there are any delays in the software release.

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.

14

Hello Rebecca. We have well recieved the committee concern about our proposal. We will be replacing the use of indexd with the use of S5 in its current version in Dart, which is 100% functional and ready for production. We will resubmit another request shortly.

15

No it is not. S5 is will not be fully ready IMO until redsolvers grant is completed. The existing S5 code is legacy and is on its way out. The rust is still in development.

16

Hello @pcfreak30
I just got back from holidays with my teams, hence the late reply. It’s true that the current S5 library will likely be deprecated with the release of the Rust version, but the current version remains robust enough to build applications on it. For example, the Luogo project is currently under construction on it, as well as other projects. In addition, as indicated in the details of @redsolver request for S5 V1, there will be direct compatibility between the current Dart version and the Rust version, making migration easy if necessary.

17

Your misinformed. The redo of S5 is basically a rewrite because the last change went from msgpack to cbor encoding (which kind of wreaks all CID’s and protocol efforts) and the homegrown P2P net is being fully replaced with iroh, keeping s5 at more of an application layer type spec, where S5 primitives are implemented within iroh.

That work is not complete. The original S5 efforts used effectively a gossip P2P system, and yes it was in dart.

If a dart version is made of the current efforts, it will simply be a FFI rust ↔ flutter bridge based wrapper.

I do not know what redsolver exactly plans moving forward, but I have given him feedback as well regarding the JS/rust/dart situation.

Broadly speaking, the v0 S5 is deprecated, and unless someone wants to fork that iteration and evolve it, there wont be maintenance on it, so robust enough to build applications on it is false and just frankly a bad idea.

Kudos.