181 karma · joined October 12, 2014
This is an interesting and deep topic, which we plan to share more about in an upcoming technical blog post. We are still experimenting with the best ways to constrain the LLM's output such that it always compiles as expected and "knows" when to use certain Dynaboard-oriented features like {{ bindings }}. At a high level:
- Code refactoring works through a recursive refinement loop of: fetching any relevant DB schema or existing component data -> initial generation prompt -> LLM output -> using tsc (or equiv) to detect errors -> feeding the errors back into the LLM recursively until a fixed point is reached -> format. In our experience it works really well for both simple and moderately complex prompts.
- UI components are first generated as an outline/scaffolding of components which map approximately 1:1 with HTML equivalents in an initial prompt, before being populated with their respective component properties in a subsequent prompt. There's a subset of properties that seem most useful to generate which we focused on for this initial release, but we are looking to expand that list over time.
One note: we have some lightweight persistent data stores built-in for convenience, like a key/value store. However, you're always able to build on top of your own database / API and most of our early users do.
[1] https://dynaboard.com/images/screenshots/DynaHacker_News.png
We will not be pricing per developer or per user, but rather usage-based. We aim to be affordable for applications at scale, because we believe the cost of an internal app should not increase linearly with your headcount.
We’ve designed the system for a few deployment configurations, with independent single-tenant and multi-tenant support on the control plane and data plane. The goal is flexible on-prem deployments that balance customer convenience with regulatory / privacy requirements. At the moment though, we’re focused on our multi-tenant cloud environment and making that as top-notch as possible.
You’ll also be able to eject your app out of Dynaboard. The code is yours, we aim to have the best editor available and convenient serverless hosting so that’s why you’ll stick with us.
We're building for early-stage technical teams and independent developers that want to reduce the iteration time on prototype -> production apps.
Multiplayer: We used the YJS project (https://github.com/yjs/yjs) as the baseline for our multiplayer system. We created a thin harness around the client and ended up implementing our own server-side architecture to handle relaying between the various WebSocket servers. More on how we do this soon.
WebAssembly: Rather than running your custom code in an iframe, we run it inside a wasm-based sandbox, a compiled version of the QuickJS VM (yes, it's JS-in-JS). This approach gives you synchronous access to most of the DOM APIs without sacrificing safety. We do some fancy ES6 Proxy management to implement the FRP-like data binding system inside the VM. In production, the browser runs the project's precompiled bytecode. In the future, we plan to support other languages with a similar architecture (Python via Pyodide, Rust, Go, etc.).
Code editing: We use Monaco, the same editor that VS Code uses. We've had to create a handful of custom extensions, including a few custom language servers, to get it to be aware of the VM environment. I'm a vim-er so we will definitely have a vim mode.
We're looking to make Dynaboard really affordable, especially for smaller teams, and entirely usage-based (no per-seat cost). Our goal is to price it more like a cloud infrastructure product and not charge for things that do not cost us money. We don't want to post something and promise something that we can't deliver on, and so we decided to table announcing the prices until we figure it out over the next 2 months. You can find the approximate structure of the pricing on the pricing page.
You can think of Cleargraph like a proxy for geth with some bonus features. You can point a local instance of Cleargraph to your own JSON RPC API endpoints using the helm charts we provide: https://github.com/dsys/charts. We're looking to make it even easier to use, so if you have suggestions please let me know.
We think it's important incorporate decentralized systems where it is practical (i.e. ENS). I'm aware of projects building the Ethereum blockchain secondary index features (for things like transaction filtering) in a decentralized manner, but haven't seen one live just yet. Maybe when they're live we can switch to them, or if you have ideas regarding Gun, would love to hear! :)
The primary "centralized" component is the privacy-preserving contact discovery, which we believe is a necessary evil. Afaict, any decentralized hashing scheme is susceptible to pre-image attacks due the space for phone numbers is small, which makes publishing the entire hashed address book leak everyone's info. Signal has a good write up on an improvement we may eventually incorporate that uses SGX: https://signal.org/blog/private-contact-discovery/
Right now we're working on some dApp/smart contract templates that use Cleargraph, and want to know what y'all would think is useful. Maybe something along the lines of a CryptoKitties clone, a token monitor, a todo-list with staking, or a graphical transaction explorer. Open to any ideas! :)
I've added a bit of documentation for the `all_orientations` parameter on POST /search and clarified what we mean by "rotation". By default, Match search for all 90 degree rotations of the given image. We're open to improvements on the hashing algo which would make it more flexible at the expense of accuracy when provided a flag.