The problem SkyeKiwi solves

Compare to services like AWS S3, decentralized storage network for blob storage is cheaper, easier to use but not secured because all files are public. We are building a solution as a thin wrapper to the Crust Network, a substrate based storage network, to provide the capacity to securely share and access control a file of any size to any number of people over a public IPFS network. We use the file sealing/unsealing mechanism along with a threshold secret sharing schema and a WASM smart contract to coordinate and access control, and have engineered all the dirty work to a simple to use API that is as simple as

SkyeKiwi.upstream()

&

SkyeKiwi.downstream()

and remains flexible and powerful. Access the SkyeKiwi Protocol at Github Link . A product we are building on top of the SkyeKiwi Protocol is called KiwiSign, it's a secure decentralized DocuSign alternative that take privacy and data ownership on heavy emphasis. It use a kind of mechanism that we called Proof-of-Agreement that leverage some delicate cryptographic way to allow anyone to verify a user's signature of agreement to a contract on chain without knowing any critical and private information of the contract (as demonstrated in the demo video below in more details). And because of the nature of cost for these decentralized storage network, we are able to achieve unmatchable cost & price for centralized counterparts. A PoC UX demo (that is not wired up to logic yet) can be accessible at Link. Please note, it's a dummy demo that does nothing but showcase the interaction we would expect. Lots of the design and stuff are gonna be changed on the final product.

Challenges we ran into

1. Encryption was not fast enough when handling huge files, because the working pipeline is quite long. So we took a few days to really benchmarked a bunch of different crypto libs and settled onto

   tweetnacl

   . Also, reduced all unnecessary parsing by passing chunk data as Uint8Arrays across the project (which means all output generated are mostly contains a bunch of hex string or simply Uint8 numbers... but it does eliminate lots resource wasting on parsing)
2. When building downstream and upstream, it involves serializing and de-serializing a complex struct of metadata. I don't believe this part is perfect yet but we built an ... usable serializing and de-serializing component that works.
3. Work with

   stream

   in Node.js. They are probably the most criticized piece of JavaScript components and a total disaster to mess with, especially when we have a long, complicated and async processing pipeline.
4. Compatibility issues with Polkadot.js, chain types. Pretty much anyone who works with these fast-changing subjects might have also encounter.
5. Contract rent model. I got the rational behind making blockchain state thin but I don't believe the rent model is positively solving that. We run into a corner trying to figure out the correct economic model to work with it for our users, but we cannot. So we switched to Patract and its testnet Jupiter, where rent is set to zero, before a good solution comes around.