Projects/docs/MissingComponnents.md

📌 Current Backend Strengths

• Authentication & user management – login, register, logout, CSRF, rate limiting, firewall.
• Article CRUD + search + recommendations – PageRank, co‑citation, bibliographic coupling, GNN.
• Real‑time messaging (private & group) – WebSocket, Redis Pub/Sub, read receipts, typing indicators.
• Inverted index for message search.
• Admin panel basics.
• Secret chat (E2E encryption) – X3DH + Double Ratchet (client‑side libsodium).

---

🧩 Missing Features (Based on Frontend)

Feature Area	Missing Endpoints / Capabilities
File uploads	Multipart handling for article manuscripts, avatars, chemical images, RAG documents.
Two‑Factor Auth (TOTP)	/users/me/2fa/enable, /verify, /disable, /backup-codes. Need TOTP library (e.g., com.warrenstrange:googleauth).
Notifications	Fetch, mark read/unread, real‑time via WebSocket. Store notifications (like, comment, follow) in a ConcurrentHashMap.
Peer Review	Submissions (anonymous), claim reviews, submit scores/comments, credentials. Entire new module.
Lab Inventory	CRUD for chemicals, locations, alerts, barcode scanning, incompatibilities, NFPA data.
Gap Analysis	Knowledge graph nodes/edges (papers, concepts, gaps). Could be stored as JSON or separate in‑memory structures.
Grant Assistant	Grant deadlines, proposal generation (might call AI). Could be simple CRUD + integration with an LLM (e.g., via HTTP to Ollama).
RAG Assistant	Document upload, chunking, embedding, vector search, LLM chat. The frontend currently does client‑side HNSW, but you may want server‑side storage of embeddings. At minimum, expose /ai/rag-chat that accepts a prompt + context (frontend already builds context) and calls an LLM.
Collaborative Editing	Yjs WebSocket signaling server. This is separate from your main WebSocket. You can run a standard y-websocket server (Node.js) or integrate a simple signaling relay.
Projects	Project CRUD, members, tasks (Kanban), outputs.
Data Hub	Research objects, protocols, preregistrations. Simple CRUD with file attachments.
Polls/Quizzes	Create, vote, get results.
Events	Event CRUD, calendar, virtual meeting links.
Analytics	Track article views over time, daily stats. You already have views counter; add time‑series storage.
Voice Assistant Settings	Store per‑user voice settings (preferences).
Admin Dashboard	More detailed stats (users, articles, comments over time).

---

🛠️ How to Extend the Backend (Step‑by‑Step)

You already have a modular architecture: Route classes → Service → Repository (in‑memory ConcurrentHashMap). This pattern is easy to extend.

1. Add File Upload Support

• Create a FileUploadRoute that handles multipart/form-data.
• Store files on disk (e.g., uploads/). Return a URL (e.g., /uploads/{id}).
• Reuse in avatar, manuscript, chemical images, etc.

2. Two‑Factor Authentication

• Add dependency: com.warmthdawn.googleauthenticator or com.warrenstrange:googleauth.
• Create TwoFactorRoute with endpoints /enable, /verify, /disable, /backup-codes.
• Store secret and backup codes in user session/repository.

3. Notifications

• Create NotificationRepository storing Notification objects (id, userId, type, message, read, createdAt, link).
• Add endpoints: GET /notifications, POST /notifications/{id}/read, POST /notifications/read-all.
• On events (like, comment, follow), call a NotificationService that saves and pushes via WebSocket.

4. Peer Review

• Create PeerReviewSubmission, PeerReview models.
• Implement endpoints:
  • POST /peer-review/submit – anonymous submission (store with generated ID).
  • GET /peer-review/submissions – list open submissions (anonymised).
  • POST /peer-review/submissions/{id}/claim – assign to current user.
  • POST /peer-review/submissions/{id}/review – submit scores/comments.
  • GET /peer-review/my-reviews – reviews assigned to me.
  • GET /peer-review/my-credentials – reviewer ORCID/expertise.
• Store in ConcurrentHashMap (or persistent DB).

5. Lab Inventory

• Create Chemical model (id, name, formula, casNumber, location, quantity, unit, minStock, expiryDate, nfpa, etc.).
• Implement CRUD routes under /inventory/chemicals.
• Add alerts (expiry, low stock) via a background job (or compute on the fly).
• Barcode scanning: lookup by barcode (CAS number or custom). Return chemical.
• NFPA diamond: store as JSON object.

6. Gap Analysis

• Since the frontend uses client‑side graph (ForceGraph2D), the backend mainly needs to serve nodes and edges.
• Create GraphNode and GraphEdge models.
• Provide endpoints:
  • GET /gap-analysis/nodes – list all nodes (papers, concepts, gaps).
  • GET /gap-analysis/edges – relationships (cites, related_to, contradicts, etc.).
• You can generate initial data from your article graph (co‑citation, etc.).

7. Grant Assistant

• Simple CRUD for grants: GET /grants/deadlines, POST /grants/generate (call external AI if needed).
• Store grant deadlines as Grant objects with title, agency, amount, deadline, status.
• For AI generation, you can implement a simple LLM wrapper (e.g., call Ollama or OpenAI).

8. RAG Assistant

• The frontend already does indexing and vector search locally (using @xenova/transformers and HNSW). The only backend endpoint needed is /ai/rag-chat which receives a prompt and the retrieved context (already built by frontend) and returns an LLM response.
• Implement AiChatRoute that forwards to an LLM (local or external). Example:

POST /ai/rag-chat { "messages": [{"role":"user","content":"..."}], "sources":[...] }

• Also /ai/chat for general conversation.

9. Collaborative Editing (Yjs)

• Run a separate Yjs WebSocket server. The simplest is to use y-websocket:

  npx y-websocket --port 9093
  

• Or embed a Java WebSocket server that mirrors the Yjs protocol – but that’s complex. Using the existing Node.js tool is fine; you can start it as a sidecar process.

10. Projects

• Models: Project (id, name, description, owner, members), Task (id, title, description, column, priority, tags, dependencies).
• Endpoints: /projects CRUD, /projects/{id}/members, /projects/{id}/tasks, etc.
• Use in‑memory storage.

11. Data Hub (Research Objects, Protocols, Preregistrations)

• Create models: ResearchObject (type, title, authors, fileUrl, DOI), Protocol (steps), Preregistration.
• Endpoints: list, upload, delete, fork protocol.
• Store files in upload folder.

12. Polls & Quizzes

• Models: Poll (question, options, multipleChoice, isQuiz, expiresAt).
• Endpoints: POST /polls, GET /polls/{id}, POST /polls/{id}/vote.

13. Analytics (Article Views Over Time)

• Currently you have totalViews counter. To get views over time, store ArticleView events (articleId, timestamp) in a list or rollup table.
• Endpoint: GET /articles/{id}/analytics?range=7d compute from stored events.

14. Voice Assistant Settings

• Store voiceSettings JSON in user profile (or separate table). Endpoints: GET /users/me/voice-settings, PUT /users/me/voice-settings.

15. Admin Dashboard Statistics

• Add /admin/stats endpoint that aggregates counts (users, articles, comments, messages, etc.) from repositories.

16. WebSocket Enhancements

• Your existing WebSocket server (port 9093?) handles chat events. Ensure it also sends notifications (new_notification).
• Add presence (online/offline) by tracking open connections.

17. General Endpoints Missing from Your Current API

• GET /recent-items – used by command palette. Return recent articles, contacts, messages.
• GET /discovery/recommendations – aggregated feed.
• GET /discovery/summarize/{paperId} – call LLM to summarise.
• GET /tags – list all tags.
• POST /users/me/contacts – add contact? (frontend might use contacts panel)
• GET /users/me/contacts – list contacts.

---

🧰 Recommended Implementation Strategy

1. Keep the existing architecture: each new feature gets its own route class, service, repository (using ConcurrentHashMap for speed and simplicity during development).
2. Use the same authentication mechanism (HttpOnly cookie, CSRF token). All new routes should extend BaseRoute and use @Route annotations.
3. For file uploads, create a MultipartParser utility that parses multipart/form‑data (or use a library like Apache Commons FileUpload).
4. For AI endpoints, start with a simple mock that returns predefined responses, then integrate with Ollama (local LLM) or a cloud API.
5. For persistence, you can continue using in‑memory maps, but for production consider adding a lightweight SQLite driver (JDBC) and migrate existing repositories to SQLite.
6. Testing: write integration tests for each new route using JUnit (like your existing tests).

---

🚀 Priority Order for Extending

If you want to make the frontend fully usable with the real backend as quickly as possible, implement in this order:

1. File upload support – needed for avatars, article manuscripts, RAG documents.
2. Notifications – essential for user experience.
3. Peer Review – if you plan to use that module.
4. RAG Assistant – just the /ai/rag-chat endpoint (calling a local LLM) – it’s highly requested.
5. Lab Inventory – if you need that module.
6. Projects & Data Hub – for collaboration.
7. TOTP & Voice settings – nice to have.
8. Analytics – can be added later.

---

✅ Final Recommendation

Your backend is already a solid foundation. By following the above plan, you can extend it to support all frontend features without rewriting the core. The modular route system makes adding new endpoints straightforward. For real‑time collaborative editing, use the external y-websocket server – don't reinvent it.