godprotocol 2.2.85 → 2.2.86
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/server/Routable/Create platform, +5 -0
- package/server/Routable/Header.js +3 -0
- package/server/Routable/Storyline,.md +20 -0
- package/server/Routable/The Story Board.md +34 -0
- package/server/Routable/The flow is simple. It is thus. +15 -0
- package/server/Routable/When you send a message first -> +8 -0
- package/server/Routable/const Modelconfig = { +5 -0
package/package.json
CHANGED
|
@@ -221,6 +221,9 @@ class Headers extends Services {
|
|
|
221
221
|
handle_security = async (name, request) => {
|
|
222
222
|
let route = await this.get_route(name);
|
|
223
223
|
|
|
224
|
+
if (!route) {
|
|
225
|
+
route = await this.get_route("*");
|
|
226
|
+
}
|
|
224
227
|
if (!route?.config?.security?.length) return true;
|
|
225
228
|
|
|
226
229
|
if (!this.check_security(route.config.security, request)) {
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
Storyline,
|
|
2
|
+
|
|
3
|
+
Assistant recieves a prompt.
|
|
4
|
+
|
|
5
|
+
It thinks it through, into type, and if type is activity, it determines the activity tool.
|
|
6
|
+
(This is a thought action, meaning it does not carry personality, it just takes memory and reasoning.)
|
|
7
|
+
|
|
8
|
+
Next stage is that it tries to resolve the selection arguments.
|
|
9
|
+
If tool or what have you, it uses memory, context argument and prompt to determine what information it can already put together to resolve the selected.
|
|
10
|
+
(This is the second thought action it carries out. They are thought actions because they are simply the agent reasoning within itself. And the world watching for an output / action it would come with.)
|
|
11
|
+
|
|
12
|
+
Once, all that is done, it sends its action to the tool service aka it simply calls the tool service. It meta information is included in the call. Such as the conversation_id
|
|
13
|
+
|
|
14
|
+
// At the tool service end.
|
|
15
|
+
|
|
16
|
+
When it handles the endpoint, What ever solution it gets, it returns an agent, which is just a profile. i.e the handling profile.
|
|
17
|
+
|
|
18
|
+
When godprotocol sees a response includes an agent property,
|
|
19
|
+
it calls the agency service response endpoint, adding the handler payload to the call, and the conversation_id provided.
|
|
20
|
+
Of course the platform i.e tool service must have third party authenticated the agent from them to the agent's own agency profile.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
The Story Board.
|
|
2
|
+
|
|
3
|
+
First entry is the new_message endpoint.
|
|
4
|
+
|
|
5
|
+
The user sends a message to that endpoint,
|
|
6
|
+
if a conversation is provided, we retrieve the conversation.
|
|
7
|
+
|
|
8
|
+
If not a conversation is provided, we infer one.
|
|
9
|
+
A conversation is simply an activity (aka tool) discussion.
|
|
10
|
+
|
|
11
|
+
There are three conversation kinds - activity (tools), feedback (preferences statements and corrections), pleasantry (small talks).
|
|
12
|
+
|
|
13
|
+
If activity, we include tool_id, and args.
|
|
14
|
+
If feedback, we include tool_id.
|
|
15
|
+
if pleasantry, not much,
|
|
16
|
+
|
|
17
|
+
Conversations also includes a spawn object, which is a {conversation, message} \_ids.
|
|
18
|
+
|
|
19
|
+
=================
|
|
20
|
+
|
|
21
|
+
Next is new_message,
|
|
22
|
+
So a message is sent.
|
|
23
|
+
|
|
24
|
+
We determine what categories the message is about.
|
|
25
|
+
Categories are - argument_resolution, new_conversation, abandon_conversation, or feedback.
|
|
26
|
+
|
|
27
|
+
First variable = m (the initiator)
|
|
28
|
+
Second variable = c (the resolver)
|
|
29
|
+
Third variable = x (the problem aka action)
|
|
30
|
+
|
|
31
|
+
Fourth variable = y (the solution)
|
|
32
|
+
|
|
33
|
+
mx + c = y
|
|
34
|
+
(Need item)(buy item) + (seller) = (item)
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
The flow is simple. It is thus.
|
|
2
|
+
|
|
3
|
+
When you create a platform, you register it to a central platform.
|
|
4
|
+
In this case, arena is the vote.
|
|
5
|
+
|
|
6
|
+
So every single platform is registered as a third party to arena.
|
|
7
|
+
The endpoint is able to recursively register the requesting platform under its requested permissions also.
|
|
8
|
+
|
|
9
|
+
Those platforms state their dependencies aka permissions.
|
|
10
|
+
|
|
11
|
+
Which arena would also have in its third parties.
|
|
12
|
+
|
|
13
|
+
When those platforms want to register new profiles,
|
|
14
|
+
they use the third_party endpoints of (signin, and signup)
|
|
15
|
+
|