Skip to content

feat: add adr for comments storage #1599

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: suggestions-adr
Choose a base branch
from

Conversation

nperez0111
Copy link
Contributor

@nperez0111 nperez0111 commented Apr 9, 2025

This is an explanation of the trade-offs between the different places you can store comments. I was not certain where the best place for this sort of document would be, so I just made it into an ADR for now.
If you have feedback on the doc or where it should go, let's discuss in the PR

The document can be reviewed here: https://github.com/TypeCellOS/BlockNote/blob/01ff8be74671ac5d1854692f15ca105a90d931ba/adr/2025_04_09-comments/README.md

Copy link

vercel bot commented Apr 9, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
blocknote ✅ Ready (Inspect) Visit Preview Apr 9, 2025 11:48am
blocknote-website ✅ Ready (Inspect) Visit Preview Apr 9, 2025 11:48am

@@ -0,0 +1,131 @@
# Y.js Document Comment Storage Options
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of useful stuff and great detail in the doc, but I think if we structure it a bit better it will be a bit clearer.

Mostly, it feels like the goal of the document is not very clear. Is it:
a) explaining the challenges with storing comments with yjs
b) explaining the overall options of where users can store comments with BlockNote

(similarly; is the audience all users of BlockNote, or ourselves as maintainers?)

I feel currently, the goal / introduction of the document make it sound like we're addressing (a), but then most of the document (i.e.: the solutions) address (b). imo, this is causing some confusion.

  • if (a) is the goal, I'd really focus on the challenges re. yjs, and only very briefly mention that you could also implement your own ThreadStore to store comments somewhere else, but don't go into detail (i.e.: drop everything re. "comments separate")
  • if (b) is the goal, I'd first introduce the concept of the ThreadStore, and then the different ThreadStore implementation that we already have, with the pros / cons and implementation notes.


This approach is not yet implemented, but is a good approach if you want to have a view-only user without access to the document content. If you are interested in sponsoring the implementation, please reach out to us at [team@blocknotejs.org](mailto:team@blocknotejs.org).

### 4. Comments Stored Separately, Without a Central REST Server
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure (depends on goal and audience, see above), this section is very relevant atm.

Part of this is relevant to people who'd currently implement comments; namely, should I use a separate YDoc or not. The big trade-off there is whether you require view-only users that are not allowed to read comment data

(Of course, we could have a (separate?) short note about ideas regarding a decentralized / p2p comment solution, or about the trade-offs of marks vs outside positions, etc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants