Issue Title: Deep link authorization fails and model activation broken in Glass (Electron)
Description:
I am experiencing two critical issues preventing normal usage of Glass:
Deep link authorization via pickleglass:// protocol does not work in Electron.
Glass fails to activate locally installed Ollama models (e.g., mistral:7b, llama3.1:8b).
Environment
OS: Windows 11 Pro (10.0.26200)
Node.js: v20.18.0
npm: 10.8.2
Electron: 30.5.1
Ollama: 0.30.8
Glass version: 0.2.4 (fresh clone from main branch)
Steps taken: Full clean reinstall (removed node_modules, Glass app data, re-cloned and rebuilt).
Issue 1: Deep link authorization fails
Steps to reproduce:
Launch Glass (npm start).
Click "Open browser to login".
Complete Google OAuth flow in the browser.
Google redirects to pickleglass://?uid=...&email=...&displayName=....
Windows shows the prompt "This website wants to open Electron" → click Open.
Electron crashes with error:
Unable to find Electron app at ...?uid=default_user&email=contact@pickle.com&displayName=Default%20User
Cannot find module ...?uid=default_user...
Expected behavior:
Glass should parse the uid, email, displayName parameters from the deep link and authenticate the user (or set local mode) without crashing.
Actual behavior:
Electron interprets the entire pickleglass://?uid=... string as a file path and tries to require() it, causing a module-not-found error.
Additional context:
Protocol pickleglass:// is registered correctly in Windows Registry (verified via HKCU\Software\Classes\pickleglass).
Glass has app.setAsDefaultProtocolClient('pickleglass') in index.js, but no explicit handler for the incoming URL parameters (e.g., protocol.handle('pickleglass', ...) seems to be missing or not parsing searchParams correctly).
As a workaround, I am avoiding Google login and using the built-in default_user with mode: 'local', but the app still reports isLoggedIn: false.
Issue 2: Model activation fails for locally installed Ollama models
Steps to reproduce:
Install Ollama (0.30.8) and pull models: ollama pull mistral:7b, ollama pull llama3.1:8b.
Start Glass (npm start).
Open Settings → Models → select provider Ollama and manually type mistral:7b (or llama3.1:8b).
Save settings and restart Glass.
Observed behavior:
Glass logs the following error repeatedly:
text
[ModelStateService] No provider found for model mistral:7b
[ModelStateService] No valid LLM model selected or selection forced. Finding an alternative...
Even though ollama list shows the models correctly and http://localhost:11434/api/tags returns a valid JSON list, Glass refuses to accept any model name with a version/size suffix (:7b, :8b, :latest).
Workarounds tried:
Creating an alias: ollama cp mistral:7b mistral and setting llm_model: "mistral" → still fails with No provider found for model mistral.
Editing ~/.config/Glass/pickle-glass-settings.json manually → no effect.
Trying llama3:latest, phi3:mini — same error.
Expected behavior:
Glass should accept any model name returned by the Ollama API, or at least support common names with version suffixes (mistral:7b, llama3.1:8b), or provide a dropdown list of available models from the running Ollama server.
Actual behavior:
Glass uses a hardcoded or narrow list of model names that does not match modern Ollama model naming conventions, making it impossible to select any local model.
Additional notes
The AskService window (ask) does not appear because no valid LLM is selected.
The frontend builds successfully (npm run build in pickleglass_web), and the app starts without other errors.
No relevant errors appear in DevTools Console except Autofill.enable warning.
Suggested fixes
For deep link: Implement protocol.handle('pickleglass', ...) in the main process to parse URL parameters and pass them to AuthService instead of treating the URL as a file path.
For model activation: Either:
Whitelist all model names returned by Ollama API dynamically, or
Remove the hardcoded restriction and allow users to type any model name, or
Provide a dropdown list fetched from http://localhost:11434/api/tags at runtime.
Logs
Attached relevant log snippets (full logs available on request).
Contact
If you need more details, feel free to ask.
Issue Title: Deep link authorization fails and model activation broken in Glass (Electron)
Description:
I am experiencing two critical issues preventing normal usage of Glass:
Deep link authorization via pickleglass:// protocol does not work in Electron.
Glass fails to activate locally installed Ollama models (e.g., mistral:7b, llama3.1:8b).
Environment
OS: Windows 11 Pro (10.0.26200)
Node.js: v20.18.0
npm: 10.8.2
Electron: 30.5.1
Ollama: 0.30.8
Glass version: 0.2.4 (fresh clone from main branch)
Steps taken: Full clean reinstall (removed node_modules, Glass app data, re-cloned and rebuilt).
Issue 1: Deep link authorization fails
Steps to reproduce:
Launch Glass (npm start).
Click "Open browser to login".
Complete Google OAuth flow in the browser.
Google redirects to pickleglass://?uid=...&email=...&displayName=....
Windows shows the prompt "This website wants to open Electron" → click Open.
Electron crashes with error:
Unable to find Electron app at ...?uid=default_user&email=contact@pickle.com&displayName=Default%20User
Cannot find module ...?uid=default_user...
Expected behavior:
Glass should parse the uid, email, displayName parameters from the deep link and authenticate the user (or set local mode) without crashing.
Actual behavior:
Electron interprets the entire pickleglass://?uid=... string as a file path and tries to require() it, causing a module-not-found error.
Additional context:
Protocol pickleglass:// is registered correctly in Windows Registry (verified via HKCU\Software\Classes\pickleglass).
Glass has app.setAsDefaultProtocolClient('pickleglass') in index.js, but no explicit handler for the incoming URL parameters (e.g., protocol.handle('pickleglass', ...) seems to be missing or not parsing searchParams correctly).
As a workaround, I am avoiding Google login and using the built-in default_user with mode: 'local', but the app still reports isLoggedIn: false.
Issue 2: Model activation fails for locally installed Ollama models
Steps to reproduce:
Install Ollama (0.30.8) and pull models: ollama pull mistral:7b, ollama pull llama3.1:8b.
Start Glass (npm start).
Open Settings → Models → select provider Ollama and manually type mistral:7b (or llama3.1:8b).
Save settings and restart Glass.
Observed behavior:
Glass logs the following error repeatedly:
text
[ModelStateService] No provider found for model mistral:7b
[ModelStateService] No valid LLM model selected or selection forced. Finding an alternative...
Even though ollama list shows the models correctly and http://localhost:11434/api/tags returns a valid JSON list, Glass refuses to accept any model name with a version/size suffix (:7b, :8b, :latest).
Workarounds tried:
Creating an alias: ollama cp mistral:7b mistral and setting llm_model: "mistral" → still fails with No provider found for model mistral.
Editing ~/.config/Glass/pickle-glass-settings.json manually → no effect.
Trying llama3:latest, phi3:mini — same error.
Expected behavior:
Glass should accept any model name returned by the Ollama API, or at least support common names with version suffixes (mistral:7b, llama3.1:8b), or provide a dropdown list of available models from the running Ollama server.
Actual behavior:
Glass uses a hardcoded or narrow list of model names that does not match modern Ollama model naming conventions, making it impossible to select any local model.
Additional notes
The AskService window (ask) does not appear because no valid LLM is selected.
The frontend builds successfully (npm run build in pickleglass_web), and the app starts without other errors.
No relevant errors appear in DevTools Console except Autofill.enable warning.
Suggested fixes
For deep link: Implement protocol.handle('pickleglass', ...) in the main process to parse URL parameters and pass them to AuthService instead of treating the URL as a file path.
For model activation: Either:
Whitelist all model names returned by Ollama API dynamically, or
Remove the hardcoded restriction and allow users to type any model name, or
Provide a dropdown list fetched from http://localhost:11434/api/tags at runtime.
Logs
Attached relevant log snippets (full logs available on request).
Contact
If you need more details, feel free to ask.