GitBook: [#260] update dead tetraplets link

knowledge_security.md

@@ -153,6 +153,6 @@ This makes decomposition a pain: why decouple services if we need them to know s
 
 **References**
 
-* [Tetraplet implementation in the Aquamarine interpreter](https://github.com/fluencelabs/aquamarine/blob/master/crates/polyplets/src/tetraplet.rs)
+* [Tetraplet implementation in the Aquamarine interpreter](https://github.com/fluencelabs/aquavm/blob/master/crates/air-lib/polyplets/src/tetraplet.rs)
 * [Example of checking tetraplets for authorization in Fluent Pad](https://github.com/fluencelabs/fluent-pad/blob/main/services/history-inmemory/src/service\_api.rs#L91)
 * [Getting tetraplets with Rust SDK](https://github.com/fluencelabs/marine-rs-sdk/blob/7c8f65fb64e64ba7e068b124449e745ef28c742d/sdk/src/call\_parameters.rs#L35)

quick-start/3.-browser-to-service.md

@@ -17,7 +17,7 @@ npm start
 
 Which will open a new browser tab at `http://localhost:3000` . Following the instructions, we connect to any one of the displayed relay ids, open another browser tab also at `http://localhost:3000`, select a relay and copy and paste the client peer id and relay id into corresponding fields in the first tab and press the `say hello` button.
 
-![Browser To Service Implementation](<../.gitbook/assets/image (38) (2) (2) (2) (1).png>)
+![Browser To Service Implementation](<../.gitbook/assets/image (38) (1) (1).png>)
 
 The result looks familiar, so what's different? Let's have a look at the Aqua file. Navigate to the `aqua/getting_started.aqua` file in your IDE or terminal:
 
@@ -30,13 +30,13 @@ And let's work it from the top:
 * Specify the `HelloWorld` struct interface binding (6-8) for the hosted service from the `marine aqua` export
 * Specify the `HelloWorld` interface and function binding (11-12) for the hosted service from the `marine aqua` export
 * Specify the `HelloPeer` interface and function binding (15-16) for the local service
-* Create the Aqua workflow function `sayHello`  (18-29)
+* Create the Aqua workflow function `sayHello` (18-29)
 
 Before we dive into the `sayHello` function, let's look at why we still need a local service even though we deployed a hosted service. The reason for that lies in the need for the browser client to be able to consume the message sent from the other browser through the relay peer. With that out of the way, let's dig in:
 
-* The function signature (18) takes two arguments: `targetPeerId`, which is the client peer id of the other browser and  the `targetelayPeerId`, which is the relay id -- both parameters are the values  you copy and pasted from the second browser tab into the first browser tab
+* The function signature (18) takes two arguments: `targetPeerId`, which is the client peer id of the other browser and the `targetelayPeerId`, which is the relay id -- both parameters are the values you copy and pasted from the second browser tab into the first browser tab
 * The first step is to call on the hosted service `HelloWorld` on the host peer `helloWorldPeerId` , which we specified in line 1
-  * We bind the `HelloWorld` interface, on the  peer `helloWorldPeerId`, i.e.,`12D3KooWFEwNWcHqi9rtsmDhsYcDbRUCDXH84RC4FW6UfsFWaoHi`, to the  service id of the hosted service `helloWorldServiceId` , i.e. `1e740ce4-81f6-4dd4-9bed-8d86e9c2fa50`, which takes the %init\_\_peer\_\_id%  parameter, i.e., the peer id of the peer that initiated the request, and pushes the result into `comp`  (20-22)
+  * We bind the `HelloWorld` interface, on the peer `helloWorldPeerId`, i.e.,`12D3KooWFEwNWcHqi9rtsmDhsYcDbRUCDXH84RC4FW6UfsFWaoHi`, to the service id of the hosted service `helloWorldServiceId` , i.e. `1e740ce4-81f6-4dd4-9bed-8d86e9c2fa50`, which takes the %init\_\_peer\_\_id% parameter, i.e., the peer id of the peer that initiated the request, and pushes the result into `comp` (20-22)
   * We now want to send a result back to the target browser (peer) (25-26) using the local service via the `targetRelayPeerId` in the background as a `co` routine.
   * Finally, we send the `comp` result to the initiating browser