Hello Grayman,
What I imagine is more or less what you describe, but the one maintaining a node doesn’t worry about the services (or bots) it runs. As users, we can play three types of roles:
- Node maintainer (similar to someone maintaining a miner in a blockchain).
- Service developer (what you call bots). These can be run by anyone on any node (any compatible node, in terms of architecture, etc.).
- Users who launch services on nodes.
Therefore, the person maintaining a node (type 1 user) doesn’t concern themselves with whether it’s mining Ergo, running a trading bot, analyzing a DNA sequence, or whatever the services it runs do. They simply execute the services that type 3 users request, in exchange for proof of payment (on a blockchain or whatever method of payment is accepted). The developer (type 2 user) only needs to send it to one or multiple nodes, and these will handle distributing the service among others and/or uploading it to the reputation system, so that users (or other services) know when and why to use it. (The reputation system is what I intend to develop on Ergo.)
So, answering your questions: The services (bots) run on nodes where any type 3 user instantiates them, and each instance runs on a single node only, although a service can execute other services on other nodes in the form of child and parent services. (In reality, the services don’t understand what a node is; they request services from the node that executes them, and this node decides whether to run it itself or on another pair. This way, when programming a service, you don’t worry about load balancing in the network.)
With all that said, continuing from my previous message, I believe the system I describe solves the disadvantages of both web services and the bot I run on my PC. This is because as a user who wants to use a service (type 3 user):
- I don’t need to run the infrastructure myself, as the node takes care of this.
- I don’t need to configure anything, as the service is entirely deterministic and the node can instantiate it as a container or virtual machine.
- The developer (type 2 user) cannot control or modify the service (or access the data it manages), as they don’t control the nodes that distribute and execute it.
Regarding Shinkai, I wasn’t familiar with the project; thank you for sharing it. It doesn’t have much documentation, but I find the idea of allowing communication between LLMs interesting. This isn’t exactly related to my idea, but services could be built with this feature (like their system). As far as I understand, both ideas could be compatible.
The project I’m presenting isn’t a protocol; I don’t intend for it to be. I suppose we could call it a design pattern (i.e., separating the notion of node and service and specifying the rights and responsibilities of each). This is because the nodes don’t need to establish a consensus beyond the abstract idea of node-service; the way they’re represented, how services are distributed, or how nodes relate to each other can vary just like the diversity of languages and cultures in our society.
This way, an LLM from Shinkai can be built on one service, an LLM from Autonolas (another similar solution you mentioned) on another, GPT-4 on another service, and a user can use a service that compares the three and uses the one that works best for them (and the same reasoning applies recursively to that service, hence not being able to reach a concrete consensus at the basic level of the system).
P.S.: I call my project Celaut, as its design is inspired by that of a cellular automaton, where simple rules create complex structures.