Feat: Add old docs, begin adapting old docs to new format.

docs/Documentation/AtDev - New Firewall script.md

@@ -0,0 +1,254 @@
+- - -
+# #AtDev , work in progress
+- - -
+Under /etc/init.d/ we have 
+
+```shell
+
+	# cd /etc/init.d/
+# ls
+S00fix-os                 S15crond                  S33dbus                   S48avahi-daemon           S63body-board-power       S78jibo-system-manager
+S01logging                S18udev                   S36sshd                   S51upload-logs            S66ntp                    S81named
+S06coredumps              S21firewall               S39audio-enable           S54modules                S69start-X11              S84identity-syslog
+S09wifi-enable            S24cpufreq                S42avahi-setup.sh         S57alsa-volume            S72jibo-apply-update      rcK
+S12dns-prime              S30urandom                S45network                S60alsaloopback           S75jibo-service-registry  rcS
+
+```
+
+currently interested in `/etc/init.d/S21firewall`
+
+```log
+# cat /etc/init.d/S21firewall
+#!/bin/sh
+#
+# Jibo Firewall init script
+#
+
+set -e
+
+IPTABLES_CMDS="/usr/sbin/iptables /usr/sbin/ip6tables"
+
+flush_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        $iptables -t filter -F
+        $iptables -t filter -P INPUT ACCEPT
+        $iptables -t filter -P FORWARD ACCEPT
+        $iptables -t filter -P OUTPUT ACCEPT
+        # add the DYNAMIC_ACCESS chain unconditionally
+        $iptables -t filter -X
+        $iptables -t filter -N DYNAMIC_ACCESS
+    done
+}
+
+normal_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        $iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
+        $iptables -t filter -A INPUT -p icmp -j ACCEPT
+        $iptables -t filter -A INPUT -i lo -j ACCEPT
+        # allow dynamic access rules from system-manager
+        $iptables -t filter -A INPUT -j DYNAMIC_ACCESS
+        $iptables -t filter -A INPUT -j REJECT
+        $iptables -t filter -A FORWARD -j REJECT
+    done
+}
+
+developer_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        # jibo-dev-shell
+        $iptables -t filter -A INPUT -p tcp --syn --dport 8686 -j ACCEPT
+        # jibo-skills-service
+        $iptables -t filter -A INPUT -p tcp --syn --dport 8779 -j ACCEPT
+        # jibo-sync
+        $iptables -t filter -A INPUT -p tcp --syn --dport 8989 -j ACCEPT
+        # jibo-debug-proxy
+        $iptables -t filter -A INPUT -p tcp --syn --dport 9191 -j ACCEPT
+        # avahi
+        $iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
+    done
+    normal_rules
+}
+
+certification_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        # jibo-certification-service
+        $iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
+    done
+    normal_rules
+}
+
+service_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        # jibo-certification-service
+        $iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
+        # jibo-service-center-service
+        $iptables -t filter -A INPUT -p tcp --syn --dport 9797 -j ACCEPT
+        # avahi
+        $iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
+    done
+    normal_rules
+}
+
+start() {
+    echo -n "Configuring firewall: "
+    flush_rules
+    my_mode=$(/usr/bin/jibo-getmode)
+    if [ $? -ne 0 ]; then
+        echo "Unspecified mode. SKIP"
+    elif [ "$my_mode" == "identified" ]; then
+        echo "IDENTIFIED"
+    elif [ "$my_mode" == "int-developer" ]; then
+        echo "INT-DEVELOPER"
+    elif [ "$my_mode" == "developer" ]; then
+        developer_rules
+        test $? -eq 0 && echo "DEVELOPER" || echo "ERROR"
+    elif [ "$my_mode" == "certification" ]; then
+        certification_rules
+        test $? -eq 0 && echo "CERTIFICATION" || echo "ERROR"
+    elif [ "$my_mode" == "service" ]; then
+        service_rules
+        test $? -eq 0 && echo "SERVICE" || echo "ERROR"
+    else
+        normal_rules
+        test $? -eq 0 && echo "OK" || echo "ERROR"
+    fi
+}
+
+stop() {
+    echo -n "Unconfiguring firewall: "
+    flush_rules
+    test $? -eq 0 && echo "OK" || echo "ERROR"
+}
+
+case "$1" in
+    start)
+        start
+        ;;
+    stop)
+        stop
+        ;;
+    restart)
+        stop
+        start
+        ;;
+    *)
+        echo "Usage: $0 {start|stop|restart}" >&2
+        exit 1
+        ;;
+esac
+```
+
+and in `S78jibo-system-manager`
+
+```log
+# cat S78jibo-system-manager 
+#!/bin/sh
+#
+# Jibo System Manager init script
+#
+
+set -e
+
+PROCESS=jibo-system-manager
+BIN_DIR=/usr/local/bin
+CFG_DIR=/usr/local/etc
+
+check_mode() {
+    my_mode=$(/usr/bin/jibo-getmode)
+    if [ $? -ne 0 ]; then
+        echo "Unspecified mode. SKIP"
+        exit 0;
+    fi
+    if [ "$my_mode" != "oobe" \
+        -a "$my_mode" != "int-developer" \
+        -a "$my_mode" != "developer" \
+        -a "$my_mode" != "normal" \
+        -a "$my_mode" != "certification" \
+        -a "$my_mode" != "service" ]; then
+        echo "Mode is $my_mode. SKIP"
+        exit 0;
+    fi
+    # only configure coredump generation for internal development modes
+    # for all other modes, don't configure as they cannot be used
+    if [ "$my_mode" == "int-developer" ]; then 
+        echo "Configuring coredumps"
+        # all subprocesses should generate core dumps
+        ulimit -c unlimited
+    fi
+}
+
+check_running() {
+    pgrep -x jibo-system-man >& /dev/null
+    return $?
+}
+
+wait_for_stopped() {
+    while check_running; do
+        echo -n "waiting... "
+        sleep 2
+    done
+}
+
+start() {
+    echo -n "Starting $PROCESS: "
+    check_mode
+    $BIN_DIR/$PROCESS -c $CFG_DIR/$PROCESS.json --daemon
+    test $? -eq 0 && echo "OK" || echo "ERROR"
+}
+
+stop() {
+    echo -n "Stopping $PROCESS: "
+    killall $PROCESS
+    wait_for_stopped
+    test $? -eq 0 && echo "OK" || echo "ERROR"
+}
+
+case "$1" in
+    start)
+        start
+        ;;
+    stop)
+        stop
+        ;;
+    *)
+        echo "Usage: $0 {start|stop}" >&2
+        exit 1
+        ;;
+esac
+```
+
+to bypass the lockout in normal mode we can add like a filter under the normal rules function
+
+first ima remount with write permissions :
+
+```shell
+
+	mount -o remount,rw /
+
+# vi and append :
+
+normal_rules() {
+    for iptables in $IPTABLES_CMDS; do
+        $iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
+        $iptables -t filter -A INPUT -p icmp -j ACCEPT
+        $iptables -t filter -A INPUT -i lo -j ACCEPT
+        # allow dynamic access rules from system-manager
+
+
+
+       >>> $iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT <<<
+        $iptables -t filter -A INPUT -j DYNAMIC_ACCESS
+        $iptables -t filter -A INPUT -j REJECT
+        $iptables -t filter -A FORWARD -j REJECT
+    done
+}
+
+
+```
+
+i was gonna use telnetd but its not installed
+
+anyway using`jibo-getmode` i will revert back to the `normal` mode
+
+and it works! saving diff for the installer
+
+now that we have normal mode with ssh we have more capabilities, i will re screw the head back!... i broke my face ring

docs/Documentation/Networking/Network Profiling & Traffic Analysis.md

@@ -0,0 +1,71 @@
+Since Jibo’s official servers were decommissioned, the robot hangs during the "Checking for Updates" phase, and of course. By sniffing its network traffic, (Community member : Jaked) has identified several hardcoded endpoints. Our goal is to redirect this traffic to a local server to simulate a "Success" response and unlock the robot’s full functionality.
+- - -
+Initial scans show that Jibo uses a standard network stack but maintains a strict internal firewall.
+
+- **Primary DNS:** Hardcoded to `8.8.8.8` (Google DNS).
+- **Web Config:** Ports `80`and `443` are closed/filtered by default.
+- **ROS Bridge:** Port `9090` (used for MIT Workspace/SDK) is **blocked**. It appears to require a specific "Skill" (likely the _be-skill_) to be running before the port opens.
+
+---
+
+## Known Target Endpoints
+
+The following table lists the IPs Jibo attempts to contact immediately after connecting to WiFi.
+
+### **Time Synchronization (NTP)**
+
+Jibo hits these IPs repeatedly to sync its internal clock. Without a successful time sync, SSL handshakes for other services will fail.
+
+```
+-45.115.225.48
+216.229.4.66
+93.57.144.50
+66.231.64.28
+194.195.253.58
+```
+
+### **Persistent AWS Infrastructure**
+
+These are the most critical targets. Jibo hits these over and over, likely checking for signals or update manifests.
+
+- **IP 1:** `35.172.208.31`
+- **IP 2:** `44.198.39.206`
+
+> **Hypothesis:** These were likely the primary API endpoints for `jibo.com`. I am investigating the packet payload to see if they are expecting JSON or XML responses.
+
+### **Legacy & Third-Party Hits**
+
+These appear less frequently, possibly for analytics or legacy newsletter/resource loading. 
+
+
+
+| IP Address       | Ownership (potential) | Purpose                    |
+| ---------------- | --------------------- | -------------------------- |
+| `66.118.231.14`  | Constant Contact      | Maybe email or newsletter? |
+| `172.232.15.202` | Akamai                | Content Delivery?          |
+| `72.30.35.89`    | Yahoo                 | Weather / News API         |
+| `67.210.96.32`   | Host Papa             | Domain hosting             |
+
+---
+
+## Current Observations
+
+### **The Update Loop**
+
+When Jibo reaches the "Checking for Updates" screen, it isn't "dead." Even while the screen is stuck loading , the background :
+
+1. **Audio Processing stays active:** Saying _"Hey Jibo"_ causes the robot to turn toward the sound source.
+2. **Network Persistence:** It continues to attempt connections to the AWS IPs listed above.
+3. **Timeout Behavior:** It is unclear if the timeout is extremely long or if it is failing a specific SSL handshake.
+
+### **Domain Discrepancy**
+
+- **jibo.com:** Officially shut down; no longer resolves to an active site.
+- **jibo.net:** Tribute site made by Community member Jibo-detective or RoboticaLabs on youtube
+
+---
+
+Check out [[Networking & ports & Error codes]] by ZaneDev from discord
+
+---
+

docs/Documentation/Networking/Networking & ports & Error codes.md

@@ -0,0 +1,21 @@
+- - -
+# Useful Ports
+> [!INFORMATION]
+> You might not be able to access some ports if you haven't unblocked them on Jibo's firewall.
+### 8779
+This port has the skills manager. From here you can do a semi-reboot by stopping and starting the "@be/Be" skill.
+### 15150
+This port has logs. This port is only available on v3+ of the revival project (can be checked on the information section in settings).
+### 10004
+Error service, allows you to simulate errors in realtime. Shows names of third parties by accident.
+It seems in recent versions of Jibo errors relating to him not being able to connect to Jibo Inc Servers don't create a pop up L2, L7, Q1 (oddly WIFI4 and WIFI4a still give pop up), Q4. N1-N12 don't have pop ups either. OTA11 and R1 also makes an error inside an error saying "NOT HANDLED BY ERROR SKILL".
+
+**TL;DR:**
+
+| Error Code(s) | Shows Popup? | Notes |
+|---|---|---|
+| L2, L7, Q1 | No | Server connection errors |
+| WIFI4, WIFI4a | Yes | |
+| Q4 | No | |
+| N1–N12 | No | |
+| OTA11, R1 | No | Triggers error-within-error: "NOT HANDLED BY ERROR SKILL" |

docs/Documentation/The be skill/About the be skill.md

@@ -0,0 +1,5 @@
+ - - -
+The Be skill really is just jibos main menu including his eye and well... menu... 
+anyway i will write about this later but for now here are some references to check out :)
+
+

docs/Documentation/The be skill/Assets/The assets directory.md

@@ -0,0 +1,5 @@
+- - -
+
+Located in `/usr/local/bin/`
+
+Has a lot of random assets, potentially has assets useful for restoration.

docs/Documentation/The be skill/Assets/The audio directory.md

@@ -0,0 +1,5 @@
+ - - -
+
+Located in `/opt/jibo/Jibo/Skills/@be/be/node_modules/jibo-anim-db-animations/audio/`
+
+Lots of audio assets, the surrounding folders also contain other assets.

docs/Documentation/The be skill/The Splash screen image!.md

@@ -0,0 +1,7 @@
+- - -
+
+it is located in:
+
+`/opt/jibo/Jibo/Skills/@be/be/resources/JiboSplash.png`
+
+This file allows you to edit the splash screen. This is the image that shows at the start of the Be skill (normally the Jibo logo, Jibo Revival logo, OpenJiboOS logo, or some variation). Note: This is only the splash screen for the Be skill. It will only edit the splash seen when you restart "@be/Be", or in the **'second boot stage'** when Jibo spins and shows the splash a second time.

docs/Documentation/Useful Items List.md

@@ -0,0 +1,16 @@
+Jibo was built a little weird, so it's easy to forget things. This document contains things that are nice to know for tinkering or developing for Jibo Revival.
+- - -
+## About [[The Splash screen image!]]
+
+## About [[The assets directory]]
+
+## About [[The audio directory]]
+
+## About [[Networking & ports & Error codes]]
+
+## About [[Network Profiling & Traffic Analysis]]
+
+## About [[Local Voice Round-Trip on Jibo (AI Commmunication)]]
+
+- - -
+ Documented by ZaneDev @ Our Discord

docs/Documentation/Voice/Local Voice Round-Trip on Jibo (AI Commmunication).md

@@ -0,0 +1,264 @@
+# Local ASR, TTS, and Voice Round-Trip on Jibo (Post-Cloud)
+
+> This document describes the first confirmed working voice interaction on a Jibo robot after official cloud services were discontinued.
+
+---
+
+## Summary
+
+Short version: Jibo can still have a full conversation loop locally.
+
+We now have:
+
+* Speech → text (STT) working locally
+* Text → speech (TTS) working locally
+* A working loop where Jibo hears something and responds
+
+This is all happening without the original cloud services.
+
+---
+
+## Key Findings
+
+Here’s what we now know for sure:
+
+* Wake word detection (`hey jibo`) still works locally
+* Speaker ID is still running locally (even if it rejects us 😄)
+* `jibo-asr-service` can be started and controlled manually
+* ASR (speech recognition) is exposed over HTTP on port `8088`
+* TTS (speech output) is exposed over HTTP on port `8089`
+
+### ASR Endpoints
+
+Confirmed working endpoints:
+
+* `/asr_simple_interface`
+* `/audio_source`
+* `/asr_control`
+* `/status`
+
+### WebSocket Outputs
+
+ASR results are streamed over WebSockets:
+
+* `ws://<jibo-ip>:8088/port`
+* `ws://<jibo-ip>:8088/simple_port`
+
+### Example STT Start Payload
+
+```json
+{
+  "command": "start",
+  "task_id": "DEBUG:task3",
+  "audio_source_id": "alsa1",
+  "hotphrase": "none",
+  "speech_to_text": true,
+  "request_id": "stt_start3"
+}
+```
+
+---
+
+## What’s Actually Happening (Architecture)
+
+Here’s the real flow in plain English:
+
+1. We send a request to Jibo to start listening
+2. Jibo captures audio from its mic (ALSA)
+3. The ASR engine processes it
+4. Results come back over WebSocket
+5. Our app reads the transcript
+6. Our app decides what to say
+7. We send that to Jibo’s TTS
+8. Jibo speaks
+
+Visual version:
+
+```
+HTTP POST (/asr_simple_interface)
+        ↓
+ASR service captures audio
+        ↓
+Speech recognition runs locally
+        ↓
+WebSocket emits events
+        ↓
+External app receives transcript
+        ↓
+External logic decides response
+        ↓
+HTTP POST (/tts_speak)
+        ↓
+Jibo talks
+```
+
+---
+
+## Example WebSocket Output
+
+Here’s a trimmed real example of a final result:
+
+```json
+{
+  "event_type": "speech_to_text_final",
+  "task_id": "DEBUG:task3",
+  "utterances": [
+    {
+      "utterance": "what time is it",
+      "score": 975.9
+    }
+  ]
+}
+```
+
+You’ll also see:
+
+* `speech_to_text_incremental` (partial results)
+* `end_of_speech`
+* `hotphrase` (for "hey jibo")
+
+---
+
+## Demo Flow (How to Reproduce)
+
+This is the important part.
+
+### 1. Make sure you are in `int-developer` mode and ASR service is running
+
+From ssh:
+
+```
+/usr/local/bin/jibo-asr-service -c /usr/local/etc/jibo-asr-service.json
+```
+
+---
+
+### 2. Connect to WebSocket
+
+```
+ws://<jibo-ip>:8088/simple_port
+```
+
+---
+
+### 3. Start an STT task
+
+POST to:
+
+```
+http://<jibo-ip>:8088/asr_simple_interface
+```
+
+With:
+
+```json
+{
+  "command": "start",
+  "task_id": "DEBUG:task3",
+  "audio_source_id": "alsa1",
+  "hotphrase": "none",
+  "speech_to_text": true
+}
+```
+
+---
+
+### 4. Speak to Jibo
+
+Say something like:
+
+> “what time is it”
+
+---
+
+### 5. Wait for final transcript
+
+Watch for:
+
+```
+event_type: speech_to_text_final
+```
+
+---
+
+### 6. Send response to TTS
+
+POST to:
+
+```
+http://<jibo-ip>:8089/tts_speak
+```
+
+With something like:
+
+```json
+{
+  "text": "It is demo time."
+}
+```
+
+---
+
+### 7. Jibo speaks 🎉
+
+---
+
+## Known Behaviors / Quirks
+
+Some things we’ve seen so far:
+
+* WebSocket connections can drop → reconnect logic helps
+* Incremental results can be messy or duplicated
+* Multiple transcript guesses can show up
+* Wake word (`task0`) runs alongside your custom task
+* Saying “hey jibo” during a manual STT session can interfere
+* Speaker ID often rejects (but doesn’t block STT)
+
+---
+
+## Corrections to Previous Assumptions
+
+Some things we (and others) thought before that are now clearly wrong or incomplete:
+
+* “ASR is dead without cloud” → **Not true in developer mode**
+* “Only wake word works locally” → **Incomplete**
+* “No way to get transcripts” → **False (WebSocket output exists)**
+* “Jibo can’t answer questions anymore” → **Also false now 🙂**
+
+---
+
+## What This Means
+
+This is a big deal:
+
+* Jibo’s core voice pipeline is still there
+* The cloud was orchestration, not the whole system
+* We can now rebuild the “brain” externally
+
+---
+
+## Next Steps
+
+Where this naturally goes next:
+
+* Hook wake word → automatically trigger STT
+* Figure out how this behaves in “normal mode”
+* See if Jibo tries to initiate outbound connections (old cloud flow)
+* Intercept or replace those endpoints locally
+* Build a simple always-on bridge service:
+
+  * Wake word → STT → AI → TTS
+
+---
+
+## Final Thought
+
+We didn’t just poke at endpoints here.
+
+We proved Jibo can:
+
+* hear
+* understand
+* and respond again
+
+That’s a pretty great place to be.