Yes, we are still using XML to represent the document content, to represent the document as a flat list would require some research into something like Automerge's Block markers https://automerge.org/docs/reference/under-the-hood/rich-tex... which we don't have the funding to look into right now, but hope to work towards in the future.
We will have better support for ProseMirror's position mapping, but I'm not confident that we will make any progress on this specific issue, since it requires a much larger refactor than what we are contracted for (suggestions & versioning). For selection mapping specifically, we can of course make an effort here to fix it, but the underlying limitations of the split node operations would still be there.
> I don't know where this popular belief came from.
It may be worth reading the whole paragraph of the blog you referenced...
> Figma isn't using true CRDTs though. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation.
> It’s also worth noting that Figma's data structure isn't a single CRDT. Instead it's inspired by multiple separate CRDTs and uses them in combination to create the final data structure that represents a Figma document (described below).
So, it's multiple CRDTs, not just one. And they've made some optimizations on top, but that doesn't make it not a CRDT?
I'm actually in the middle of rewriting the y-prosemirror binding with Kevin Jahns as we speak, we hope to address a number of the fundamental design choices that were made 6 years ago. I did a presentation on this at FOSDEM this year if anyone is interested in some specifics to the approach we are taking for this: https://fosdem.org/2026/schedule/event/8VKQXR-blocknote-yjs-...
I feel like this post is overly hyperbolic about the choices that an Open Source maintainer made years ago, and no one seemed to care enough to pay him to rewrite it.
FWIW, I'm literally working on rewriting the y-prosemirror binding today with Kevin Jahns, the creator of Y.js and wrote the initial binding. Yes, the current binding has it's flaws, but we hope to flush out the most egregious of them with a completely different design which I made a presentation about at FOSDEM this year: https://fosdem.org/2026/schedule/event/8VKQXR-blocknote-yjs-...
I think it definitely depends on the country, there isn’t a one-size fits all answer to this for the countries in the EU.
Even in this example, the French are building this in-house, but the Germans are repackaging this into their suite. And the Netherlands is on their way to do the same.
So the approach would be different depending on which country you approached.
My advice to you would be to follow government events like Hackdays to get yourself in front of people who can point you in the right direction
“Content over form” so you don’t really need all the formatting options of something like Word when you are just trying to write meeting notes.
They are definitely trending more towards a wiki, but it is still early days for this whole experiment. Though, many of the municipalities in the French gov are using it for their day to day work so it is clearly useful in some capacity. I don’t have numbers, but it’s definitely respectable
I made a collaborative editing framework based on Y.js.
I think it has many advantages over existing solutions like hocuspocus, Y-Sweet, Liveblocks and others. Mainly, it being built as a library (and framework) allows you to build in assumptions for your application. Just this weekend I had a short talk about it at FOSDEM. Let me know if you are interested!
We will have better support for ProseMirror's position mapping, but I'm not confident that we will make any progress on this specific issue, since it requires a much larger refactor than what we are contracted for (suggestions & versioning). For selection mapping specifically, we can of course make an effort here to fix it, but the underlying limitations of the split node operations would still be there.