What's cool to see some references to what we're doing already and the power of open source
so that's really cool to be in a very collaborative room.
So we're trying to build like a modern blockbase editing experience for the open web.
So quick run through.
I want to share like okay what we've been up to past year mostly and look a little bit
forward to next year.
First a little bit of an introduction to block now.
We'll do a quick demo to show you how it works for those not familiar with it.
We'll show what we've done mostly in 2025 and kind of like our ideas of okay what's ahead.
So for those who are not familiar.
Here's like a quick 10 second overview of what you can do with our editor.
So it's up.
We started building this a couple of years ago when we did an editor like this for ourselves
that we noticed okay this is actually a lot more work than expected.
It was hoping there'd be something existing that we could really easily reuse.
And though there was great low level open source libraries it was still a lot of work
to build something with a good UX and a good developer experience on top of it.
So we started with block now and the idea is okay we have a good UX included.
So notion style blockbase UX including all the UI components that you might need.
Is your APIs so no low level position juggling for those who are familiar with lower level text editors.
Blockbase design and internally we're proud to build really on some high quality open source libraries like pros mirror for
managing the DOM content editable and YJS to power collaboration with CRDTs.
We started kind of spitting out of a research project sponsored by AnnelNet.
And then the last one and a half years.
So Alex mentioned it and I think Bill and also mentioned it.
We've been really proud to unfortunate to collaborate with Zemdus and Dinem from France.
They're building a, they reached out one a half year ago like hey we're building last week ducks in our collaboration,
which is like a notion style collaboration documents collaboration products.
And we're using block for not for it. It works great.
Can we help you take it to the next level?
We also need this and this and this. So that's also really accelerated our product and organization last year.
Besides that, we're also supported by industry.
So now you see more and more sponsors of the last year.
I think 2025 for us was really a year where we went from something that started as a side project to a small team.
So it's like four of us now with a mix of different sponsorship models.
One thing that's core to block now is blocks.
Nothing to do with block chain but about the cool little pieces in the editor just picked out here.
Why blocks and why this kind of editor?
If you look at different formats existing, so let's position yourself a little bit like what we're trying to be.
We're not like a pure markdown editor. It's a little bit too limited if you want advanced formatting or colors or something like that.
That's not easily possible with simple markdown editor.
And we also definitely don't want to be a word style editor because all of us have seen these kind of like word documents.
That have a super inconsistent layout and design because you can change the font here and everything there.
And so you kind of end up with a little bit of a messy thing. So that's also not our goal.
What we want to do is have a better UX and for us the blocks are the answer to this.
So it helps blocks help users to create structured content naturally.
And yeah, we call that prioritizing content over form.
So you end up with nice and structured documents.
And this same principle also really helps in the developer experience.
So because everything is a block you can easily address it by an ID.
You have a clear schema of what kind of blocks are allowed in the document and it makes it easier to work with as a developer.
On to Nick for a quick demo about that and I'll need to try to hold this with you.
Okay.
Yeah, so what I want to go over here is a little bit about how you actually use block now in terms of the API and such.
So over the past year we've put a lot of effort into the ability to customize the editor.
So you'll see here that I have a very simple document editor so you can see that there's a bunch of elements that you can add to the editor.
So all of these are blocks that are available by default and built into the system.
And on the left hand side you can see all of the code that it actually took to get that to happen.
So what we're really trying to go for here is a really easy to use out of the box experience.
Whereas many other lower level editors tend to force you to build out all of this content.
Yourself rather than it being provided by default.
But what we've done on top of this is, well actually I should go over the code a little bit.
So you'll see here that we block notice based on we're using React as the framework.
And you'll see that there's this used create block note.
Hook that actually gives us an editor instance and then we can render it out.
So what I'm going to show here is actually adding to the schema.
So what you'll see here is that we can extend and add additional features into the editor by extending its schema.
So you can choose what blocks you actually want inside of your editor.
So what I've done here is created a very simple alert block, which we've we've spent over the past year.
One of the major refactors that we've done is worked on the actual API for defining these custom blocks and adding them into the editor.
So block note in general we heavily focus on type safety structure schema.
Like that's kind of our whole bit is that everything in the editor it's content is completely type safe.
It's always valid content.
So what you'll see here is that there is this configuration that describes what an alert block has as.
So it's the blocks type so it's an alert block and the properties that it's available to have.
So this is defining a way that it can be validated at runtime.
And the content that the actual alert block supports.
So in this case it's it's allowed to have content inside of it.
So you'll see that there's a very simple function for describing how to map that block, which is just a json object at this point and how to map that into something that actually renders into the editor.
So what we can do here is go ahead and actually add that block to the editor.
So again, very simple example so you can actually see how it actually renders out.
So you'll see here that we have defined this severity property for the alert block.
And defined that it should change its background color based on that severity.
And I had added a button that actually will insert that new element, the new block into the editor.
So what I would really like to stress here and show off is that everything is type safe.
So you can see that the actual properties of the alert block are being validated.
So you can actually also see the different types of blocks.
Since we've extended the block note schema here, there was a number of blocks that were already built into the editor.
And so we were just adding on the alert block to the list essentially.
So you can see that there's a number of other.
You see that there's a list of all the blocks that are available in the editor and all of this is defined in a type safe way.
So yeah, I think that's the majority of what I wanted to show off.
We spent a good amount of time over the year to work and refine the API for defining these blocks and allowing for more customization into the editor.
Yeah.
Nice and I think it was important to keep in mind with this.
So thanks for the demo. It's like okay because we're.
Thank you.
Because it's an editable service right.
It's a little bit different than when you're just making a web app.
So having this type safety.
How are you doing?
Yeah.
Okay.
Cool.
Because an editor is a dynamic service.
So these kind of things are a little bit more complex.
And when you're building a regular app so hard.
So looking back at 20 25.
So what we've been focusing on and some key numbers again.
Yeah, I think a project is really taking off now and that's cool to see.
And I think you can see it in these numbers.
So we've done over 60 releases.
Lots of PRs and we've grown from I think it was like 30k.
This is like mpm downloads, right?
It's the best set that we have.
But the question marks, but at least it was like 30,000 about a year ago.
And now we're like 120 or 130,000 weekly downloads.
It's really nice to see the adoption.
And apparently that to see our project really resonates with the community.
Yep.
We worked on many different things.
So definitely a lot of features going from export system.
I'll go over some of these in a bit.
A lot of like API enhancements.
But I'm even even more proud that we were also able to also really invest in the core.
That has been around for a couple of years.
But you really make sure that the core is also sustainable.
And you're being able to re-factor parts of this.
So for example, this custom block API that Nick just showed,
like with which you can make your own alert block in the demo.
Last year we migrated all our default blocks to actually also use the external API.
First version of our AI integration and it's been designed.
So you can have an agent understand the documents and then hand in hand with an AI.
You can understand the documents.
So you can ask questions.
You can redact the documents.
So ask it to make changes or write new content.
Hand in hand.
And you can really integrate this.
Of course with your own language model.
So you're not bound to any surface or whatsoever that we build.
And it's done in a way.
Yeah, what we call like human in the loop.
So the AI, you really see it writing as a collaborator.
You can accept and reject changes.
So the end user is still in control.
It's not like some random robots taking control of your document.
Here's a more advanced demo.
Some of this is still to come.
But most of it is available already.
So here's a template document.
And now I demonstrate that it's also possible to connect certain tools.
So look up some information about the European Union.
It does a web search on the back end with an AI tool.
And now you see it making those suggestions in the document.
I can review them.
And as a user I can say, OK, accept these changes and then they become part of the document.
So connecting a web search might be one thing that you like.
But maybe you want to connect like a rag system or your own database or have it look up something about your colleagues or about other documents that you've written earlier.
You can make all these integrations yourself.
Yes.
Suggestions and versioning.
I'm really looking forward to this.
This is something that we expect.
We've done a prototype on this last November and December in close collaboration with Kevin Yans.
From the YGS project.
This was sponsored by Deanum and Zendis.
And so this is about what we call asynchronous collaboration.
So making different versions.
I think I'm in front of the screen.
See being able to see and they've changes between versions.
And also to go into suggested mode.
So what you might know as track changes suggestions.
You can maybe have a user that doesn't have permissions for the base documents.
But once you suggest some changes and then the owner of the document can accept or reject those changes.
And we want to as part of that.
We also want to make a possible so that you can store metadata.
Keep in the version history.
Keep a complete overview of who they want and when.
So we call that attributions.
That's going to be.
Let me quickly see.
We're hosting a local first dev room tomorrow.
And it's going to be a presentation about the technical stuff behind that.
And a little bit of sneak peek of what's upcoming and also what's coming in the new version of
BIGS to enable all this.
Yeah.
Some other things that are ahead of us.
So I mentioned a sync collaboration.
Of course there are some features that we have to remind that we would love to work on.
We also want to keep working on some of the foundations like we have done last year.
We've always things to improve there.
Well, I think this was illustrated very clearly by us in the last talk.
So we don't want to lose a side of that.
And I think also as our project might mature as we have more people working on it.
As we have more people depending on it.
I think actually there's also.
We want to spend more time looking at the overall ecosystem around blocknotes.
So that means okay, how can we be transparent in terms of our roadmap?
How do we govern the project?
But also thinking more about things like extension systems.
Can we make that even easier?
We've done some investments in the extension API last year.
But can we make this even easier?
Maybe like extension gallery where the community can create and share extensions, etc.
But also think about other interoperability related features like standardization of these kind of documents.
Yeah, and really look beyond just the editor or just the new features, but really at blocknotes as a project.
Thanks.
There's seven minutes for questions.
We use YGS CRDT for powering the collaborative features.
Basically we think like YGS is kind of like a industry standard for this.
We also directly work with Kevin for this kind of more advanced features.
We always keep an eye on different things.
So tomorrow on the local first demo, I think there might be a session related to Loro as well.
But really it is like okay we're pretty into YGS at this moment.
So I've done haven't done like an advanced comparison.
I'd make might be more into this topic.
But maybe that's more on the side.
Yeah.
Yes?
I worked in the company, which was using the solution.
For me, because how do you read about them?
And I don't really speak about 80 things in the community.
And now I'm going to move to another company.
I don't know what they have, but I have to suggest them.
Would my life be there?
Nice. Thanks for your questions.
The question is, was difficult for you.
I expect for accessibility reasons to work in a notion that the previous company that you worked,
and would your life be better working in block-not.
It's a little bit challenging to say because the notion is like an end user application,
and we are just like an editing service.
So also very much depends on the editor around it.
We've done some sprints on accessibility, and we expect also a collaboration with some of the sponsors
to do larger sprints on top of accessibility this year.
So I can't guarantee you that as of this moment,
but I will be really happy if the end of this year,
I can say with 100% confidence.
So let us give a try to accomplish it.
Will I?
Yes. So I already said that we are using block-not-not-not-appal project
and of course we extended this schema to have links to work packages,
which are my entities in our project.
But I don't know the good ideas that I have in a year.
Like, how my schema should actually should've looked at it like in the beginning.
in the beginning. So my question is, in your example, you had an alert with, I think, like,
for a very used, let's say we replace Aera by Adal. Adal. And we want to migrate, let's say,
100,000 documents, change that. Is there any concepts how we can do this? Like, oh, yeah,
we can prove that, make this structure. So the question is, okay, how to deal with
migrations of the schema. So let's say you support the specific kinds of blocks.
And let's say you change the severity that make them out from Aera to Fatal. I'll skip
the Spanish part. How do you go about that? I think that's a good question.
There is, as in most migrations, this is, I would say this is similar to most migrations.
So at this moment, you have multiple options. Like, either make your new application
compatible with both formats. Then on the clients, you can choose to either upgrade it
to show the same interface when it's Aera or Fatal. Or you find a way to migrate your data.
I know there has been quite some research in systems that kind of like keep migrations
in the clients and automatically try to upgrade things. I know that are currently
react. So most of the UI components are based on react. So we keep the option open for the future,
but I don't see it happen this year.
I have a follow-up on this in Crystal, the project from Twiki, the audio.js.
And so we have plenty of modules that we don't specifically to allow the integration of blocks.
So we have plenty of modules that we also submit to the modules of blocks.
And I have a follow-up to the map also. In Tenzu, we use block-plat and we are in Angular.
And so, if you want, for example, of block-plat working in Angular, and I should focus on this