Embeddings are created using OpenAI's ada model. They are stored in Supabase with the vector extension, which offers a simple way to compute vector similarities. Then the associated sections are added to the prompt context.
The way it went is: we built this as part of Motif for the past month, and our users loved it. Many asked for a way to add this feature to their existing sites, so we made a standalone platform that streamlines the process, and open sourced it :)
Haven't made a comparison yet but would love to hear about any findings. So far, for the intended use cases, meaning narrative docs with lots of text, images and code, it works really well. We're still breaking up the Markdown into sections and comparing embeddings as this strikes a good balance between performance and cost, but will also plan to let users experiment with other approaches, such as sending entire corpuses of text to GPT-4.
Nice work! Regarding your question on how to handle undoing a command on a shape that doesn't exist anymore, is there a way we could automatically recreate the shape?
Co-founder of Motif here. We're building Motif because we think that ultimately, there is no difference between a document and a full-blown website. The tool needed to author such docs should be at the intersection between a coding environment and a word processor, and leverage open web technologies. The goal is that, by building a platform geared for content creation, with a rich set of tools and helpers (think drag and drop, asset management, WYSIWYG editing, shared components, instant publishing...), we can make software development accessible to more people than just developers, and improve collaboration between teams that have been siloed apart in different tools.
Today, Motif is a collaborative text editor (based on Monaco + Yjs + Replicache) that runs entirely in the browser (thanks to esbuild, no local Node dev environment required). It also syncs with the file system so that you can use your tools of choice (we posted about this last week [1]). It supports MDX [2], Markdoc [3], React/JS/JSX, Tailwind CSS, and ES module imports. It features instant publishing (as a Next.js application hosted on Vercel).
Why MDX and Markdoc? While we do think that MDX provides the most versatile format and the most powerful API (with the Unified.js ecosystem, which we will soon support), we want to give optionality to experiment and choose what is best for a given situation. Other formats, like AsciiDoc, might also be supported down the line.
Sure! Motif is an MDX editor running in the browser, with a full-fledged JS build system inside (based on esbuild). It allows you to publish your content instantly (in fact, as a Next.js app, deployed on Vercel, benefitting from things like ISR to make your pages fast, SEO-ready, etc.). For instance, the entire Motif website is built on Motif, including the blog, as well as our docs: https://motif.land/docs.
Yes that's one of the goals, and CRDTs are pretty much built for this. Also, browsers are starting to support Progressive Web Apps (PWAs), which enables the websites/apps themselves to be opened while offline.
Yes, this is an interesting topic. In Motif, we are using MDX for the page content, which has an associated AST and a nice set of tools (Unified.js [1]) to manipulate it. We plan to use this to track semantic changes in the content, and act in an appropriate way. For instance, if the same block of JS code is changed, instead of merging, we can prompt the user with a diff and allow them to edit the final version manually (effectively transitioning from a synchronous to an asynchronous workflow). In simpler scenarios, such as text markup, we can use heuristics like the ones presented in Peritext [2].
We're in an exploratory phase on this. We have been experimenting with reading the .git folder to determine the current branch, and store this info alongside the CRDT in the client. Still early to say whether this is a fruitful approach or not.