For folder and note IDs I think 6 characters would be better to prevent any collision. There's no attempt in general to keep them private since knowing doesn't give access to anything.

By the way I just remembered there's a CLI command that does something similar in command-e2ee.js to check the status of encrypted items on the sync target. The logic might be similar to what you need so you might want to take a look at it

It looks like some of this is already possible:

• joplin-server-url-here/api/items/root/delta?limit=1000000 outputs the result of a delta
• joplin-server-url-here/api/items/root:id-here.md shows whether id-here was uploaded to the server

I also see that the changes route, a similar feature, was disabled for leading to database locks.

Interestingly, joplin-server-url-here/api/items/root:notebook-id-here.md results in an "item not found" error and joplin-server-url-here/api/items/root/delta?limit=1000000 seems to not include items with item_name matching notebook IDs (at least for the folders I tested). This does not seem to be the case for notes.

The debug report page I've created, so far, seems to share this limitation — notebooks don't show up in the output (notes and resources do).

To see this:

1. Start a local instance of Joplin Server
2. Sync to it from a client
3. Copy the external link to a notebook from that client (e.g. joplin://x-callback-url/openFolder?id=8b4fd3a997ba4260a3cd05495bf0f0bf)
4. Copy just the notebook ID (e.g. 8b4fd3a997ba4260a3cd05495bf0f0bf)
5. Open http://localhost:22300/api/items/root/delta?limit=1000000 in a web browser
6. Search for the notebook ID
7. Copy a resource ID and search for it
8. Copy a note ID and search for it

I'm currently trying to debug this.

Edit: Many folders weren't on the server. Clicking "re-upload local data" fixed the issue.