Have a direct editing entry point that can be cached and reused #9251

Activity

1. max-nextcloud

   added

   enhancementNew feature or requestNew feature or request

   on Sep 24, 2026
2. mejo-

   added

   mobile

   client: 🤖🍏 mobile

   on Sep 24, 2026
3. megamaced commented on Oct 6, 2026

   

   megamaced

   on Oct 6, 2026

   More actions

   Disclosure: this comment was written by Claude, an AI (via Claude Code), and posted at the direction of the maintainer of the Android client linked above. The technical positions are theirs; the wording is mine.

   Thanks for opening this, and for #9250, which helps us too: fewer assets on the page means less for the WebView to cache.

   Here's what this would need to do to work for the Android Collectives client, roughly in priority order.

   1. Read-only with provided content is the mode we'd use first

   The app already keeps every page body in a local database and renders it natively with no network, including from a cold start. If the entry point can take markdown handed to it and render it read-only, we can show the real Text rendering offline without relying on IndexedDB or the WebView cache surviving. In that mode we'd want no collaboration session at all: no sync or push connection, no lock, and no presence shown to other users who have the page open. Viewing a page shouldn't make the reader appear to be editing it.

   Read-write can come later. For now, read-write would stay on today's directEditing path. One question for that stage: if we pass content in for a fileId whose IndexedDB copy is dirty, which wins? We'd rather Text resolved that and told us, because the app has its own offline edit queue, and two offline-edit systems shouldn't compete over the same file.

   2. Authentication passed in at runtime, not baked into the page

   For the cached page to stay valid, it can't contain anything tied to one session. Native clients hold an app password from Login Flow v2. Our suggestion: the app calls an OCS endpoint with that password to get a scoped, refreshable token, then passes the token to the page through the JS bridge. Two notes from the Android side:

   • An Android WebView can't add headers to XHR/fetch POSTs from the outside (shouldInterceptRequest doesn't expose the request body), so Text's JS would need to attach the token itself.
   • We'd rather not put a full app password into the WebView's JS context. A token limited to Text's endpoints, or to one document, would be better.

   Open question: in read-only mode without a session, how would embedded images and attachments be fetched and authenticated? It's fine for them to fail to load offline, but online they need a way to authenticate.

   3. Cacheable in practice, not only a stable URL

   A stable URL gets us offline only if the page itself is served with headers that let the WebView keep it, or comes with a service worker. Long cache lifetimes are fine for us. The app already reads version from status.php and clears the WebView's HTTP cache when it changes, without touching IndexedDB, so a server upgrade doesn't leave old assets behind.

   4. Links reported to the app, not followed

   Ideally, link taps in read-only mode go through the bridge with the raw href, plus the target fileId when Text has resolved it (wikilinks and relative .md links). The app can then open other pages natively. Today we intercept navigation with shouldOverrideUrlLoading to stop a link from replacing the editor.

   5. Theming the app can set

   We'd want to pass in light or dark mode, an accent colour and a text size (the app has a user-facing text-size setting). A small set of supported CSS variables would cover it. Without this, a WebView viewer looks out of place among Material You screens.

   6. Discoverable and versioned

   Please advertise the entry point in the OCS capabilities with a contract version, so a client can detect it, fall back to its native renderer on older servers, and notice when a cached copy no longer matches the server. Documenting the bridge messages would help too. Today's DirectEditingMobileInterface messages (loading, loaded, close, share, reload) work well, but we found them by reading the source.

   And agreed: no npm package

   Fetching Text from the user's own server at runtime is also the only form F-Droid accepts, since its scanner flags prebuilt JS bundled in the APK. The status.php invalidation above handles the version-tracking cost that comes with runtime fetching.

   Happy to test early builds against the app, or to pin down any of the above in more detail.