Flair AI is a design tool for AI powered product photoshoots. Using custom image models, FlairAI enables ecommerce brands to capture their products in virtual environments while preserving the brand identity and details of their product.

Antonio Cao, co-founder of Flair AI, uses a self-hosted version of Y-Sweet, our open source Yjs sync engine for collaborative editing. Antonio and I were also classmates back in college, so we recently got together to chat about his work on Flair AI.

---

To start, could you give an overview of the different components of your service? How does Flair AI work? Say you want a fashion photo, you can directly upload a photo of your clothing item to Flair AI and click “generate” with a given template. That’s the most straightforward way to create an image.

But a lot of users are using custom controls to better preserve their brand identities. For example, we give users a way to train a model based on their product styles. This lets them generate a lot more variety while maintaining the details of their product.

Why is multiplayer important for this kind of product? Multiplayer is basically a requirement. Figma really pioneered multiplayer for design, but once Canva and everyone else added multiplayer, it became a standard. Users have come to expect multiplayer for any design tool on the web right now.

How did you find the multiplayer solution that worked for you? Could you describe your discovery process? There are a number of open source and closed source solutions on the market. Liveblocks is probably the more famous closed sourced solution. And Yjs is probably the most famous for open source.

From the get go, open source was definitely the priority, the preferred solution.

Mostly because we can tweak the solutions to work for us, especially because tools like Yjs still need to be customized for drawing-like design tools. We needed to be able to hack around a little bit to get the right solution.

There are lots of examples out there for building multiplayer design tools, but those examples have a lot of assumptions baked in, especially about where the data and authentication stuff is stored.

Because we already had a lot of the backend logic built, we didn’t want to migrate our entire backend logic to another system. It made more sense to bring a tool like Yjs and Y-Sweet into our existing architecture.

How did you ultimately land on Y-Sweet as your Yjs sync engine? Some of the other Yjs providers are just not mature enough that we can run them. Y-Sweet’s documentation was just more comprehensive. We saw the examples and how well everything integrated.

And frankly the moment I realized Y-Sweet was made by Jamsocket, it became a no-brainer.

What were some challenges you faced in changing your data structure to use Yjs? Yjs is mostly like JSON, and our internal documents are also JSON shaped, so that's fairly easy.

Migrating from a JSON to a YDoc is also pretty easy. The main difficulty is making sure all past assets are now shareable.

Let's say, we have images stored in Google Cloud, and they have their own authentication and permission system. We also need to make that play well with Y-Sweet.

And how have you liked self hosting? We chatted before about how there wasn’t a very visible cloud version at the time you started using Y-Sweet. One main benefit with self hosting we found initially during migration was being able to write custom scripts to import and export documents.

We also still have active documents that were created before we added Yjs, so we were able to write custom services to keep two versions of the document in sync.

We’re actually working on some new Y-Sweet features. Paul, maybe you can share a bit about what’s coming next?

Paul: I can share our open source roadmap.

One of the features I’m most excited about is the history API. Yjs structures document data in a way that makes it really good for storing incremental updates. So what we want to do is store an entire document's history, so you can go back in time in, say, 15 second intervals.

And we can do that without storing the whole copy of the document each time because of how Yjs structures the data.

Antonio: That’s really nice. There's another open source package, Automerge, that does this, but it’s more expensive and heavy.

Paul: We’re also working on read-only client tokens, which will bring improvements around permissions.

Antonio: That’s super important.

Overall, we’re investing a lot more resources on open source Y-Sweet, so if you have any feedback, let us know. We don’t always know who uses Y-Sweet and self-hosts, so it’s super cool to learn about how you’re using the service. Totally, really like the product so far.

Thanks for taking the time to talk. Thanks for having me.

---

If you're using Y-Sweet and are interested in chatting with us, please reach out. To get started with Y-Sweet, check out our quickstart.