Question

[gassechen]

Hi. I'm working on this project. https://github.com/gassechen/iiscv
I was planning to use websockets for collaboration between developers and their images, as well as for possible hotfixing between dev and prod, but then I saw your development and I found the actor model very interesting. I'd like to know, and if you'd be so kind as to shed some light on the topic, do you think it's feasible for what I'm working on?

[mdbergmann]

Hello.
Well, uff, there is a lot to read on your project. :)

Generally actors provider a thread-safe interface to state. Due to queue data structure driving the mailbox of each actor a sequential handling of the messages is guaranteed.

Most of the time an actor and the message it receives are meant for changing the state of the actor. That state can be anything actually. Maybe, in your case you could store the operations someone does on the code?

But the state is not necessarily needed all the time. Another use-case is to just have stuff being worked on asynchronously. Because the actors mailbox is backed by a thread (or set of threads when used from a message dispatcher), the work you send to it in form of a message is basically a delayed computation. The 'ask' pattern allows you to get informed when that computation happened and the result it had.

But I guess I need to read more on you project description. But just so much generally in regards to actors.

[gassechen]

Hello, thank you for responding. I'm leaving this document here, a bit more conceptual. My project currently only covers partially the IISCV.

Conceptual Document: Smart Augmented Development Architecture (SDAI)

1. Vision and Fundamentals

---

The Smart Augmented Development Architecture (SDAI) is a model designed to scale the "Live Image" philosophy of Common Lisp to a globally distributed or inter-planetary development environment. Its purpose is to guarantee the maximum productivity of the Lisp monolithic paradigm while ensuring complete forensic traceability of the code and facilitating Hot-Swapping in production.

SDAI is a robust synthesis of three core advanced software engineering concepts:

1. Live Image Paradigms: Allows for real-time code modification and compilation.
2. Actor Model (cl-gserver): Provides concurrency, fault tolerance, and asynchronous communication.
3. Immutable Systems (IISCV): Ensures complete code auditability and integrity.

2. The Two Foundational Pillars of SDAI

---

The architecture is based on a clear separation of concerns between the what (the knowledge) and the how (the infrastructure).

2.1. The Knowledge Pillar: IISCV (The Forensic Engine)

IISCV (Immutable and Curated Version Control System) is the component responsible for managing the immutable truth of the code.

• Atomic Commit: The fundamental unit of change is not the text file, but the source-form (a Lisp function, class, or variable).
• Atomic History Graph: Stores all individual, cryptographically linked, and immutable source-forms, creating a complete forensic history that guarantees the traceability of every line of code back to the developer and the exact moment of the commit.
• Curated Knowledge Object (KOC): This is the system's unit of transfer. A KOC is the Atomic Graph (or a portion thereof) serialized into a Lisp binary stream. This object is what travels across the Actor network.

2.2. The Infrastructure Pillar: cl-gserver

cl-gserver (or a similar Actor Model implementation) provides the concurrency and network abstraction layer.

• Actors: Every instance in the system (Dev, Integration, Production) is a self-contained Lisp Actor. Actors communicate only through asynchronous messages, abstracted from network details (IPs, ports, TCP/IP).
• Asynchrony and Fault Tolerance: This model allows for total decoupling between Actors. An Actor does not wait for a response from another and is not blocked by network failures or slowness—essential for high-latency environments.
• Abstracted Stream: KOC serialization occurs through Lisp I/O Stream Functions which are, at the library level, translated into secure network protocols (TLS/mTLS) for communication with the central KOC Store.

3. The SDAI Actor Ecosystem

---

The system is a federation of Actors with specialized roles that constitute the Live Development System.

Actor	Primary Role	Responsibility Focus
DEV-ACTOR (K-MS)	Knowledge Microservice. Code mutation and creation of Curated Atomic Commits.	Publishes the full KOC to the KOC Store and notifies MAIN via a lightweight message.
MAIN-ACTOR	Forensic Orchestrator and Canonical Arbiter. Resolves symbol conflicts and maintains the Canonical Curated Source Code.	It is the Source of Code Truth; it holds all source code ready for Production builds.
PROD-ACTOR	Live Execution Engine. The running application instance, with self-diagnosis and Hot-Swapping capabilities.	Monitors execution, sends errors, and dynamically applies fixes without rebooting.
ERROR-GATEWAY-ACTOR	Intelligent Triage Center. Receives error telemetry from PROD. Uses Lisp Introspection to route the bug to the correct diagnostic Actor.	A defense routine for debugging; centralizes and distributes error messages.
LLM-ACTOR	Augmented Development Assistant. Analyzes error context and code history to generate proposed source-form fixes.	Proposes solutions to the DEV-ACTOR for final validation.

4. The Two Operational Circuits

---

The SDAI operates simultaneously through two distinct, parallel, asynchronous communication channels.

4.1. Circuit I: Development, Integration, and Build (Features)

This is the main channel for code evolution:
DEV ---> MAIN --> PROD

1. Dev works locally and publishes its KOC to the KOC Store.
2. Dev sends an (:PUBLISH-KOC) message to Main.
3. Main audits, resolves symbol conflicts, and consolidates the Curated Source Code in its internal state.
4. Main generates the Production Image (build) on demand, using the code it already holds (build autonomy).

4.2. Circuit II: Triage, Diagnosis, and Hot-Fixing (Bugs)

This is the reactive channel for live failure response:
PROD --> ERROR-GATEWAY --> LLM/DEV --> MAIN --> PROD

1. Prod detects an exception, serializes the context, and asynchronously sends it to Error-Gateway.
2. Error-Gateway reads the error symbol and routes it to the LLM-Actor and/or the responsible Dev-Actor.
3. The LLM/Dev proposes a fix (source-form).
4. The Main signs the fix and sends it to the Prod with an (:APPLY-FIX) message.
5. Prod verifies the cryptographic signature and executes the code live (Hot-Swap), fixing the bug without restarting.

5. Security and Guarantee of Autonomy

---

5.1. Cryptographic Security (The Antidote to Remote REPL) 🔒

Security is implemented in layers to prevent Remote Code Execution (RCE), the main risk of dynamic hot-swap systems:

• Transport Encryption (TLS/mTLS): All Actor communication is encrypted. Mutual TLS (mTLS) ensures that only authenticated Actors can participate.
• Code Signing (IISCV): Every KOC and Atomic Commit is digitally signed by its originating Actor. The PROD-ACTOR verifies this cryptographic signature before executing the code. If the code was altered, the execution is rejected.

5.2. Autonomy and Geographical Resilience 🌍

The architecture is designed to withstand high latency and intermittency:

• Build Autonomy: The MAIN-ACTOR stores all Curated Source Code, making the Production build process totally independent of connectivity to Dev Actors or the KOC Store.
• Latency Tolerance: The asynchronous Actor Model decouples developers from network latency, allowing continuous work without blocking, while the Curated Atomic Commit travels and is integrated at the speed of light (or slower, if on Mars).

[mdbergmann]

Nice project.

Yeah, I think this can be doable with Sento.

[mdbergmann]

One thing to consider is if each actor should have its own thread or if actors should use the default message dispatcher.
Since you don't seem to need many actors a :pinned dispatcher could probably be better.
Also something to avoid is long running tasks being handled by actors.

[gassechen]

Thanks for responding, I'm going to study the topic well because I lack knowledge about the actors' paradigm.