BlockSuite: An open-source Notion-like editor with multiplayer support
blocksuite.affine.pro
blocksuite.affine.pro
I want to be able to open a document in read-only mode. Otherwise, while just navigating through pages or reading content, it's far too easy to accidentally add text to a block by pressing anything on the keyboard, or move things around with an accidental drag of the mouse.
I've been reprimanded several times for errant edits to company wiki pages because of this...
The problem occurs when someone accidentally drags things around, or has the wrong window open when typing in text and you end up with "ls" and "exit" scattered randomly throughout the doc.
.. okay it’s mostly a misfeature because it’s the exact same input gesture as selecting text, but you have to remember that there is text selected / ensure that no text has been inadvertently selected.
Another case where making the user remember things can cause a problem is hybrid cars, where the driver needs to know the state of the hybrid battery because the responsiveness of the brakes and acceleration change depending on it.
the same thing would happen in word/google docs/etc
Yes, but not accidentally. You should press an [Edit] button which would take you to another URL to edit the page.
Is it really such a foreign concept that people want a dedicated editing-focused mode whose source is published into the final wiki page for viewing? Is this not how basically all tools worked pre-Notion?
Do they? Then export your documents to an immutable website. That's why those options exist. Personally I don't want that. I want to edit my content fast and the hybrid-solution doesn't bother me. So we are talking here about a conflict of interest, not an anti-pattern. And solutions for this already exist, maybe they should just advertised more prominently?
> I want to differentiate content editing and content viewing much the same way in software development you edit source code which is then built into an immutable read-only artifact.
I don't read the compiled artifact, I use it, which is very different from what we are talking here. A more equal example would be reading code on github or reading in a code editor.
We want to serve people who've used apps like those with their preferred writing experience.
If Notion had to be everything-editable-by-default, make it so that changes need to be explicitly committed and saved, much the same way one would do with Git. Otherwise it becomes impossible to track down these kinds of accidental mutations to the document, much less even realize that they have occurred.
On that note, I'm increasingly considering making my Emacs open all files read-only by default. When coding, I'm usually viewing many more individual documents than I end up actually editing - and multiple times a day, I end up accidentally typing (and then immediately deleting - muscle memory, this) a character into some file I was reading - and causing a spike in CPU usage, as the Language Server tries to reprocess the change. $deity forbid I do this in a widely-used header file - if I'm not quick with undo, LSP will churn through dozens of translation units before it realizes the edits were reverted.
This is not a big deal - usually just the cooling fans spinning up for a few seconds, and the editor (or whole system) getting slightly less responsive. It's just that the "slightly less responsive" part is really jarring.
Spitballing bad ideas somewhere in the ball park of what could be prototyped: - Editing locked by default and locked whenever a clear non editing action occurs. Editing unlocked by right swipe, double click, enter key or something similar. Editing unlocked by looking at the text cursor.
A little editor/reader toggle button would go a long way here.
But for a lot of people that never do that, that's hard, the more closer edit mode is to reality to easier it is to understand what it will look like and the less brainpower it takes the creator. But yeah in some cases with notion the difference between read and edit mode is not significantly indicated.
There's a certain sort of worker that really leans into that as their version of "easy async collaboration" but is actually just putting the burden on the recipients to make sense of the author's journey and thought process, instead of putting more effort into more-infrequent-but-more-curated updates.
This makes me happy, because I switched to Obsidian primarily for local-first file storage in a platform-agnostic format. I've learned to love many things about Obsidian and am writing a few plugins myself, but there are still several Notion-esq functionalities I wish I had, and I find myself handing off between Obsidian and other webapps for certain effort, like team project management.
I used to get far more excited to explore new projects like BlockSuite, and I really appreciate their documentation, but I find it hard to justify allocating time to reviewing and trying out new tools when I still have much more improve on with my Obsidian usage; this is especially true of newer projects where I'm unsure of their shelf life.
To assuage my internal conflict I remind myself that I think plaintext is fundamentally the right choice for much knowledge collection, and I'm proud to say that if the internet shut down, I'd retain a significant growing fraction of my personal data.
I did try obsidian briefly, but eventually gravitated towards Notion for knowledge and project management - but found that the bulk of the content I put into this would eventually go stale/unused simply because content was not linked and would instead be held in a table, within a project/area full of other pages of notes. I then found myself on Logseq for the reasons mentioned prior.
I wish they have a offline electron app.
But it comes with its downsides as well. For example cross block selection doesn't work.
If the entire page is one big editable area, then it becomes difficult to embed complex blocks like "kanban views" and calendar.
I guess we should think beyond contenteditable at this point and separate rendering layer from input layer[1] - sort of like how Google Docs has built its editor.
But writing a rich text editor is not just a text-editing problem. It essentially needs you to build a layout engine itself (like webkit) that knows how/when to recalculate and draw the affected parts (render objects) when the rich-text changes. Why? because baking in tables and image-wraps and other complex resizable blocks affect other elements around/after it.
Bottomline: we need a custom built layout engine + text renderer + input handler(that respects accessiblity) + selection handler to build an absolutely powerful rich-text editor. I'd like to start a open source project in this direction.
At Slite I was part of the mobile team, and the editor is using Slate. So to make it work in React Native we had to go for a WebView (similar to what Notion uses), with all the downside it can bring..
I tickled with the possibilty to do a native adapter of Slate, but the fact that it's based on a content editable, makes it complicated to adapt in React Native..
I have the feeling that block approach might fit better a more native integration on mobile. It seems similar to what Craft does, isn't it ?
Would be interesting to see projects going beyond contenteditable for sure!
It includes a block-based framework for composing rich content editors and an out-of-the-box block editor tailored for the AFFiNE knowledge base. With block-based editing, text editing and state management are handled block-by-block, supported by CRDT technology for distributed collaboration.
BlockSuite also offers framework agnostic rendering for scalability and flexibility. For more information about BlockSuite and the AFFiNE project, we welcome you to visit https://affine.pro/ where you can also try it in action.
We had the pleasure of hosting one of the co-founders at our latest local first meetup https://lofi.software, feel free to checkout the recording https://www.youtube.com/live/Z0nzsxhoToo?feature=share The team has put in a lot of background effort to allow for a seamless https://affine.pro app using blocksuite
My code is pretty slapdash, as I have been playing with what I actually want from this editor. BlockSuite's implementation looks much more polished. I've been meaning to refactor, and this might be the time to start!
How extendable is this? Can I add my own blocks? And is this a commercial project with open core, or a truely open source-project?
Many document editors describe the “collaborative Google-docs like model” of multiple people working on the same document and seeing everyone’s updates in real time as “multiplayer”
https://www.google.com/search?q=%22multiplayer%22+document+e...
I don’t think it’s misleading, given the existing usage.
Yours is basically an argument against domain specific language that doesn’t agree with common language.
> Okay, but the word is in active use in this space for this exact meaning.
Word misuse proliferates because those using terms incorrectly are not corrected. Instead of doubling down, there should be a course correction. I recommend using this as an opportunity to highlight the unprofessionalism of your competitors.
But "multiuser" already has an existing connotation that is different that "multiplayer". Multiplayer indicates a stronger "real-time, everyone sees the exact same thing", while "multiuser" is a weaker term. "Multiplayer" is used specifically _because_ the experience is supposed to be a parallel to the place where the term originated: video games.
The idea of a "multiplayer" document editing experience is all users are _occupying_ the same space (and often can even see each other).
> I recommend using this as an opportunity to highlight the unprofessionalism of your competitors.
I'm not in the space. I'm just aware of the space. I don't find the behavior of people in the space to be unprofessional.
Thank you for attempting to "correct" my behavior.
I think there's a subtle distinction between "collaborative editing" and "multi-player". With the latter normally implying that there are real-time visual cues as to where the other users are, what they are doing, distinguishing styles, etc. More like what you get from a game. Within front-end it seems to be well understood.
> BlockSuite (pronounced "block sweet" )
Is there any other way that "BlockSuite" would be pronounced?(Not a native speaker.)
I'm from India. I went to a school (started by a British-Indian family) where the students speaks so many dialects, that English was the only common denominator and I remember a lot of emphasis was given on pronunciation and the like. Getting the right lyrics of English western songs was one of the common pastime.
The obvious immediate benefit to this would be native editing of Wordpress blocks for your website. But if this became standardized and usable both locally and on the web, it could open up all sorts of interesting use cases.
https://blocksuite.affine.pro/assets/block-based-editing.57b...
So I’m curious how this compares with vitePress, which does look really nice.
Open-Source, E2E encrypted, offline first, syncs to all your devices via IPFS so no centralized server, etc.
No usernames or email addresses either.
I can't find it's source code on GitHub.
I don't think that is the same thing as "open source".
https://community.anytype.io/t/which-license-would-anytype-c...
That seems like either a severe bug or limitation.
/s
It's for this reason we recently switched to desktop clients for the parent project, AFFiNE. To create a more standard experience for all users.
As BlockSuite development is currently targeted for AFFiNE, but we hope to resolve many of these browser issues in the future.