Tech Status Update Q&A
Boxel UI & the OpenAI, Cardstack Workflows & more
What is the most important innovation behind Boxel?
The most important technical innovation in Boxel is that it’s an operating environment in which the logic of the app can be added or changed at a code level and the changes immediately effect. No build steps or deployment is necessary. This enables no code-style UI actually to change the code. It also enables AI that generate code to apply changes to the running code as part of a chat.
How can we test the AI assistant from the Boxel UI?
AI generation requires an API key with OpenAI and a Matrix chat server, which marshalls the communication between the Boxel UI and the OpenAI API. Our current generative system prompts are using GPT-4, which is powerful, but slower and more expensive.
We are working to back porting a lot of Card / Boxel code generation prompts to use the faster and cheaper GPT3.5 Turbo with custom tuning (https://openai.com/blog/gpt-3-5-turbo-fine-tuning-and-api-updates), so we can offer a minimally-gated hosted version of Boxel with AI assistant for the Cardstack community to try and still manage the OpenAI API cost.
What is the current status of the workflow designer?
Our workflows are a collaboration between people (and bots) using a chat room as a common shared context, using the Matrix protocol as persistence and transport. The sharing of cards manually is the foundation of cross-organizational workflows. Think of email trails and PDF attachments for ordering custom products with a vendor. A workflow designer is about scripting automation, which in our architecture is implemented as a Matrix chatbot.
Our AI content generation feature in the live app is already based on this pattern (the AI bot is a Matrix chatbot and shares card data with OpenAI). Extending end-user bot creation (with or without AI behind the scenes) is a planned future feature.
How will different apps that are already developed leverage each other? (Wallet, Boxel, CardPay)
We plan to port all of our existing (d)apps using Boxel as a business and display logic composability runtime. Payments, merchants, wallets, scheduled payments, balances, currency, and denominations can be refactored as cards/boxels, so they can be linked and composed with Web2 concepts like customer, vendor, fiat payments, invoices, quote, purchase orders, etc.
Web2 SaaS apps and Web3 dApps are built on very different full-stack architecture. With Boxel, they are all built on the same TypeScript-based model and templating system, allowing us to bridge Web2 and Web3 use cases.
Will it be possible to use current Matrix clients for communication and attach cards or should a new client be developed?
In the first implementation, we are focused on having a first-class experience with the sending and rendering of cards within the Boxel environment. The matrix protocol is considered a storage protocol in this first phase. While it is possible to see the data that has been sent in JSON format, other matrix clients will not be able to display or render these cards directly.
We plan to add a pre-rendering pipeline so that we render a card into a format that can be displayed in other Matrix clients as an enhancement in future releases. However, to modify those cards you will have to get the URL for that particular Matrix chat room and open it within the Boxel environment to activate all the editing features. But you will be able to see what has been discussed and shared using these pre-rendered HTML snapshots.
As an architectural principle, we want to map all the boxel-specific features onto standard Matrix APIs and data structures so that official and third-party clients will be able to make sense of the contour of who is participating and what has been shared even if they cannot enable editing or automation specific to our own concept of a workflow.
Stay up-to-date
- star Cardstack on GitHub
- join our Discord channel
- join our Telegram group and announcement channel
