---
title: "Esteban Fuster Pozzi (estebanrfp) (@estebanrfp) | Hashnode"
description: "Full Stack Developer - dWEB R&D. Read the latest articles by Esteban Fuster Pozzi (estebanrfp) on Hashnode."
url: "https://hashnode.com/@estebanrfp"
---

@estebanrfp

# Esteban Fuster Pozzi (estebanrfp)

@estebanrfp · Valencia, España · Joined November 2025

Full Stack Developer - dWEB R&D

[Website](https://estebanrfp.com/)

## Comments

[Really appreciate this — you put your finger on the exact thing I cared about while building it: the action boundary. A few design choices that tackle it head-on: Every mutation goes through Defold's own editor.transact API — changes are atomic and land in the editor's normal undo stack. A bad edit is just Ctrl+Z, nothing exotic. Nothing touches disk until an explicit editor.save() — the AI stages changes in the live editor, but the developer decides when they get persisted. Read and write are split across tools (editor\_state, \*\_get\_\*, \*\_find are read-only; mutations are separate calls), so inspecting state never has side effects. So it's exactly the "fast assistant, developer keeps final control" model you describe — not "Claude controls everything." The editor stays the source of truth and the human stays in the loop. Thanks for the thoughtful read — this is exactly the kind of feedback that shapes where it goes next. — Esteban. On a tangent, since you're clearly into AI + game tooling: I also maintain estebanrfp/gdb on github (a real-time graph DB) and a Godot integration, godot-genosdb — different engine, but the same itch of keeping live state predictable. Might be up your alley.](https://hashnode.com/posts/defold-ai-the-mcp-that-connects-claude-code-straight-into-your-live-defold-editor/6a162094da253d50d4f30823/comment/6a26f2e490a24206524d0abd)

Comment · Article · Jun 8 · [Defold AI: the MCP that connects Claude Code straight into your live Defold editor](https://hashnode.com/posts/defold-ai-the-mcp-that-connects-claude-code-straight-into-your-live-defold-editor/6a162094da253d50d4f30823)

[I’ve worked quite a bit with GunDB over the years (including building its documentation platform and several P2P projects on top of it), so it’s always nice to see breakdowns like this one. At some point I ended up building my own alternative, GenosDB, mostly because I needed a few things that differed from the traditional Gun model: A more explicit API with stronger querying GenosDB keeps the distributed graph idea but uses a minimal API (put/get/map/link/remove) plus native Mongo-style queries, sorting, pagination, and recursive traversal with $edge for exploring full descendant trees in a graph . Integrated RTC without running custom servers Gun uses DAM, but I needed real-time P2P with both data channels and AV streams directly from the DB layer. GenosDB includes GenosRTC: WebRTC + decentralized signaling over Nostr, dynamic relay fallback, PoW detection, and automatic mesh connectivity between peers . A distributed security model with cryptographic verification Every operation is signed, and each node runs a local Security Manager that validates identities, roles, and permissions based on a shared constitution. No implicit trust between peers, even if a client tampers with its local UI. Superadmins are defined statically to ensure a secure trust root in the RBAC model . The bundle is free for personal and commercial use, so if you already understand the GunDB approach and feel like comparing design choices or testing another P2P/RTC architecture, it might be interesting to try. If you’re curious about how these design choices look in practice, the implementation and specs are openly available on my GitHub profile estebanrfp/gdb.](https://hashnode.com/posts/intro-to-gun-a-p2p-decentralized-database/634188a5250857e669efc4f1/comment/69248551526c58980a05f668)

Comment · Article · Nov 24, 2025 · [Intro to Gun - A P2P Decentralized Database](https://hashnode.com/posts/intro-to-gun-a-p2p-decentralized-database/634188a5250857e669efc4f1)