Hi! Before starting implementation, I'd like to ask whether direct access to Markdown folders in Nextcloud would fit the project's direction. Nextcloud is my main use case, and its integration is the part I'd be keen to work on first.

Use case

I keep Markdown files in Nextcloud and would like to browse, open, edit, and save them directly in Markdown Viewer, without installing the Nextcloud desktop client or maintaining a synchronized local copy of the folders.

Each user would connect to their own server and account, then select folders to display in the Explorer/sidebar. Files would be fetched when opened; edited documents would retain local recovery drafts.

Proposed initial scope

• Connect to a Nextcloud account, preferably through its browser-based Login Flow with an app-specific credential.
• Browse selected remote folders and open Markdown files in the existing editor/tabs.
• Explicitly save changes back to the remote original, using server-supported conditional writes to prevent overwriting a competing edit.
• Preserve drafts during connection failures or conflicts, and distinguish local draft persistence from confirmed remote saving.

Full folder mirroring, background synchronization, remote delete/move operations, and automatic conflict merging would be outside the initial scope. This would provide remote file access rather than synchronize the application's entire workspace.

Architecture and platform scope

I'd focus the initial contribution on Nextcloud browsing and editing. Document handling, draft recovery, and conflict logic could be shared between platforms, while authentication, credential storage, and network transport use platform-specific adapters.

If you prefer a general "Remote connections" section or a reusable source interface, I'd be happy to discuss how the Nextcloud integration should fit into it. Support for generic WebDAV or other server types would remain a possible future extension, outside the contribution I'm proposing here.

I'd like to support both desktop and web, but browser CORS requirements mean direct access to arbitrary Nextcloud servers cannot be assumed. Would a desktop-first proof-of-concept be acceptable, with web support evaluated separately? I would not assume a hosted proxy or require one without discussing that tradeoff first.

Keeping the shared logic independent of Neutralino could also make it reusable in a future Android client, but Android would not be part of this proposal's initial implementation.

Questions

1. Would this feature be of interest for upstream?
2. For a Nextcloud-focused contribution, would you prefer a dedicated sidebar section or integration through a reusable remote-source interface?
3. What initial platform scope and integration approach would you prefer?

I'm keen to implement the Nextcloud integration and contribute it in small, focused PRs. If this aligns with your plans, I'd start with a Nextcloud connection/list/read proof-of-concept, followed by conditional saving and recovery/conflict tests. I'd coordinate the approach with you before implementation and keep the first contribution focused on Nextcloud.