feat(librechat): full API integration — server-side conversations, search, tags, sharing, memories, presets

[itsablabla]

Summary

Replaces localStorage-based conversation persistence with full LibreChat server-side API integration across all 3 tiers. This is the single biggest quality improvement — conversations now sync across devices, survive cache clears, and include full tool call history in MongoDB.

Tier 1: Server-side persistence (core)

• Conversations: store.js loads from /api/convos instead of localStorage. ChatView.vue loads message history from /api/messages/{id} on conversation switch.
• Search: SearchView.vue uses debounced server-side search via /api/messages?search= (MeiliSearch full-text) plus instant local search for conversations/tools/workspaces.
• JWT Auth: OpenClawService.php implements dual auth — API key for Agents API, JWT for internal APIs. Tokens cached with 14min TTL, auto-refresh on 401.
• Sidebar: Conversations grouped by Today/Yesterday/This Week/Older with relative timestamps and "Load more..." pagination.

Tier 2: New capabilities (backend fully wired)

• File attachments via /api/files
• Conversation sharing via /api/share
• Agent memory via /api/memories
• Tags via /api/tags (workspace mapping)

Tier 3: Polish (backend fully wired)

• Presets via /api/presets
• Archive conversations via /api/convos/archive
• Auto-generated titles via /api/convos/gen_title

Infrastructure

• 30+ new PHP routes in routes.php
• 15+ new proxy methods in AgentController.php
• Complete frontend API client in api.js
• Fixed JWT 401 retry bug (was corrupting Content-Type header via array_search returning false)
• Service account credentials externalized to Nextcloud app config (admin settings UI)
• Version bump to 0.5.0

Devin Review fixes (0743d62)

1. Hardcoded credentials removed — SERVICE_EMAIL/SERVICE_PASSWORD constants replaced with librechat_service_email/librechat_service_password app config keys, configurable via Admin → Jada Agent settings
2. array_search false bug fixed — 401 retry path now safely checks $authIndex !== false before array assignment, with fallback to append
3. Per-user isolation documented — see Known Limitations below

Known Limitations

• Single service account: All Nextcloud users share one LibreChat identity (jada@nextcloud.local). This means conversation data is not isolated per-user. For single-admin setups this is fine. Multi-user isolation requires either per-user LibreChat account provisioning or OIDC SSO integration (planned).
• Tier 2-3 frontend: Backend routes are fully wired but frontend UI components (file upload, sharing button, memory viewer, presets picker) are not yet built.
• Admin must configure credentials: After deploying, the admin must set the LibreChat service password in Nextcloud Admin → Jada Agent settings before JWT-authed endpoints work.

Review & Testing Checklist for Human

• Set service password in admin settings — Navigate to Nextcloud Admin → Jada Agent, enter the LibreChat service account email and password
• Verify conversation list loads from server — Open Jada Agent → sidebar should show conversations from LibreChat
• Verify send + persist — Send a message → reload page → conversation should appear in sidebar and messages should reload from server
• Verify search — Type in Search view → should show server-side results plus local results
• Test on mobile — Sidebar conversation list, chat input, and streaming should all work on iOS Safari

Notes

• The service account (jada@nextcloud.local) must exist in LibreChat's MongoDB with role: ADMIN and email verified
• Tier 2 and 3 frontend components will be built in a follow-up PR once Tier 1 is verified working end-to-end

Link to Devin session: https://app.devin.ai/sessions/f4e16f12bfa34fc6bdc3d73a833a5d91
Requested by: @itsablabla

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 3 potential issues.

View 6 additional findings in Devin Review.

[devin-ai-integration]

🔴 All Nextcloud users share a single LibreChat service account — no per-user data isolation for JWT-authed endpoints

All 21 JWT-authed endpoints (conversations, messages, search, tags, sharing, memories, presets) authenticate to LibreChat using a single shared service account JWT (jada@nextcloud.local). Unlike the API-key-authed endpoints (health, chat, models) which pass X-Nextcloud-User headers via getUserHeaders(), none of the jwtGet/jwtPost/jwtDelete calls include any user identity. This means LibreChat treats all requests as the same user, so all Nextcloud users see each other's conversations, messages, memories, tags, and presets. This directly contradicts the stated feature of "Per-User Isolation".

Example: getConversations passes no user identity

In lib/Controller/AgentController.php:200, jwtGet is called without user headers:

$result = $this->openClaw->jwtGet('/api/convos?' . $params);

Compare with the API-key-authed health() at line 53 which does include user headers:

$result = $this->openClaw->get($apiPath . '/models', $this->getUserHeaders());

Prompt for agents

The fundamental issue is that all JWT-authenticated LibreChat API calls go through a single shared service account with no per-user scoping. Every call to jwtGet/jwtPost/jwtDelete in AgentController.php needs to include user identity so LibreChat can scope data per user. There are two main approaches to fix this:

1. Per-user JWT approach: Instead of a single shared JWT, obtain and cache a separate JWT for each Nextcloud user. This requires creating individual LibreChat accounts per Nextcloud user (or mapping them). The JWT cache in app config would need to be keyed per user.

2. Shared JWT + user header approach: If LibreChat supports user scoping via request headers (similar to how X-Nextcloud-User works for the Agents API), pass getUserHeaders() as extra headers in all jwtGet/jwtPost/jwtDelete calls. This would require the controller methods to call e.g. $this->openClaw->jwtGet('/api/convos?' . $params, $this->getUserHeaders()) instead of $this->openClaw->jwtGet('/api/convos?' . $params).

All 21 JWT-authed endpoints in AgentController.php are affected: getConversations, getConversation, deleteConversation, updateConversation, archiveConversation, genTitle, getMessages, getConversationMessages, searchMessages, getTags, addTag, removeTag, getSharedLinks, createShareLink, deleteShareLink, getMemories, deleteMemory, getPresets, createPreset, deletePreset, getConversationToolCalls.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Valid architectural concern. This is a known limitation of the current "shared service account" approach — all Nextcloud users share one LibreChat identity (jada@nextcloud.local).

Why it's this way for now: LibreChat's internal APIs (/api/convos, /api/messages, etc.) scope data by the authenticated user's JWT. There's no header-based user impersonation like the Agents API supports. To get true per-user isolation, we need one of:

1. Per-user LibreChat accounts — auto-provision a LibreChat user per Nextcloud user on first login, cache per-user JWTs keyed by NC uid. Most correct but requires user provisioning logic.
2. OIDC SSO — connect Nextcloud as an OIDC provider to LibreChat so each NC user gets their own LibreChat session natively. This is the planned long-term fix.
3. MongoDB query scoping — add a custom header that LibreChat reads for data scoping (would require LibreChat core changes, not viable).

For single-admin setups (which is the current deployment), this is a non-issue. For multi-user, option 1 is the pragmatic next step and option 2 is the proper solution. I'll note this in the PR description as a known limitation.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 23 additional findings in Devin Review.

[devin-ai-integration]

🟡 Accessing $models[0] on empty array generates PHP 8 warnings in health endpoint

When the LibreChat /models endpoint returns no models (e.g., backend is down, misconfigured, or API key is missing), $models is []. Lines 57-58 access $models[0]['name'] and $models[0]['provider'] directly, which generates two PHP 8 warnings: "Undefined array key 0" followed by "Trying to access array offset on null". The ?? fallback values work correctly so the response is fine, but the warnings pollute logs and will fire on every health check (called every 30 seconds by the frontend).

Note that $agentName is assigned but never used — only $provider feeds into the response at line 68.

Suggested change

	$agentName = $models[0]['name'] ?? 'Jada';
	$provider = $models[0]['provider'] ?? 'Gemini';
	$firstModel = $models[0] ?? [];
	$agentName = $firstModel['name'] ?? 'Jada';
	$provider = $firstModel['provider'] ?? 'Gemini';

---

Was this helpful? React with 👍 or 👎 to provide feedback.