-

Author: ZaouiAmine

content/posts/add-llm-to-your-cloud.md

@@ -26,7 +26,7 @@ In this article, I'll go over how to use the LLM (or GPT) capabilities of [tauby
 A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it's [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte's terminology) LLM features.
 
 ## LLAMA SDK
-Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
+Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
 
 ## Get Ready
 Before proceeding, let's ensure you have a project and a DFunction ready to go. If not, please refer to ["Create a Function"](https://tau.how/guides/build/02-guide/02-create-a-dfunc/).
@@ -147,9 +147,7 @@ package lib
 
 import (
 	"github.com/taubyte/go-sdk/event"
-  "github.com/samyf
-
-odil/taubyte-llama-satellite/sdk"
+  "github.com/samyfodil/taubyte-llama-satellite/sdk"
   "io"
 )
 

content/posts/add-llm-to-your-project.md

@@ -25,7 +25,7 @@ In this article, I'll go over how to use the LLM (or GPT) capabilities of [tauby
 A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it's [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte's terminology) LLM features.
 
 ## LLAMA SDK
-Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
+Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
 
 ## Get Ready
 Before proceeding, let's ensure you have a project and a DFunction ready to go. If not, please refer to ["Create a Function"](https://tau.how/guides/build/02-guide/02-create-a-dfunc/).
@@ -146,9 +146,7 @@ package lib
 
 import (
 	"github.com/taubyte/go-sdk/event"
-  "github.com/samyf
-
-odil/taubyte-llama-satellite/sdk"
+  "github.com/samyfodil/taubyte-llama-satellite/sdk"
   "io"
 )
 

content/posts/be-competitive-in-few-minutes.md

@@ -136,7 +136,7 @@ $ curl https://get.tau.link/tau | sh
 > It's worth noting that a single host can support multiple nodes, provided their ports do not overlap. However, for the purposes of this guide, we will maintain a one-node-per-host configuration.
 
 Upon successful installation, you should see an output similar to the following:
-```
+```bash
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload   Total   Spent    Left  Speed
 100  3982  100  3982    0     0   3962      0  0:00:01  0:00:01 --:--:--  3966
@@ -156,7 +156,7 @@ The configuration process for a node is straightforward and can be executed with
 ```sh
 $ sudo tau config generate -n enterprise.starships.ws \
       -s compute --protos all --ip 34.133.173.124 \
-      --dv --swarm 
+      --dv --swarm
 ```
 
 Here's a quick rundown of the options used:
@@ -170,7 +170,7 @@ Here's a quick rundown of the options used:
 > Note: It's generally not advisable to enable all protocols on a single node due to potential conflicts and resource constraints. This article simplifies the setup for demonstration purposes. Adjustments to the protocol configuration can easily be made with a single command, which we will explore in future discussions.
 
 Upon successful configuration, you'll receive the node's ID as confirmation:
-```
+```bash
 [INFO] ID: 12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY
 ```
 
@@ -218,7 +218,6 @@ domains:
 plugins: {}
 ```
 > Should the location be inaccurately determined, you have the option to correct it manually.
-
 The final step involves validating the configuration to ensure its accuracy and completeness:
 ```sh
 $ sudo tau conf validate -s compute
@@ -284,7 +283,7 @@ $ sudo systemctl status tau@compute
 ```
 
 You should see output similar to the following, indicating that the `tau@compute` service is active and running:
-```
+```bash
 ● tau@compute.service - Taubyte Tau Service Running compute
      Loaded: loaded (/lib/systemd/system/tau@.service; enabled; vendor preset: enabled)
      Active: active (running) since Fri 2024-02-09 22:43:52 UTC; 1min 5s ago
@@ -352,6 +351,7 @@ You'll be prompted to enter a password for the encryption:
 ```txt
 Password?
 ```
+
 > Remember this password; it's crucial for the subsequent steps.
 
 The exported configuration will resemble the following (omit the `location` to let it be automatically determined for the other nodes):
@@ -422,12 +422,12 @@ With the template and necessary preparations in place, proceed to configure the
 - **For the Second Host:**
     ```sh
     $ sudo tau config gen --ip 34.130.131.76 --use compute.tmpl.yaml  --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY
-    ```
+```
 
 - **For the Third Host:**
     ```sh
     $ sudo tau config gen --ip 35.235.122.141 --use compute.tmpl.yaml  --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY
-    ```
+```
 
 Important considerations:
 - Utilize the correct IP addresses for each host.
@@ -468,7 +468,7 @@ Running a DNS lookup should now reflect all active hosts:
 ![](/blog/images/slimdig-all-seer-tau-ent-starships-ws.png)
 
 - **For the Generated Domain:** Delegate the specified subdomain to your cloud by adding the appropriate `NS` entry, enhancing domain management and flexibility.
-![](/iamges/add-ns-entry-s-ftll-ink.png)
+![](/blog/images/add-ns-entry-s-ftll-ink.png)
 
 ### Bootstrapping for Recovery and Expansion
 Ensure all nodes are aware of each other to facilitate network resilience and data consistency:
@@ -495,7 +495,7 @@ To extend our cloud's reach, we proceed to configure the additional nodes with p
 - **On the Third Host**:
   ```sh
   $ sudo tau config gen --ip 35.235.122.141 --use compute.tmpl.yaml  --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY
-  ```
+```
 
 **Important**: Use the correct IP addresses for each host and the first node's multi-address for initial discovery. You'll be prompted to enter the password established during the template creation phase—this step is crucial for maintaining security and consistency across your cloud infrastructure.
 

content/posts/branches-taubyte.md

@@ -24,6 +24,7 @@ Both **Tau** and **Dream** support running on branches.
 ## Default Behavior
 
 By default:
+
 - **Tau** (production) runs on `main` and `master` branches
 - **Dream** (local) also defaults to these branches
 
@@ -92,19 +93,19 @@ This time it should **succeed**. If you imported a project with existing functio
 
 ## Commands Reference
 
-| Command | Description |
-|---------|-------------|
-| `dream new multiverse` | Start Dream on default branch (main) |
-| `dream new multiverse -b dev` | Start Dream on `dev` branch |
-| `dream inject push-all` | Trigger builds for all repos |
+| Command                       | Description                          |
+| ----------------------------- | ------------------------------------ |
+| `dream new multiverse`        | Start Dream on default branch (main) |
+| `dream new multiverse -b dev` | Start Dream on `dev` branch          |
+| `dream inject push-all`       | Trigger builds for all repos         |
 
 ## Troubleshooting
 
-| Issue | Cause | Solution |
-|-------|-------|----------|
-| "Reference not found" | Branch doesn't exist on remote | Create branch in console |
+| Issue                 | Cause                             | Solution                             |
+| --------------------- | --------------------------------- | ------------------------------------ |
+| "Reference not found" | Branch doesn't exist on remote    | Create branch in console             |
 | Wrong branch building | Dream started on different branch | Restart Dream with correct `-b` flag |
-| Changes not appearing | Built on wrong branch | Verify console shows correct branch |
+| Changes not appearing | Built on wrong branch             | Verify console shows correct branch  |
 
 ## Best Practices
 
@@ -126,4 +127,3 @@ You've learned how to:
 Branching enables safe, isolated development that follows industry best practices. You can experiment freely knowing your main branch stays stable until you're ready to merge.
 
 Next, learn how to [ship to production](/blog/posts/ship-to-production-taubyte) when your project is ready.
-

content/posts/build-your-cloud.md

@@ -26,7 +26,7 @@ In this article, I'll go over how to use the LLM (or GPT) capabilities of [tauby
 A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it's [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte's terminology) LLM features.
 
 ## LLAMA SDK
-Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
+Satellites export low-level functions that aren't very intuitive to use directly. Fortunately, it's possible to address that with a user-friendly SDK. The [Go](https://go.dev/) SDK for [taubyte-llama-satellite](https://github.com/samyfodil/taubyte-llama-satellite) can be found [here](https://github.com/samyfodil/taubyte-llama-satellite/tree/main/sdk).
 
 ## Get Ready
 Before proceeding, let's ensure you have a project and a DFunction ready to go. If not, please refer to ["Create a Function"](https://tau.how/guides/build/02-guide/02-create-a-dfunc/).
@@ -147,9 +147,7 @@ package lib
 
 import (
 	"github.com/taubyte/go-sdk/event"
-  "github.com/samyf
-
-odil/taubyte-llama-satellite/sdk"
+  "github.com/samyfodil/taubyte-llama-satellite/sdk"
   "io"
 )
 

content/posts/cicd-taubyte.md

@@ -25,15 +25,13 @@ Taubyte comes with a **built-in CI/CD system**. Every time you push changes to t
 
 The build process is defined inside the **`.taubyte` folder**, which lives at the root of your codebase. You'll find this folder in the code of any function, website, or library.
 
-![Builds page with eye and stack icons](/blog/images/hitchhikers-guide/builds-eyeicon-list-stackicon.png)
-
 ### Folder Contents
 
-| File | Purpose |
-|------|---------|
-| `config.yaml` | Defines the build workflow |
-| `build.sh` | Script executed by the workflow |
-| Additional files | Build-specific assets |
+| File             | Purpose                         |
+| ---------------- | ------------------------------- |
+| `config.yaml`    | Defines the build workflow      |
+| `build.sh`       | Script executed by the workflow |
+| Additional files | Build-specific assets           |
 
 ## The Configuration File
 
@@ -59,12 +57,12 @@ workflow:
 
 ### Configuration Breakdown
 
-| Field | Description | Example |
-|-------|-------------|---------|
-| `version` | Config format version | `"1.0"` |
-| `environment.image` | Docker image for builds | `node:alpine` |
-| `environment.variables` | Environment variables | Key-value pairs |
-| `workflow` | Ordered list of scripts | `["generate.sh", "test.sh", "build.sh"]` |
+| Field                   | Description             | Example                                  |
+| ----------------------- | ----------------------- | ---------------------------------------- |
+| `version`               | Config format version   | `"1.0"`                                  |
+| `environment.image`     | Docker image for builds | `node:alpine`                            |
+| `environment.variables` | Environment variables   | Key-value pairs                          |
+| `workflow`              | Ordered list of scripts | `["generate.sh", "test.sh", "build.sh"]` |
 
 ## Convention Over Configuration
 
@@ -80,16 +78,17 @@ For serverless functions, Taubyte currently supports **WebAssembly only**. We pr
 
 ### Official Build Containers
 
-| Language | Container | Use Case |
-|----------|-----------|----------|
-| Go | `taubyte/go-wasi` | Go functions |
-| Go (libraries) | `taubyte/go-wasi-lib` | Go libraries |
-| Rust | `taubyte/rust-wasi` | Rust functions |
-| AssemblyScript | `taubyte/assemblyscript-wasi` | AS functions |
+| Language       | Container                     | Use Case       |
+| -------------- | ----------------------------- | -------------- |
+| Go             | `taubyte/go-wasi`             | Go functions   |
+| Go (libraries) | `taubyte/go-wasi-lib`         | Go libraries   |
+| Rust           | `taubyte/rust-wasi`           | Rust functions |
+| AssemblyScript | `taubyte/assemblyscript-wasi` | AS functions   |
 
 ### Go Example
 
 **config.yaml**:
+
 ```yaml
 version: "1.0"
 environment:
@@ -99,6 +98,7 @@ workflow:
 ```
 
 **build.sh**:
+
 ```bash
 #!/bin/bash
 go mod tidy
@@ -108,6 +108,7 @@ tinygo build -o /out/main.wasm -target wasi .
 ### Rust Example
 
 **config.yaml**:
+
 ```yaml
 version: "1.0"
 environment:
@@ -117,6 +118,7 @@ workflow:
 ```
 
 **build.sh**:
+
 ```bash
 #!/bin/bash
 cargo build --release --target wasm32-wasi
@@ -129,13 +131,13 @@ cp target/wasm32-wasi/release/*.wasm /out/main.wasm
 
 ### What WASI Provides
 
-| Capability | Description |
-|------------|-------------|
-| File access | Read/write files in sandbox |
-| Networking | HTTP requests, sockets |
-| Randomness | Cryptographic random numbers |
-| Environment | Environment variables |
-| Clocks | Time and timing functions |
+| Capability  | Description                  |
+| ----------- | ---------------------------- |
+| File access | Read/write files in sandbox  |
+| Networking  | HTTP requests, sockets       |
+| Randomness  | Cryptographic random numbers |
+| Environment | Environment variables        |
+| Clocks      | Time and timing functions    |
 
 ### Why WASI Matters for Taubyte
 
@@ -151,6 +153,7 @@ WASI modules can interact with the outside world in a **controlled, portable way
 ### For Functions
 
 Your build must output a file at:
+
 ```bash
 /out/main.wasm
 ```
@@ -160,6 +163,7 @@ This is the WebAssembly binary that gets deployed.
 ### For Websites
 
 All files must be placed in:
+
 ```bash
 /out/
 ```
@@ -169,6 +173,7 @@ The entire folder contents become your static site.
 ### Website Example
 
 **config.yaml**:
+
 ```yaml
 version: "1.0"
 environment:
@@ -180,6 +185,7 @@ workflow:
 ```
 
 **build.sh** (for a React app):
+
 ```bash
 #!/bin/bash
 npm install
@@ -188,7 +194,6 @@ mkdir -p /out
 cp -r build/* /out/
 ```
 
-
 ## Triggering Builds
 
 ### In Production
@@ -220,12 +225,12 @@ dream inject push-specific <repo-id>
 
 ## Common Build Issues
 
-| Issue | Cause | Solution |
-|-------|-------|----------|
-| `/out/main.wasm` not found | Build output in wrong location | Check `build.sh` output path |
-| Docker image not found | Typo in image name | Verify container name |
-| Build timeout | Long compilation | Optimize code, split into libraries |
-| Missing dependencies | Not in container | Add `npm install` or `go mod tidy` |
+| Issue                      | Cause                          | Solution                            |
+| -------------------------- | ------------------------------ | ----------------------------------- |
+| `/out/main.wasm` not found | Build output in wrong location | Check `build.sh` output path        |
+| Docker image not found     | Typo in image name             | Verify container name               |
+| Build timeout              | Long compilation               | Optimize code, split into libraries |
+| Missing dependencies       | Not in container               | Add `npm install` or `go mod tidy`  |
 
 ## Conclusion
 
@@ -239,4 +244,3 @@ Taubyte's CI/CD system is designed for simplicity:
 Every push builds and publishes your serverless functions and static websites automatically, keeping deployment simple and seamless.
 
 Next, learn about [working with branches](/blog/posts/branches-taubyte) for feature development and testing.
-

content/posts/create-an-online-marketplace-pt1.md

@@ -85,7 +85,7 @@ Steps:
 
 We’ll use [agents.doc](https://github.com/taubyte/agents.doc) as documentation. Prompt your AI to generate code:
 
-```
+```bash
 "Create a fully functioning simple Auth CRUD API using JWT.
 Use different files for organization.
 Use only simple and necessary code.
@@ -199,7 +199,7 @@ Backend library example: [tb_library_auth_service](https://github.com/ghir-hak/t
 
 4. Prompt AI:
 
-```
+```bash
 "Use TailwindCSS to create a minimalist elegant Auth page.
 Use the .env file for the base URL.
 Use window.location.origin for API calls."