[RFC] Road to beta

[hanspagel]

It’s amazing what we achieved with Hocuspocus already. The adoption is insane, it’s running in production in tons of apps already. BUT, we’re still in alpha, and in a pretty closed state. 👀

We’d like to transition to a more stable beta version soonish. Let’s keep track of what needs to be done in this issue:

• [x] #286
• [x] Release the new Redis extension
• [x] #376
• [x] Migrate all tests to AVA
• [x] Go through the documentation to reflect recent changes and see Hocuspocus from the developers perspective

Things we can do in a beta stage:

• [x] Incorporate feedback for the above changes
• [x] Improve the typing
• [x] Polish the documentation
• [x] Add tons of examples

This list can change in the future.

Put your feedback/questions below 👇

[ViktorQvarfordt]

This is great! Most important for us is:

• Release the new Redis extension

[stefanluptak]

Remove RocksDB from the documentation, promote the new generic database extension

Can I somewhere read a reasoning about this decision? Thanks. :-)

[philipaarseth]

Is this project still moving towards beta? Rough goal end of March was three months ago and there doesn't seem to be any updates anywhere.

[svenadlung]

@philipaarseth Reasonable question. You're right, unfortunately we are behind schedule. We've had a few team challenges over the past weeks. However, we always fixed critical bugs whenever needed. Now we are getting back on track with more focus towards the beta in late summer. Sorry for our poor communication in this regard.

[philipisik]

Status Quo and Next Steps of Hocuspocus

Dear friends of Hocuspocus,

We've kept you waiting for a long time, but now we can finally tell you that Hocuspocus will be released as a beta version at the end of September. The last item on our list for the road to beta is improving the documentation.

Hocuspocus is being used in some larger software projects in production, and so far, we are not aware of any critical issues. Still, we are curious: do you have any concerns about the stability of Hocuspocus?

What's Next

Besides our road to beta, we would like to give you a preview of what we have planned next. The communication was pretty lousy from our side in the last months for multiple reasons (our daily business was a roller coaster ride, and we had some challenges in the team). We want to apologize to you and promise to improve.

Stable Release

We plan to release a stable version of Hocuspocus by the end of this year. For this, we will separate it from the Tiptap Pro subscription and provide it as a standalone package. The stable release also means that Hocuspocus will have its own website, and the documentation and developer resources will be even more extensive.

Cloud Beta

We have been asked a few times whether there will also be a cloud service from Hocuspocus so that you don't have to care about the whole setup and maintenance of the infrastructure yourself.

And this is where we break the big news: Yes, we have already developed the first version for a cloud solution and plan to release it as a beta version by the end of the year, next to the stable release of the open-source package.

There will be an invite-only phase until the public release of the Hocuspocus cloud to test and improve the service and stability with you. Tiptap Pro subscribers will get a guaranteed invitation.

Questions?

Please share your thoughts with us! Every question is welcome, and we are glad to answer all of them.

[ahoyahoy]

will multidoc be part of it? :))

[janthurau]

Hey @ahoyahoy, multidoc support is not officially planned for the beta, but as we've had multiple requests about it already, we've started to gather more feedback on this. Do you currently have a use-case where multidoc support is required or would be useful? If so, please share some details on how you would use it :-) thanks!

Sorry for late reply, I had a short vacation :)

[philipaarseth]

Glad to hear that we're moving towards beta and stable release! Personally I'm running a very old build because at some point things were changing so rapidly and the documentation was quite lacking/ outdated so I've been hesitant of re-writing the logic until it stabilises a bit. It's good to see that documentation and examples will be a priority going forward!

A few questions:

Does stable release mean transitioning to MIT open source licensing or is it already MIT? Right now on the website it says it "will be licensed under MIT" but in the repo LICENSE.md it already is MIT.

Will sponsoring continue to give early access until then? Do you guys have any thoughts on what you want to do with HocusPocus after stable release?

[DanSnow]

I hope will see multidoc support. We already use multiple docs on our production. Our editor has separated fields for title and body. And we are using multiple editor instances with one Yjs document.

[HelloAlexPan]

Same here re multidoc!

[ahoyahoy]

@janthurau thanks :)

I want to control access rights per each data property (granulated permissions). https://github.com/ueberdosis/hocuspocus/discussions/333

Also one websocket connection per one user for multiple docs would be nice.

[janthurau]

Thanks a lot for all the comments!

hey @DanSnow, what's your use-case for subdocs? You can use multiple fragments with the Hocuspocus provider (field property of the provider) to separate e.g. title from content in a single ydoc (and also just persist other data in it). Which advantages are you expecting from using a subdoc instead? (same question to @HelloAlexPan) Sorry If I'm missing something here!

@ahoyahoy thx! In the future you can use the beforeUpdate hook (planned in #286) for filtering incoming updates on the hocuspocus server. Indeed, I think 'only allow user X to fetch a particular property of a ydoc' is a use-case that can be solved best using subdocs, thanks!

[DanSnow]

Hey @ahoyahoy, multidoc support is not officially planned for the beta, but as we've had multiple requests about it already, we've started to gather more feedback on this. Do you currently have a use-case where multidoc support is required or would be useful? If so, please share some details on how you would use it :-) thanks!

Sorry for late reply, I had a short vacation :)

Do I misunderstand something? We already using different field options to have multiple documents. Does multidoc at the above comment mean some different thing?

[janthurau]

@DanSnow yes, different field options are fragments, which can already be used with the current hocuspocus / hocuspocusprovider.

Subdocuments are really separated documents that are loaded separately. I think the main example is this folder structure from the official docs, where you have one ydoc which is a large folder and then each file in it is a subdoc, so you can decide which subdoc (file) you want to load.

But if Hocuspocus can already do what you thought multidoc was, then what kind of feature are you looking for? :-)

[DanSnow]

I understood. Thanks for clarifying

[martinboksa]

Same here, multi-doc.

We cannot use 'subdocs' because we would like to keep the option to share documents with public (it's impossible to load only subdoc). It would be a great feature!

Thank you 🙏

[tslater]

Hey @ahoyahoy, multidoc support is not officially planned for the beta, but as we've had multiple requests about it already, we've started to gather more feedback on this. Do you currently have a use-case where multidoc support is required or would be useful? If so, please share some details on how you would use it :-) thanks!

Sorry for late reply, I had a short vacation :)

We have a document structure where blocks are considered documents in themselves. They can appear in multiple docs, or by themselves. Essentially everything is nested/nestable and the idea of just one doc is really just a temporary abstraction. We'd like to treat each block as it's own subdoc.

We also show lots of different portions of documents in a large table.

[deiucanta]

@tslater I'm working on a similar use case. The only difference is that I don't need real-time updates. I do a simple sync through HTTP every X seconds using state vectors and it works fine.

My current challenge is on the editor side. How do you manage to combine multiple documents into one editor?

[lele0108]

@janthurau Multidoc (multiplexing one websocket connection for many yjs docs) is also very important for us as our application can render many separate documents in the same view and want them to be separate yjs instances. Establishing new ws per document is costly and we would run into browser ws limits

[ahoyahoy]

Hi @janthurau any update or timeline? :)) thanks

[svenadlung]

I am closing this topic as we did publish the stable version. Please discuss other topics in dedicated issues 🙏.