Can confirm zooming issue is fixed.

I got it running in Docker. I had to run "docker-compose up -d" rather than the instructions' "docker compose up -d" (no dash), which just gave a confusing error message about not knowing "-d".

It looks great!

I got confused at first between Workspaces and Spaces. It seems that Workspaces contain Spaces which contain Pages? I like that, but the names seem too similar.

I noticed the page title doesn't update on some locations. E.g. I go into a page, the title updates, but then when I leave the note the title remains. Similarly the "Login" title persisted after I'd logged in.

It took me a minute to figure out how to access it from other computers on my local network, and the problem was I left the APP_URL as localhost. Confusingly, that partly worked, so it might be worth putting in a warning about it. With APP_URL set to localhost, if on another computer on the same network I go to <ip address>:3000, it redirects to <ip address>:3000/home, so something is connecting, but then nothing loads and it's just a blank screen (there's an error message in the browser console about failing to load resources from "localhost").

How and where are pages stored? I would love to use this, but need robust backup/restore.

Edit: It would be great if going to a page URL when not logged in would redirect to that page after login.

Edit 2: "Copy link" doesn't work? It pops up a message saying "Link copied" but it's not in the clipboard.

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.

1. I guess so. I'm using the one from Ubuntu 23.10.

2. I think something like Project would work better than Space.

4. Does the app need to know its server name? Can it just use relative URLs everywhere instead of absolute? That would simplify configuration.

5. Thanks, I've had a poke around in the DB. I think a Backup/Restore feature in the UI is important. Also good would be a way to request the data programmatically e.g. I'd put it in a cron job before my Borg backup job runs (that would store daily versions using diffs, so it would need to be uncompressed). An "export to HTML/Markdown/[something importable]" feature would help people feel comfortable trusting the app. I have thousands of pages of handwritten notes in an Android app called Squid, and regularly export from that to back it up (it gives me an SQLite DB file only readable by Squid, which is okay but not ideal); without that backup option I'd be pretty worried about losing my work in there, and I get the same feeling about Docmost.

By the way, are you allowed to distribute the Tiptap Pro extensions? E.g. the Latex support and Comments.

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.