The Fluence Labs Developer Hub

Welcome to the Fluence Labs developer hub. You'll find comprehensive guides and documentation to help you start working with Fluence Labs as quickly as possible, as well as support if you get stuck. Let's jump right in!

Should you have any questions, feel free to join our Discord or Telegram!

Get Started

This documentation represents the overview of the Fluence project, describes its essential parts and how to use it.

What is Fluence?

Fluence is an open application platform powered by peer-to-peer computing protocol and a decentralized licensing system. Fluence enables developers to host applications in the decentralized network and collaborate on live applications, reusing components and data. The protocol creates an open marketplace of compute capacity, so availability and pricing are not controlled by a single company and instead are driven by competitive market forces.

Applications are faster to build, easier to integrate, and more secure due to the enhanced composability. Business logic is incorporated into data packets orchestrating the execution of distributed components. Just as code collaboration creates better products, composition via network protocol enables live apps to be forked, expanded, or re-arranged into new and enhanced user experiences.

Fluence uses blockchain to enable a new software business model. Application dependencies are globally available and secured on-chain, and authors can earn when their applications or components are used in the network. The hosting payments are coupled with the author rewards, so the more popular a component is in the network, the more revenue for hosts and authors.

How Fluence works

The Network
The Fluence network is a distributed, peer-to-peer network that is intended to run applications. Peers participate in different ways: they communicate over secure channels to transfer requests and responses, relay messages, discover other peers, maintain connectivity. Peers use the Fluence’s DHT, a network-wide shared state based on Kademlia algorithm, to find, choose, and connect to other peers.

Open Applications
Applications are constructed as a set of distributed services (analogy to microservices) run by different peers and composition scripts managing the execution across peers. There is no separation on private and public network environments, all services are exposed to the public network and their communication is secured by the protocol. That’s why integrating applications is as easy as composing a set of existing services into new business logic. Read more about the execution model.

Services
Each service is a set of WebAssembly modules linked together and run on some peer in the network. Modules that compose a service can call external programs, access filesystem, and preserve state over time or be completely stateless. Services are described by and deployed from blueprints, i.e. configurations of module sets the services consist of.

Fluence nodes
Fluence nodes provide computation resources for the applications deployed to the network and collect payments for this. Nodes run services via the Webassembly runtime called Fluence Compute Engine, which executes each service as the inter-linked set of Wasm modules. Nodes may provide additional services external to the Fluence network (i.e. IPFS node, Ethereum node, AWS API, etc). These services are connected to services via effector modules and therehow available from the applications on Fluence. Learn here how to run a node.

Aquamarine
Aquamarine is a composition layer for services that simplifies describing application business logic with the new non-Turing complete programming language. Scripts written in Aquamarine interact with distributed services by calling functions from their APIs and pass data between peers. It is possible to call several services in parallel, pass results to other services, and forward data to any peer, to a client.

The Aquamarine Intermediary Representation (AIR) is a Lisp-style low-level implementation of Aquamarine. The higher-level language compiled to AIR is in development.

Trust Graph
The network-wide peer relationship layer is used to manage connectivity and permissions. Peers keep the distributed graph of relationships, similar to Web of Trust, which is used to prioritize connections from known peers and avoid eclipse attacks. Also, TrustGraph may be used at the application level in various ways such as prioritization of service execution on authorized peers or a tighter connection of a single company’s peers.

Licensing System (soon)
Application components that run on Fluence are available for reuse freely but come with mandatory royalty to their authors. Each author may define periods and fees that have to be paid when a service or module is being used as a dependency of another application. License fees are taken in favor of the author from payments for hosting to a Fluence network node.

Application dependencies and license terms are stored in a blockchain, and the network nodes enforce the rules and check payments.

Learn more

  • Protocol Paper, a general overview of the Fluence protocol
  • Introducing Aquamarine, a talk by Dmitry Kurinskiy about Aquamarine and the composition from the Phase 1 Launch event
  • Fluence Compute Engine, a talk by Mike Voronov about the Fluence Webassembly runtime that runs services
  • Fluence Demo talk, where Dmitry Kurinskiy demonstrates open application examples at the Phase 1 Launch event

Contribute

All of the core components of the Fluence network and protocol are open-source and permissively licensed, so we welcome contributions from community members. While the protocol is still in the development phase, the network is launched and you can start building applications on it. The best way to start is to run a Fluence node.

Feel free to dig into the code repositories and open your first issue on Github.

Reach out to the core developers team in the Telegram group with any questions, or subscribe to the newsletter and join the developer community calls.

Updated 6 months ago

Overview


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.