Inspiration

There has been a lack of innovation in the content sharing space since the advent of BitTorrent. With the emergence of new browser-based technologies such as the File System Access API, WebAssembly and Web3 SDKs, there is an opportunity to build an innovative and fully decentralized product in this space while leveraging the Solana blockchain. Content providers have been searching for a way to reach audiences they can monetize without relying on a centralized platform. Privacy conscious users have been unable to transfer large files securely in an easy manner, without having a 3rd party service analyzing their data. Casual users do not want to install 3rd party software to discover content. These concerns are the genesis of Enclave, which is solving these problems in large part thanks to the speed and low transaction fee nature of Solana.

What it does

Enclave is a content sharing platform and protocol with stablecoin-based payments for direct p2p transmission of content via browser-based WebRTC. On the platform, "Users" can peruse the content listing of available "Providers" before opening a channel to exchange payment and transfer data. It is important to note that in contrast to content-agnostic file sharing networks like BitTorrent/IPFS, Enclave is highly content focused and data transfers only occur when the smart contract conditions have been met between the user and provider for any particular file.

How it's built

In contrast to the overwhelming majority of React based Solana dApps, Enclave is built using Vue.js. The ease of this framework allowed for rapid prototyping such that the work could be focused on the business logic of the protocol, and less on building frontend components. Enclave makes use of a few browser tricks involving service workers to allow WebRTC datachannels to be used as a source for file downloads, without bloating up the browser memory when transferring large files.

Challenges

One of the many challenges faced was getting all the required data to fit in a single transaction. Requiring users to sign multiple transactions is not a great user experience, so extra effort was made to squeeze out every byte, such that a single transaction could hold all the necessary account data in addition to the WebRTC signaling data. As with many engineering challenges, adding extra layers of abstraction is often quite fruitful when solving problems in a complex system.

What's next for enclave

  • Encryption of signaling data
  • Using IPFS to serve the file manifest, allowing for an infinitely scalable and searchable content share.
  • Expand manifest to include more metadata such as descriptions, screenshots, etc.
  • Native client in a compiled language (rust/go)
  • For particularly large providers, a "load balancer" component that can distribute the download request load to more than one physical machine.
  • Establish community-run frontends of Enclave, to bolster censorship resistance.

Built With

Share this project:

Updates