Context switching doodt het momentum. Wanneer een AI-assistent halverwege een project uitvalt, begint de volgende sessie koud. Geen geheugen van de repositorystructuur. Geen herinnering aan welke poorten actief zijn. Geen besef dat de Monero RPC gisteren problemen gaf. Daniel Ioni heeft iets direct en nuttigs gebouwd: een technische gids, specifiek geschreven voor AI-systemen, zodat ze de werkzaamheden aan de MyZubster Gateway kunnen hervatten zonder dat er handmatige begeleiding nodig is. Het functioneert als een persistent synthetisch geheugen. In plaats van ruwe broncode te dumpen, leert het de machine hoe het systeem moet worden bediend, hoe fouten moeten worden opgelost en hoe de autoriteit van de operator moet worden gerespecteerd voordat er destructieve wijzigingen worden aangebracht.

Wat MyZubster feitelijk bouwt

MyZubster Gateway is een gedecentraliseerde marktplaats gebouwd rond de tokenisatie van real-world assets. In begrijpelijke taal is het infrastructuur die fysieke of traditionele activa on-chain laat bewegen met gedefinieerde metadata en eigendomsregels. Het platform handelt de tokenisatie van fungibele activa af, wat betekent dat activa kunnen worden opgedeeld, verhandeld en gevolgd met gestandaardiseerde metadata die aan elke eenheid is gekoppeld.

Privacy staat centraal in het ontwerp. Transacties worden afgewikkeld in Monero. Programmeerbare activa en NFT's draaien op Tari. De gehele operatie schermt zichzelf af achter een Tor Onion Service, waardoor de gateway bestand is tegen censuur en geografische blokkades. Een beveiligingslaag draait op Kali Linux en maakt gebruik van DeepSeek AI security bots, wat duidt op automatische detectie van indringers of anomalie-scanning in plaats van eenvoudige logrotatie. Escrow en geschillenbeslechting zijn geen handmatige backoffice-taken. Ze zijn geautomatiseerd, waarbij AI bemiddelt wanneer handelsvoorwaarden een conflict veroorzaken.

Dat is slechts de oppervlakte. Daaronder is het systeem een web van RPC-endpoints, lokale databases en Node.js-processen die gesynchroniseerd moeten blijven, anders stopt de marktplaats met het afwikkelen van transacties.

De technische stack en waarom dit belangrijk is

De gateway luistert op poort 3002. Dat is de voordeur. De wallet RPC van Monero bevindt zich op localhost:18083 en handelt privé-walletoperaties, saldo-opvragingen en uitgaande overboekingen af zonder gebruikersgegevens bloot te stellen aan publieke chain-analyse. De RPC van Tari reageert op localhost:12820 en beheert de laag voor programmeerbare activa. Als een van deze endpoints afwijkt of uitvalt, komt de marktplaats tot stilstand.

MongoDB draait op de achtergrond als de operationele gegevensopslag. Node.js voedt de gateway-service zelf. De frontend-code bevindt zich in een specifieke directory op ~/myzubster-frontend. Dit is een klassieke gedecentraliseerde stack: blockchain-nodes voor afwikkeling, een lokale database voor de status en een dunne weblaag voor interactie, allemaal verpakt in privacy-tools. Niets hier is decoratief. Elke poort en elk pad is gekozen om het systeem zelfvoorzienend en verdedigbaar te houden.

Het systeem draaien

Het starten van de gateway is een enkele systemd-opdracht: systemctl start myzubster-gateway. Dat klinkt triviaal totdat de service na een onbeheerde reboot geruisloos uitvalt. Dan heb je journalctl -u myzubster-gateway -n 50 --no-pager nodig om de laatste vijftig logregels op te halen zonder paginageruis. Die vijftig regels bevatten meestal het antwoord. Misschien weigerde de Monero RPC de verbinding. Misschien kwam MongoDB na een systeemupdate nooit meer online.

De security bot bevindt zich op /root/security_bot.py en wordt gestart met python3 /root/security_bot.py. Een security-script als root draaien is niet iets wat je doet op een algemene server. Binnen een verharde Kali-omgeving die gewijd is aan monitoring en automatische respons, past dit in het operationele model. De DeepSeek AI-integratie impliceert dat de bot meer doet dan alleen logs scannen; het evalueert waarschijnlijk netwerkgedrag of transactiepatronen op tekenen van een inbreuk.

Voor frontend-werk neemt de gids alle giswerk weg. De AI weet de exacte locatie: cd ~/myzubster-frontend. Geen zoektochten door /var/www, /opt of verspreide home-directories. De gids dwingt consistentie af door deze paden exact vast te leggen, wat belangrijk is wanneer meerdere sessies of verschillende AI-instanties gedurende weken dezelfde server gebruiken.

Wanneer er iets misgaat

Wanneer de gateway uitvalt, is de eerste stap procesverkenning. Voer ps aux | grep node uit om te zien of het Node.js-proces nog leeft. Als het is verdwenen, controleer dan de logs. Als de logs een databaseverbindingfout laten zien, is MongoDB de schuldige. Start het op met systemctl start mongod. Veel gedecentraliseerde applicaties beschouwen blockchain-nodes als het kwetsbare onderdeel, maar in de praktijk is de lokale MongoDB-instantie vaak degene die als eerste hapert na een onjuiste afsluiting of een routinepakketupdate.

Monero RPC-problemen volgen een ander patroon. Als saldi stoppen met bijwerken of uitbetalingstransacties in een 'pending' status blijven hangen, instrueert de handleiding om de status van monero-wallet-rpc te controleren. Dat betekent meestal het verifiëren of het wallet RPC-proces draait, bevestigen dat het gesynchroniseerd is met de juiste daemon, en ervoor zorgen dat de authenticatievlaggen overeenkomen met wat de gateway verwacht. Triage is hier eenvoudig: eerst de blockchain settlement-laag, dan de database, en als laatste de applicatie. Negeer je deze volgorde, dan ben je naar spoken aan het zoeken in de Node.js-logs terwijl de werkelijke fout een dode RPC-poort is.

Hoe de AI deze handleiding moet gebruiken

De handleiding legt vier gedragsregels op aan de AI, en deze tonen een begrip van hoe geautomatiseerde assistenten falen in productieomgevingen.

Ten eerste: refereer aan specifieke secties. Als de gebruiker een betalingsfout probeert op te lossen, moet de AI het Monero RPC- of escrow-subsysteem expliciet benoemen, zodat de gebruiker precies weet welke 'pijp' lekt. Ten tweede: geef exacte commando's. Parafraseer geen vlaggen en raad geen paden. Ten derde: suggereer de volgende logische stap. Projectherstel is een opeenvolging; willekeurig springen tussen poortcontroles en security bots verspilt tijd en brengt het risico met zich mee dat het probleem verergert. Ten vierde: vraag om bevestiging van de gebruiker voordat services worden herstart of gegevens worden verwijderd. Autonomie is nuttig totdat het per ongeluk een wallet-cache wist of de gateway platlegt tijdens actieve transacties.

Een levend document

Deze handleiding is expliciet ontworpen om te evolueren. Naarmate het MyZubster-project groeit, werkt de AI het document bij. Dat creëert een feedbackloop waarbij operationele ervaring verandert in institutioneel geheugen. In een klein team, of bij een solo-project dat over verschillende tijdzones en slaapcycli heen werkt, vervangt dit de 'watercooler-kennis' die normaal gesproken in de hoofden van senior engineers zit. Het document leert van elke storing.

De belangrijkste conclusie

AI-projectherstelgidsen zoals deze lossen een specifiek, pijnlijk probleem op. Ze overbruggen de kloof tussen ruwe documentatie en contextueel begrip. Voor MyZubster betekent dit dat de marktplaats contextverlies, reboots en teamovergangen kan overleven. De machine hoeft de stack niet telkens opnieuw te leren wanneer een nieuwe sessie start. Het hoeft alleen de handleiding te lezen, de exacte commando's te volgen en te weten wanneer het moet stoppen en om hulp moet vragen.

Bron: AI Technical Guide: MyZubster Project Recovery door Daniel Ioni

Optionele leercommunity: GyaanSetu AI op Telegram