Guidance on third-party extensions and BlockNote’s extension ecosystem

[gsingh-ds]

First of all, we at DefenseStation really appreciate the BlockNote project and the work the team has done.

We have been using BlockNote since around version 0.15, possibly even earlier. Over time, we have built several extensions for features we needed, and we also maintain the Awesome BlockNote repository.

More recently, we have worked on extensions for features such as superscript and subscript, math support, comments, and export functionality. We built some of our own export tools before BlockNote introduced its commercial PDF and HTML export features.

We want to make sure our work supports the BlockNote ecosystem without conflicting with the project’s commercial plans. We understand the importance of those commercial goals, and we are open to supporting them in the future.

We would appreciate some guidance on a few questions:

1. Are there any boundaries or guidelines for third-party extensions?
2. How does the team decide which features belong in the core editor, which should be official extensions, and which are suitable for community extensions?
3. Is it reasonable for us to continue investing time in building and maintaining extensions for features that may already be on the BlockNote roadmap?
4. Would the team prefer these extensions to remain in our own repositories, or would contributions to the BlockNote organization or project be welcome?
5. Are there any types of extensions, particularly around commercial features, that community developers should avoid publishing?

Our goal is to contribute positively to the ecosystem and avoid duplicating work in a way that creates confusion or conflicts with the project’s direction.

Any guidance on how the BlockNote team sees the future of third-party extensions would be very helpful. Thank you again for all the work you are doing on the project.
@YousefED

[YousefED]

Thanks for reaching out and running this by us! I'll answer 1-by-1:

1. Are there any boundaries or guidelines for third-party extensions?

As BlockNote is open source, we welcome anyone to extend the code, create extensions, etc. (of course, as long as you stay within bounds of the licenses). We'd love to improve our extension surface further, for now this is documented here. Contributions or suggestions for the extension surface are always more than welcome as well.

2. How does the team decide which features belong in the core editor, which should be official extensions, and which are suitable for community extensions?

We're slowly making the editor more pluggable, to avoid large bundle sizes of the core packages. This means you'll see us shipping features in separate extensions more often. Community extensions can fill a gap for features BlockNote doesn't provide yet or are too specific (i.e.: only interesting for a handful of users) to maintain / document / expose in our core repositiry

3. Is it reasonable for us to continue investing time in building and maintaining extensions for features that may already be on the BlockNote roadmap?

This is up to you. You can always check in before you're developing an extension to see if it's on our near-term roadmap.

4. Would the team prefer these extensions to remain in our own repositories, or would contributions to the BlockNote organization or project be welcome?

Contributions are welcome, but do note we do try to hold a high standard for contributions so we can keep maintaining the codebase well into the future. In line with the above, we're unlikely to accept contributions to features we think are only interesting to a handful of users. (these are a better fit for community extensions)

5. Are there any types of extensions, particularly around commercial features, that community developers should avoid publishing?

We'd appreciate it if community extensions don't provide the exact functionality that we provide as XL packages - so we can keep supporting the core team with commercial licenses for those.

We'd also love to host a community extension / block gallery at some point to enable ecosystem contributions.

@gsingh-ds Hope this helps. What kind of projects are you using BlockNote for? Always great to learn.

[gsingh-ds]

Thanks, this is very helpful and gives us a much clearer understanding of where community extensions fit.

Defense Station is a cybersecurity company, and we use BlockNote in a product that helps customers create and maintain cybersecurity policies, standards, and procedures.

One of our main requirements is allowing users to comment on documents while preserving a reliable audit history. In some workflows, a document may need to be locked against content changes while still allowing comments. Since comments currently modify the document content and mark it as changed, we started exploring a separate approach. This led us to build several related extensions and components, including commenting functionality and Yjs backends in Go.

That work naturally led to our questions about the direction of the extension ecosystem.

We understand your position regarding the XL packages, and we will avoid publishing extensions that provide the same functionality as BlockNote’s commercial offerings.

We also maintain the Awesome BlockNote repository. Are you comfortable with us continuing to host and maintain it as a community resource?

Also, when you receive feature requests that are better suited to community extensions, please feel free to tag or point us to them. We would be happy to explore whether we can help.

Thanks again for the detailed response.

[YousefED]

We also maintain the Awesome BlockNote repository. Are you comfortable with us continuing to host and maintain it as a community resource?

Of course, we love initiatives like these!

Since comments currently modify the document content and mark it as changed, we started exploring a separate approach.

Yes, this is currently a limitation. We hope to address this later this year in collaboration with the Yjs team. Glad you found a different workaround for now!

Yjs backends in Go

Exciting! Focusing on performance? What are the number of documents / clients you typically host?