HN user

Pi9h

249 karma

email: hn@neuronlabs.co.uk

Posts2
Comments43
View on HN

Perhaps try it first before dismissing it as just a “note-taking tool,” which it isn’t.

We have support for team-spaces, permissions, diagrams, real-time collaboration, comments, page verification workflows, AI, SSO/LDAP, search, audit logs, API, public sharing, and a lot more.

Btw, we have plans to introduce a database-like feature.

If you are looking for a self-hostable Notion alternative, I am building Docmost, which is open source.

It has real-time collaboration and support for diagrams (drawio, excalidraw and mermaid).

It can be tempting to want to do it all, but I am focused on building a great wiki and documentation software.

GitHub: https://github.com/docmost/docmost

While some Tiptap Pro extensions would have made things a little easier, I appreciate that the core and majority of the extensions are open source. It has the building blocks to create custom extensions without limits.

Docmost does not depend on any Pro Tiptap extensions.

The team at Tiptap are doing something really amazing. I believe it is fair that they find avenues to make revenue from it.

I like Lexical, but I found Tiptap first and loved it.

I should have been more explicit.

I do not intend to change the Postgres database or introduce a new one. I’m sure this won’t be an issue for the majority use-case.

However, I am open to learning more about alternate ways to efficiently handle Yjs state updates, which may be useful for a cloud version that would run at scale. If I were to go that way, it would not affect self-hosted users and would probably be via a reference pointer and not a database switch.

This is absolutely not an issue at the moment. Nothing to worry about.

I truly appreciate your in-depth articulation.

Indeed, the Yjs state update can be problematic due to its growing size and constant updates.

I will have a look at MyRocks. Reference pointers sound more plausible.

I spent time analyzing and deciding my usage of uuid7 from different perspectives. From the git logs, you can see it came at the last minute.

I guess the best way will be to store the PNG/SVG in the storage driver with a reference to it in the editor. The same PNG/SVG will get updated/replaced whenever the code is updated. I need to do more study on this.

Storing the raw data in the editor will bloat the Prosemirror JSON and Yjs state (real-time collaboration) which I want to avoid.

1. "Project" sounds good too.

2. With a small change, I can make the frontend use the window.location URL if none is set. On the backend, the catch is emails. Emails with link use the APP_URL to build it.

3. I do not really think "backup" belongs to the UI, but there is a possibility. I plan to work on HTML and Markdown exports. We have what it takes already from the editor.

3. Latex and Comments do not use the Tiptap Pro extensions, so it's fine. Also, the comment extension is entirely different from Tiptap's own which depends on Tiptap Cloud to work.

I thought about it.

For example, the sidebar page tree supports keyboard navigation.

The UI library I am using, Mantine, follows accessibility best practices and has full keyboard support.

There is still a lot to do in this regard. As the project progresses, more support will come.

In the past, I built a Twitter bot (@threadvoice) to help people listen to Twitter threads in audio format ( https://twitter.com/Philipofficial9/status/11899711858004869... ). I had accessibility as one of my motivations while building it.

The software itself is very easy to install, even without Docker. You are set with just three commands: pnpm install, pnpm build and pnpm start.

Docker is not a hard dependency but it was the easiest way to document it and hope it works for everyone, given the Postgres and Redis requirements.

With time, I will create documentation for other platforms.

Thank you.

1. You were using an older docker compose version, I guess? Newer versions recommend `docker compose` without the dash.

2. Your understanding of the hierarchy is correct. Workspace -> Space -> Page. I admit, the naming is similar and can be confusing. I just couldn't come up with a conclusive alternative while self-debating it. Do you have better suggestions?

3. I will look into the title issue. Thanks for pointing out.

4. I will put the APP_URL thing in mind too.

5. The pages are stored in the pages table. The content is stored in 3 formats, i. Prosemirror Json (default editor state). ii. Yjs state (real-time collaboration). iii. raw Text (for search indexing). The affected tables are json_content, ydoc and text_content

5. I will look into the redirect issue, and "Copy link" bug.

I appreciate your feedback and thank you for trying it out.