It would be awesome if one could access their Nextcloud files with a slash command (/nextcloud) and embed them in logseq. Similar to how the Zotero integration is currently implemented.
This, of course, could be enhanced even more to contacts, calendar etc.
Curious what you think!
Also the opposite would be nice: installing Logseq in the cloud as Nextcloud app and use it with files hosted on Nextcloud.
Nextcloud integration would be good. Currently, I find that editing an .md file breaks a Logseq journal file, as all - headings are replaced with *. Could Logseq not accept * headings?
Until official integration /cloud solution I’m using Nextcloud WebDAV sharing. So WebDAV shared folder is local folder for Logseq. My office Laptop+ homePC + Home Linux Laptop are using same Nextcloud folder shared with WebDAV.
https://docs.nextcloud.com/server/latest/user_manual/en/files/access_webdav.html
I suppose editing same page simultaneously is not possible this way but on the other hand I’m only at one machine at the time 
Thanks @Vulcan69 - unless you have incomplete edits on more than one device! I’ve started getting loads of edit conflicts in the last couple of weeks accessing Logseq in synced Nextcloud folders on Windows, I’ll try connecting to the share directly using WebDAV. Things seem a bit more reliable on Mac.
To me, synchronizing instances using webdav (which is included in nextcloud) would be awesome!
it would be awesome, the total solution to fix all of my problems
Just a quick warning. Don’t open logseq md files with Nextclouds native “Text” app. (web interface) It will reformat everything and breaks the page for logseq.
That sounds great. Just wondering: Is using WebDAV any better than using the Nextcloud desktop client? Have you tried both?
They are different approaches:
The quality of your WebDAV experience really depends on your client and to use it with Logseq you need your WebDAV client to expose those files as regular local files to Logseq. Operating systems generally have different ways to let programs “mount virtual file systems”.
For example in KDE/Plasma (Linux desktop environment) native applications (supporting so called “KIO”) can access remote files as they were local using different protocols, including WebDAV. Third party apps like Logseq that don’t support KIO can still access those files thanks to a tool called KIO-FUSE that mounts remote directories as a virtual file systems, Logseq can’t tell the difference and just read/write there.
Thanks for the explanation. I’m using GNOME Files (Nautilus) and it too can mount WebDAV folders as local folders.
But WebDAV folders don’t work offline, so I was wondering why one would choose to sync a Logseq graph via WebDAV instead of the Nextcloud client, which would seem more reliable to me.
Does WebDAV have any advantages I’m missing for this use case?
Since files are edited live you are less likely to get conflicts: when you sync files with something like Nextcloud client, if you edit a file with a device but the Internet connection doesn’t work, then later you edit the same file with another device and only at the end the connection work again what would happen? Probably only more recent edits on the second device are stored and the other ones are lost. I didn’t try it, but this is the kind of issues.
In general another advantage of WebDAV is browsing large archives with many big files that you don’t want to keep synced.
Maybe, if you have very large files that you want to mention in your graph but you are OK with them being available only when there is an Internet connection, you can try a mixed approach:
Thanks for the insight! Now I get the point for certain use cases.