In-depth

Intro

In this section we will cover the Fluence JS in-depth.

Fluence

@fluencelabs/fluence exports a facade Fluence which provides all the needed functionality for the most uses cases. It defined 4 functions:
  • start: Start the default peer.
  • stop: Stops the default peer
  • getStatus: Gets the status of the default peer. This includes connection
  • getPeer: Gets the default Fluence Peer instance (see below)
Under the hood Fluence facade calls the corresponding method on the default instance of FluencePeer. This instance is passed to the Aqua-compiler generated functions by default.

FluencePeer class

The second export @fluencelabs/fluence package is FluencePeer class. It is useful in scenarios when the application need to run several different peer at once. The overall workflow with the FluencePeer is the following:
  1. 1.
    Create an instance of the peer
  2. 2.
    Starting the peer
  3. 3.
    Using the peer in the application
  4. 4.
    Stopping the peer
To create a new peer simple instantiate the FluencePeer class:
1
const peer = new FluencePeer();
Copied!
The constructor simply creates a new object and does not initialize any workflow. The start function starts the Aqua VM, initializes the default call service handlers and (optionally) connect to the Fluence network. The function takes an optional object specifying additional peer configuration. On option you will be using a lot is connectTo. It tells the peer to connect to a relay. For example:
1
await peer.star({
2
connectTo: krasnodar[0],
3
});
Copied!
connects to the first node of the Krasnodar network. You can find the officially maintained list networks in the @fluencelabs/fluence-network-environment package. The full list of supported options is described in the API reference
1
await peer.stop();
Copied!

Using multiple peers in one application

The peer by itself does not do any useful work. You should take advantage of functions generated by the Aqua compiler.
If your application needs several peers, you should create a separate FluencePeer instance for each of them. The generated functions accept the peer as the first argument. For example:
1
import { FluencePeer } from "@fluencelabs/fluence";
2
import {
3
registerSomeService,
4
someCallableFunction,
5
} from "./_aqua/someFunction";
6
7
async function main() {
8
const peer1 = new FluencePeer();
9
const peer2 = new FluencePeer();
10
11
// Don't forget to initialize peers
12
await peer1.start({
13
connectTo: relay,
14
});
15
await peer2.start({
16
connectTo: relay,
17
});
18
19
// ... more application logic
20
21
// Pass the peer as the first argument
22
// ||
23
// \/
24
registerSomeService(peer1, {
25
handler: async (str) => {
26
console.log("Called service on peer 1: " str);
27
},
28
});
29
30
// Pass the peer as the first argument
31
// ||
32
// \/
33
registerSomeService(peer2, {
34
handler: async (str) => {
35
console.log("Called service on peer 2: " str);
36
},
37
});
38
39
// Pass the peer as the first argument
40
// ||
41
// \/
42
await someCallableFunction(peer1, arg1, arg2, arg3);
43
44
45
await peer1.stop();
46
await peer2.stop();
47
}
48
49
// ... more application logic
Copied!
It is possible to combine usage of the default peer with another one. Pay close attention to which peer you are calling the functions against.
1
// Registering handler for the default peerS
2
registerSomeService({
3
handler: async (str) => {
4
console.log("Called against the default peer: " str);
5
},
6
});
7
8
// Pay close attention to this
9
// ||
10
// \/
11
registerSomeService(someOtherPeer, {
12
handler: async (str) => {
13
console.log("Called against the peer named someOtherPeer: " str);
14
},
15
});
Copied!

Understanding the Aqua compiler output

Aqua compiler emits TypeScript or JavaScript which in turn can be called from a js-based environment. The compiler outputs code for the following entities:
  1. 1.
    Exported func declarations are turned into callable async functions
  2. 2.
    Exported service declarations are turned into functions which register callback handler in a typed manner
  3. 3.
    For every exported service the compiler generated it's interface under the name {serviceName}Def

Function definitions

For every exported function definition in aqua the compiler generated two overloads. One accepting the FluencePeer instance as the first argument, and one without it. Otherwise arguments are the same and correspond to the arguments of aqua functions. The last argument is always an optional config object with the following properties:
  • ttl: Optional parameter which specify TTL (time to live) of particle with execution logic for the function
The return type is always a promise of the aqua function return type. If the function does not return anything, the return type will be Promise<void>.
Consider the following example:
1
func myFunc(arg0: string, arg1: string):
2
-- implementation
Copied!
The compiler will generate the following overloads:
1
export async function myFunc(
2
arg0: string,
3
arg1: string,
4
config?: { ttl?: number }
5
): Promise<void>;
6
7
export async function callMeBack(
8
peer: FluencePeer,
9
arg0: string,
10
arg1: string,
11
config?: { ttl?: number }
12
): Promise<void>;
Copied!

Service definitions

1
service ServiceName:
2
-- service interface
Copied!
For every exported service declaration the compiler will generate two entities: service interface under the name {serviceName}Def and a function named register{serviceName} with several overloads. First let's describe the most complete one using the following example:
1
export interface ServiceNameDef {
2
//... service function definitions
3
}
4
5
export function registerServiceName(
6
peer: FluencePeer,
7
serviceId: string,
8
service: ServiceNameDef
9
): void;
Copied!
  • peer - the Fluence Peer instance where the handler should be registered. The peer can be omitted. In that case the default Fluence Peer will be used instead
  • serviceId - the name of the service id. If the service was defined with the default service id in aqua code, this argument can be omitted.
  • service - the handler for the service.
Depending on whether or not the services was defined with the default id the number of overloads will be different. In the case it is defined, there would be four overloads:
1
// (1)
2
export function registerServiceName(
3
//
4
service: ServiceNameDef
5
): void;
6
7
// (2)
8
export function registerServiceName(
9
serviceId: string,
10
service: ServiceNameDef
11
): void;
12
13
// (3)
14
export function registerServiceName(
15
peer: FluencePeer,
16
service: ServiceNameDef
17
): void;
18
19
// (4)
20
export function registerServiceName(
21
peer: FluencePeer,
22
serviceId: string,
23
service: ServiceNameDef
24
): void;
Copied!
  1. 1.
    Uses default Fluence Peer and the default id taken from aqua definition
  2. 2.
    Uses default Fluence Peer and specifies the service id explicitly
  3. 3.
    The default id is taken from aqua definition. The peer is specified explicitly
  4. 4.
    Specifying both peer and the service id.
If the default id is not defined in aqua code the overloads will exclude ones without service id:
1
// (1)
2
export function registerServiceName(
3
serviceId: string,
4
service: ServiceNameDef
5
): void;
6
7
// (2)
8
export function registerServiceName(
9
peer: FluencePeer,
10
serviceId: string,
11
service: ServiceNameDef
12
): void;
Copied!
  1. 1.
    Uses default Fluence Peer and specifies the service id explicitly
  2. 2.
    Specifying both peer and the service id.

Service interface

The service interface type follows closely the definition in aqua code. It has the form of the object which keys correspond to the names of service members and the values are functions of the type translated from aqua definition (see Type convertion). For example, for the following aqua definition:
1
service Calc("calc"):
2
add(n: f32)
3
subtract(n: f32)
4
multiply(n: f32)
5
divide(n: f32)
6
reset()
7
getResult() -> f32
Copied!
The typescript interface will be:
1
export interface CalcDef {
2
add: (n: number, callParams: CallParams<"n">) => void | Promise<void>;
3
subtract: (n: number, callParams: CallParams<"n">) => void | Promise<void>;
4
multiply: (n: number, callParams: CallParams<"n">) => void | Promise<void>;
5
divide: (n: number, callParams: CallParams<"n">) => void | Promise<void>;
6
reset: (callParams: CallParams<null>) => void | Promise<void>;
7
getResult: (callParams: CallParams<null>) => number | Promise<number>;
8
}
Copied!
CallParams will be described later in the section

Type conversion

Basic types conversion is pretty much straightforward:
  • string is converted to string in typescript
  • bool is converted to boolean in typescript
  • All number types (u8, u16, u32, u64, s8, s16, s32, s64, f32, f64) are converted to number in typescript
Arrow types translate to functions in typescript which have their arguments translated to typescript types. In addition to arguments defined in aqua, typescript counterparts have an additional argument for call params. For the majority of use cases this parameter is not needed and can be omitted.
The type conversion works the same way for service and func definitions. For example a func with a callback might look like this:
1
func callMeBack(callback: string, i32 -> ()):
2
callback("hello, world", 42)
Copied!
The type for callback argument will be:
1
callback: (arg0: string, arg1: number, callParams: CallParams<'arg0' | 'arg1'>) => void | Promise<void>,
Copied!
For the service definitions arguments are named (see calc example above)

Using asynchronous code in callbacks

Typescript code generated by Aqua compiler has two scenarios where a user should specify a callback function. These are services and callback arguments of function in aqua. If you look at the return type of the generated function you will see a union of callback return type and the promise with this type, e.g string | Promise<string>. Fluence-js supports both sync and async version of callbacks and figures out which one is used under the hood. The callback be made asynchronous like any other function in javascript: either return a Promise or mark it with async keyword to take advantage of async-await pattern.
For example:
1
func withCallback(callback: string -> ()):
2
callback()
3
4
service MyService:
5
callMe(string)
Copied!
Here we are returning a promise
1
registerMyService({
2
callMe: (arg): Promise<void> => {
3
return new Promise((resolve) => {
4
setTimeout(() => {
5
console.log("I'm running 3 seconds after call");
6
resolve();
7
}, 3000);
8
});
9
},
10
});
Copied!
And here we are using async-await pattern
1
await withCallback(async (arg) => {
2
const data = await getStuffFromDatabase(arg);
3
console.log("");
4
});
Copied!

Call params and tetraplets

Each service call is accompanied by additional information specific to Fluence Protocol. Including initPeerId - the peer which initiated the particle execution, particle signature and most importantly security tetraplets. All this data is contained inside the last callParams argument in every generated function definition. These data is passed to the handler on each function call can be used in the application.
Tetraplets have the form of:
1
{
2
argName0: SecurityTetraplet[],
3
argName1: SecurityTetraplet[],
4
// ...
5
}
Copied!
To learn more about tetraplets and application security see Security
To see full specification of CallParams type see API reference

Signing service

Signing service is useful when you want to sign arbitrary data and pass it further inside a single aqua script. Signing service allows to restrict its usage for security reasons: e.g you don't want to sign anything except it comes from a trusted source. The aqua side API is the following:
1
data SignResult:
2
-- Was call successful or not
3
success: bool
4
-- Error message. Will be null if the call is successful
5
error: ?string
6
-- Signature as byte array. Will be null if the call is not successful
7
signature: ?[]u8
8
9
-- Available only on FluenceJS peers
10
-- The service can also be resolved by it's host peer id
11
service Sig("sig"):
12
-- Signs data with the private key used by signing service.
13
-- Depending on implementation the service might check call params to restrict usage for security reasons.
14
-- By default signing service is only allowed to be used on the same peer the particle was initiated
15
-- and accepts data only from the following sources:
16
-- trust-graph.get_trust_bytes
17
-- trust-graph.get_revocation_bytes
18
-- registry.get_key_bytes
19
-- registry.get_record_bytes
20
-- registry.get_host_record_bytes
21
-- Argument: data - byte array to sign
22
-- Returns: signature as SignResult structure
23
sign(data: []u8) -> SignResult
24
25
-- Given the data and signature both as byte arrays, returns true if the signature is correct, false otherwise.
26
verify(signature: []u8, data: []u8) -> bool
27
28
-- Gets service's public key.
29
get_pub_key() -> string
Copied!
FluenceJS ships the service implementation as the JavaScript class:
1
/**
2
* Whether signing operation is allowed or not.
3
* Implemented as a predicate of CallParams.
4
*/
5
export type SigSecurityGuard = (params: CallParams<"data">) => boolean;
6
7
export class Sig implements SigDef {
8
private _keyPair: KeyPair;
9
10
constructor(keyPair: KeyPair) {
11
this._keyPair = keyPair;
12
}
13
14
/**
15
* Security guard predicate
16
*/
17
securityGuard: SigSecurityGuard;
18
19
/**
20
* Gets the public key of KeyPair. Required by aqua
21
*/
22
get_pub_key() {
23
// implementation ommited
24
}
25
26
/**
27
* Signs the data using key pair's private key. Required by aqua
28
*/
29
async sign(
30
data: number[],
31
callParams: CallParams<"data">
32
): Promise<SignResult> {
33
// implementation ommited
34
}
35
36
/**
37
* Verifies the signature. Required by aqua
38
*/
39
verify(signature: number[], data: number[]): Promise<boolean> {
40
// implementation ommited
41
}
42
}
Copied!
securityGuard specifies the way the sign method checks where the incoming data is allowed to be signed or not. It accepts one argument: call params (see "Call params and tetraplets") and must return either true or false. Any predicate can be specified. Also, FluenceJS is shipped with a set of useful predicates:
1
/**
2
* Only allow calls when tetraplet for 'data' argument satisfies the predicate
3
*/
4
export const allowTetraplet = (pred: (tetraplet: SecurityTetraplet) => boolean): SigSecurityGuard => {/*...*/};
5
6
/**
7
* Only allow data which comes from the specified serviceId and fnName
8
*/
9
export const allowServiceFn = (serviceId: string, fnName: string): SigSecurityGuard => {/*...*/};
10
11
/**
12
* Only allow data originated from the specified json_path
13
*/
14
export const allowExactJsonPath = (jsonPath: string): SigSecurityGuard => {/*...*/};
15
16
/**
17
* Only allow signing when particle is initiated at the specified peer
18
*/
19
export const allowOnlyParticleOriginatedAt = (peerId: PeerIdB58): SigSecurityGuard => {/*...*/};
20
21
/**
22
* Only allow signing when all of the predicates are satisfied.
23
* Useful for predicates reuse
24
*/
25
export const and = (...predicates: SigSecurityGuard[]): SigSecurityGuard => {/*...*/};
26
27
/**
28
* Only allow signing when any of the predicates are satisfied.
29
* Useful for predicates reuse
30
*/
31
export const or = (...predicates: SigSecurityGuard[]): SigSecurityGuard => {/*...*/};
32
};
Copied!
Predicates as well as the Sig definition can be found in @fluencelabs/fluence/dist/services
Sig class is accompanied by registerSig which allows registering different signing services with different keys. The mechanism is exactly the same as with ordinary aqua services e.g:
1
// create a key per from pk bytes
2
const customKeyPair = await KeyPair.fromEd25519SK(pkBytes);
3
4
// create a signing service with the specific key pair
5
const customSig = new Sig(customKeyPair);
6
7
// restrict sign usage to our needs
8
customSig.securityGuard = allowServiceFn("my_service", "my_function");
9
10
// register the service. Please note, that service id ("CustomSig" here) has to be specified.
11
registerSig("CustomSig", customSig);
Copied!
for a non-default peer, the instance has to be specified:
1
const peer = new FluencePeer();
2
await peer.start();
3
4
// ...
5
6
registerSig(peer, "CustomSig", customSig);
Copied!
FluencePeer ships with the default signing service implementation, registered with id "Sig". Is is useful to work with TrustGraph and Registry API. The default implementation has the following restrictions on the sign operation:
  • Only allowed to be used on the same peer the particle was initiated
  • Restricts data to following services:
    • trust-graph.get_trust_bytes
    • trust-graph.get_revocation_bytes
    • registry.get_key_bytes
    • registry.get_record_bytes
    • Argument: data - byte array to sign
The default signing service class can be accessed in the following way:
1
// for default FluencePeer:
2
const sig = Fluence.getPeer().getServices().sig;
3
4
// for non-default FluencePeer:
5
// const peer = FluencePeer();
6
// await peer.start()
7
const sig = peer.getServices().sig;
8
9
// change securityGuard for the default service:
10
sig.securityGuard = or(
11
sig.securityGuard,
12
allowServiceFn("my_service", "my_function")
13
);
Copied!

Using Marine services in Fluence JS

Fluence JS can host Marine services with Marine JS. Currently only pure single-module services are supported.
Before registering the service corresponding WASM file must be loaded. Fluence JS package exports three helper functions for that.

loadWasmFromFileSystem

Loads the WASM file from file system. It accepts the path to the file and returns buffer compatible with FluencePeer API.
This function can only be used in nodejs. Trying to call it inside browser will result throw an error.
loadWasmFromNpmPackage
Locates WASM file in the specified npm pacakge and loads it. The function accepts two arguments:
  • Name of npm package
  • Path to WASM file relative to the npm package
This function can only be used in nodejs. Trying to call it inside browser will result throw an error.

loadWasmFromServer

Loads WASM file from the service hosting the application. It accepts the file path on server and returns buffer compatible with FluencePeer API.
The function will try load file into SharedArrayBuffer if the site is cross-origin isolated.
Otherwise the return value fall backs to Buffer which is less performant but is still compatible with FluencePeer API.
We strongly recommend to set-up cross-origin headers. For more details see: See MDN page for more info
This function can only be used in browser. Trying to call it inside nodejs will result throw an error.

Registering services in FluencePeer

After the file has been loaded it can be registered in FluencePeer. To do so use registerMarineService function.
To remove service use registerMarineService function.
You can pick any unique service id. Once the service has been registered it can be referred in aqua code by the specified id
For example:
1
import { Fluence, loadWasmFromFileSystem } from '@fluencelabs/fluence';
2
3
async function main()
4
await Fluence.start({connectTo: relay});
5
6
const path = path.join(__dirname, './service.wasm');
7
const service = await loadWasmFromFileSystem(path);
8
9
// to register service
10
await Fluence.registerMarineService(service, 'my_service_id');
11
12
// to remove service
13
Fluence.removeMarineService('my_service_id');
14
}
Copied!