Download Now!

SHARU

fully decentralized, post-cloud, unstoppable, censorfree, trustless, encrypted, anonymous filesharing

Share your files, trust no one. Sharu is filesharing for all hackers, dissidents, leakers, anarchists. Filesharing for

YOU!

TL;DR

Wall of Text

Sharu is build upon IPFS, Ethereum, RSA, AES and ECC crypto. Sharu runs locally as an electron app. There is no backend server.
As your files are distributed via IPFS your machine has to be online to allow others to download your shared files. To allow sharing with your machine offline, you can setup a pinning server to distribute your files.
Every Sharu folder is AES-GCM 256 encrypted with secure random Keys. These keys are RSA-OAEP 2048 encrypted. Your RSA key is encrypted with the key of an Ethereum Wallet. This key is stored encrypted inside the app, with a password you choose. The encrypted AES and RSA keys are stored in IPFS, you can export your Ethereum Wallet key anytime as a mnemonic. So you can easily log in on different machines. Currently we use a Kaleido permissioned blockchain, to store what is shared with who. Transactions are free.

TRY IT!

Right now, Sharu is not more than a technical proof of concept, but even now some things already work so you might get the idea why we think we should work on this thing to make it a fully usable product.

Feel free to try it out - currently people have used sharu so far, shares have been produced.

We do offer prebuild binarys but you can also checkout the sources and build it for yourself.
Download Now!
Linux build
Download Now!
Windows build
Download Now!
OS X build
We are happy if you share your feedback/bugs as an email or open an issue at github

LIMITATIONS

It is probably easier to list what is already working ;-)

  • Sharing of small files (some MB) is already working quite good. Big files do work in LAN, but due to the absence of high bandwith of upstream in standard environments it does not spark joy when you try to share the last season of game of thrones with your friends.
  • Receivers of a share can only download files as long as the publisher has her sharu-application running. We plan to release some basic image/docker-container/whatever to proxy your content using a raspberry pi or something else, but the current implementation is even more prebeta than the sharu application itself is.
  • Each share does have exactly one owner, multiple contributors to a share is not implemented yet. We already know how to add this feature, but as long as we struggle with more fundamental issues we are not adding any features.
  • You can export your account to different machines, nevertheless you can only edit a share from the sharu-application the share was initially created. This is also solveable, but the implementation remains untouched as long we have fundamental issues to be solved
  • All files are encrypted and only decryptable by exactly the users you want. The file- and foldernames are NOT. Again, solveable - but not at the top of our Todo-List.
  • FAQ

    Q: Is it really decentralized, unstoppable, censorfree as long as you are using a permissioned chain like Kaleido?
    A: That's right - it is not! But right now usability is more important - we don't want our users to think about transaction-costs and FIAT-to-crypto-conversion. Moving to the main-net or something similar is going to happen at some point (probably in 2020 with PoS or with some kind of side-chain).

    Q: Why is looking up shares and downloading files so slow?
    A1: We are still in the process of crunching numbers and use hyper-parameter-optimization to find the right setup of the ipfsd running inside the application.
    A2: Although all running Sharu-applications try to relay the meta-data of all existing shares, this is still pretty basic and some better concept like sharding needs to be implemented.

    Q: If you want to attach "trustless" to this, why isn't this opensource?
    A: To be honest: we are full of shame about the quality of the code. 2 of the 3 developers of Sharu left the path of professional software development several years ago and got in touch with typescript and solidity for the first time with this project. Nevertheless, this will be opensource at some point and we would be happy if it is not only the three of us spending our free nights working on this thing.
    UPDATE: As everybody knows 2/3 of us are very good in doing bad code, we felt there is no real problem. Voila: here is the desktop-application

    Q: Why don't you use metamask as the integration with the ethereum stack?
    A: At first we did, but we think people don't want to add plugins, create wallets and do all the other things cryptonerds like to to. ethers.js works fine right now.

    WHAT'S NEXT?

    There is TONS of stuff to do, this is a non-exclusive list of things we want to achieve in the future

  • This needs to be opensource. Not only because we believe people do not trust compiled code, but also because we cannot bring this thing to its final state with our own free time.
  • Stability: it is far from being stable. We spent days of trying to use ipfs right (and played both with go-ipfs and js-ipfs) and are totally not happy with the current state
  • Relaying: Of course it is not acceptable that a Sharu-instance needs to run for accessing files - we already started working on off-the-shelf pinning services you can add to a local machine (running in your basement on a raspberry pi or a NAS) or at a VM/HW at your favourite provider.
  • Collaboration: shares should be writeable by multiple partys.
  • Multi-instance: use your Sharu-account on different machines.
  • Mobile: at least a read-only-version of the shares you can access should be there for your cellphone.
  • Webonly: we started Sharu as a web-only-application but needed to switch to electron as we could not find a userfriendly way to integrate with a locally running IPFS-node. Removing the need to install an application is still a nice thing we would like to have
  • OS-Integration: mount shares into your OS the same way as you mount NFS or SMB.
  • Permissioned/Non-permissioned blockchain: using Kaleido gave us a lot of benefits, but this cannot be the final state.
  • Encryption: there is still some stuff not encrypted: filenames, foldernames, the wallets of the people allowed to access a share.
  • Migrateability: Moving away from Kaleido currently means that we create a split-brain and all already created content is lost.
  • Transactions: right now the application fires transactions into the blockchain with every single change. This is fine with a PoA-chain, but most probably not for something else
  • Maintaining the state: we aren't even sure if using a blockchain to decentralized maintain the state (e.g.: mapping shares to ipfs) is the right way. Maybe we find something better. ;)
  • JOIN TEH PARTY!

    Don't hesitate to share your thoughts at github