paulbricman
commented
3 years ago An incremental update of the idea above.
- The
#dualrecipetag can be omitted, all recipes could be placed in a recipe folder to avoid this overhead. patterncould be replaced withinput, as it defines the signature of the recipe as a function, how information gets in.- Additionally, to better reflect what gets out of a recipe, an
outputfront matter field could also be provided. - Just like \1 points to regex group 1 from the input command, so should
#1point to the output of code block 1 etc. #0 should stand for the entire note once all blocks have been resolved (up to a point). - \0 could stand for the contents of the conversation before the call of the recipe. So backslash numbers refer to user input and the conversation, while tag numbers refer to block output and the note.
- The Dual code block only knows how to call another recipe.
- However, the recipe interpreter also supports javascript and python code blocks, interpreted on the fly. Their outputs can similarly be references with a tag number reference. Heavily inspired by this
With those modifications, a recipe might look something like this:
---
input: "Come up with a writing prompt about (.*)"
output: "Here's a writing prompt about \1: #1"
---
- robots: You live in a world where human beings are forbidden to work. Every job imaginable has been taken over by robots, even flying airplanes and writing books. You are not allowed to pursue any work-related tasks, just as robots cannot have a life of their own. When both sides realize they want to make a change, they rise up together and rebel against their governments to prove the power of the people—and bots.
- space: Interplanetary war has broken out and you're a mercenary who will fight for the highest bidder. Suddenly, news that your childhood sweetheart has been captured and is being tried as a traitor on Earth changes your mind, and you decide to rescue her instead.
- \1:
'''dual
Generate a paragraph based on #0.
'''
'''js
alert("This is a useless pop-up window containing a writing prompt about" + " \1: " + "#1")
'''Low-level recipes elegantly use js blocks to actually fetch stuff from the local server.
Progress towards solving existing issues and setting up a proper roadmap had been slowed in the past days by the fear of prematurely settling on an architecture and API design given that this space of conversational interfaces over personal knowledge bases is quite unexplored.
The following describes a suggestion for heavily restructuring the functionality and the codebase, a tentative something in between a spec and a user story.
Architecture
Dual is based on two components: the backend and the frontend. The backend is a server which exposes two main endpoints:
/extract, which returns entries from one's knowledge base based on a natural language description, with some options/generate, which generates text given a prompt, with some optionsHowever, the user doesn't usually interact with the endpoints directly. Rather, they use recipes. Recipes tell Dual how to answer certain commands. They can be predefined, user defined, or contributed by some other user. Recipes are simple Markdown files with the following structure:
If the user has this recipe in their vault as a note, then whenever they ask their Dual that question, they'll get the contents of the note as an answer.
The
patternfield of a recipe is a regex pattern. It can also house groups, which can then be referenced in the content.With this recipe, if the user tells their Dual
My name is John, it'll reply withHi there, John!.All this is cute, but not all that useful or interesting. Among the recipes there's also this predefined recipe:
Now, this is good old descriptive search, expressed as a recipe which makes use of the
/extractendpoint. When askingFind a note which describes a metaphor between machine learning and sociology, it'll answer with a list of results based on that GET HTTP call made behind the scene to the endpoint.But if you wanted to customize the command triggers even for this predefined command, you could just wrap a new recipe around it, or change the original one. Here's a wrapper recipe:
Cool, you just made your Dual a bit edgier.
So this is how you can express good old descriptive search and fluid search as recipes. What about good old open dialogue?
Now, when you ask it a question with that structure, Dual assembles the relevant notes in there, composes the prompt further with your query, and then generates the response. Good old open dialogue, but expressed as a recipe. Every command becomes a customizable recipe.
Now you want to teach your Dual to come up with writing prompts, you create this recipe:
You ask it
Come up with a writing promptand you get some in return.Sure, there are technicalities. The note contents until the generate call should be piped into it as the prompt. The endpoints are shorthand for localhost:5000/..., but you could perhaps change them to refer to a hosted instance at some point in the future. You could make calls to other people's instances through recipes. You could tap into any API through a recipe, turning Dual in a sort of conversational hub. Regex groups have to be entered when making calls. URL's have to be encoded properly because they contain text. Extract calls should know if to supply filenames or contents, through parameters probably. What should a recipe return, the entire contents or the result of the last call? Perhaps a metadata setting. A bunch of things still to settle on.