mfester

Interesting. Could you share more about the performance characteristics of EdgeDB + TypeScript vs say Prisma + other DB?

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.

Thanks!

Yes, we plan to do this in background workers soon so that it can carry the load.

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 :)

Yes, this will come, we had to start somewhere. Would love a PR on this, should be straightforward.

Handmade, but indeed Tailwind.

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.

Not yet. We do support file sync though (https://motif.land/blog/syncing-text-files-using-yjs-and-the...) so you can use your mobile Markdown editor of choice.

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.

Would love your feedback! Our Discord is: https://discord.gg/MBMh4apz6X.

[1] https://motif.land/blog/syncing-text-files-using-yjs-and-the...

[2] https://motif.land/docs/basics/mdx

[3] https://motif.land/docs/basics/markdoc

Thank you!

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.

With pleasure. Feedback welcome! :)

Thank you!

Awesome! Happy to hear this :)

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.

Thanks!

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].

[1] https://unifiedjs.com/ [2] https://www.inkandswitch.com/peritext/

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.

We wish! Currently, the API is supported on Chrome 86+, Edge 86+ and Opera 72+: https://developer.mozilla.org/en-US/docs/Web/API/File_System.... It's all quite new, and we hope other browsers will follow.

Yes, the goal was to make pragmatic choices in order to make the data freely available, here and now, to other apps (most of which operate on plain text files), despite running in the browser. I do have hope that the POSIX file system still has its place in a "change-aware" setup, for instance by adding a folder, similar to .git, alongside the "final state materialization". Do you see a reason for this not to work?

I'm really thinking in practical terms, i.e. of how we can make this happen incrementally, without forcing a new standard that everyone needs to adhere to in order for it to work.

Indeed, there's always the risk of breaking a document, since we are dealing with raw edits to a Markdown/MDX/code file. This is very well described by the Ink & Switch team working on Peritext (https://www.inkandswitch.com/peritext), when it comes to WYSIWYG editor operations (bold, links, etc.). This is a more general issue of making semantically wise decisions in your merge strategy, and it's exacerbated in real-time collaborative settings (we sort of mitigate that in an asynchronous, Git-like workflow by reviewing commits / ensuring they compile before they are merged). We haven't dealt with this yet, but this will be really interesting, especially when it comes to merging code blocks.

Once we figured out the "CRDT trick", i.e. simulating file changes as CRDT update operations, it was surprisingly quick to implement. If you look at our repo [1], you will see that the code is fairly straightforward and succinct. But this is very much thanks to the excellent work of Kevin Jahns on Yjs [2], which has made it a breeze to work with CRDTs in an efficient way!

[1] https://github.com/motifland/yfs [2] https://yjs.dev/

The starting point for this work is really: how can we take what exists (text files) and make it work in a CRDT setting, without tainting the data in any ways. For instance, if you decide to host your data on Git, we want the repo to look exactly the same as if it was a regular code project. We don't look to add another standard on top of existing ones – for instance, we are not aiming to enable "CRDT version history" in the file system. This could of course constitute future work (something similar to a .git folder – CRDTs can be stored efficiently). But our main goal here is to show that browser apps have a way to free their data from the tool, something Excalidraw started doing [1], and which was a source of inspiration to us.

[1] https://blog.excalidraw.com/browser-fs-access/

No, we currently don't run into the issues that Peritext are addressing, simply because we are dealing with plain text. These issues will come up when we start working on WYSIWYG editing, but if we keep plain text as the underlying data format, it should not affect the setup described here.

That's still a shortcoming in the current setup. The API does not yet allow us to "track" a file as it is moved around on disk. So the best thing we can do is upload it from its new destination, keeping the original version where it is (we want to avoid guesswork and ensure no data is ever lost). We can likely optimize this. Would love to see the API evolve so that we can keep persistent file handles even after moving and renaming (including parent folders).

Totally agree that we need decent, open hardware, and that's why we're set on building it :) This will take some time, but in the mean time, we've launched a "Maker Kit" (https://makers.snips.ai/kit/) so that everyone can get started building voice assistants for their home that don't listen in.

The blockchain is a key ingredient in what we are trying to build, that is, 100% private AI assistants. We will detail this in our upcoming white paper.

Hi bluehatbrit. We will publish our whitepaper in a few weeks, which will thoroughly detail the usecases for our blockchain, and how it fits in our roadmap of building 100% private voice assistants.

And I do invite you to try out our voice platform, running 100% on-device on Raspberry Pi 3 or equivalent (and soon MCUs). We're on par with Amazon, Google et al. in terms of performance:

- https://makers.snips.ai/

- https://github.com/snipsco/snips-nlu

- https://medium.com/snips-ai/snips-nlu-is-an-open-source-priv...