• The existing button is located in sessions/[id]/+page.svelte
• Right now it's only disabled if it has !prompt
• The only server check we do is in the Settings view and the server status not globally available.
• This is the current Typescript definition of Settings.
• We could probably save the server status to the settingsStore so we can access it from the Sessions view.
• Currently, we only check the status of the server whenever ollamaServer changes.
  • That means that if the server went offline after starting a new session the status would still appear as online.
  • This is not ideal because submitting the form to an offline server would cause an error but we should handle that behavior in #49
• Should add a new test for this behavior in sessions.test.ts

Minimum requirement:
Only run seed data and take screenshots for README.md on demand, maybe with an environment variable.

Nice to have:

• Automate the process, perhaps with a Github Action?
• Maybe keep the test as is but instead of taking a screenshot we run visual diffs.

Extended Parameter Support for Ollama API in Hollama Interface

The Hollama interface currently supports a limited set of parameters when making requests to the Ollama generate API. The current completion request payload looks like this:

let payload: OllamaCompletionRequest = {
    model: session.model,
    context: session.context,
    prompt: session.messages[session.messages.length - 1].content
};

Request

We would like to extend the Hollama interface to support more of the parameters available in the Ollama generate API. This would provide users with greater control over their interactions with the models.

Proposed Parameters to Add

Based on the Ollama API documentation, I suggest adding support for the following parameters:

1. images: For multimodal models
2. format: To specify the response format (e.g., JSON)
3. options: For additional model parameters (e.g., temperature)
4. system: To override the system message defined in the Modelfile
5. template: To override the prompt template defined in the Modelfile
6. stream: To control whether the response is streamed or returned as a single object
7. raw: To allow specifying a full templated prompt without formatting
8. keep_alive: To control how long the model stays loaded into memory

Implementation Considerations

• The interface would need to be updated to include input fields/controls for these new parameters (some of these could go in the settings page, but we may want to consider including others in the session page so that the params can be modified on a per session basis)
• Default values should be considered for optional parameters

Questions

• Are there any specific parameters that should be prioritized?
• Are there any concerns about exposing these parameters to users through the Hollama interface?

Ollama Params

REF #70

We could probably add a new userTheme: 'dark' | 'light; to $settingsStore

It'd be nice if the prompt or knowledge fields behave like the VSCode editor (monaco-editor decided to use codemirror) so you could use keyboard shortcuts to move text between line, use multiple lines selector, etc

Should match the look and feel of the existing UI.

References:

• TextFieldEditor.svelte
• @codemirror/lang-markdown

Example (source):

import {basicSetup, EditorView} from "codemirror"
import {markdown} from "@codemirror/lang-markdown"
import {languages} from "@codemirror/language-data"

// The Markdown parser will dynamically load parsers
// for code blocks, using @codemirror/language-data to
// look up the appropriate dynamic import.
let view = new EditorView({
  doc: "Hello\n\n```javascript\nlet x = 'y'\n```",
  extensions: [
    basicSetup,
    markdown({codeLanguages: languages})
  ],
  parent: document.body
})

REF #70

// FIXME: This behavior may belong in hooks.client.ts
	beforeUpdate(() => {
		if (!$settingsStore?.ollamaServer) {
			// FIXME:
			// This should only rediect to /settings if the server is not connected
			goto('/settings');
		} else {
			goto('/sessions');

• Should add an updatedAt field to Sessions
• Once Sessions have dates we should sort them in descending order, where the most recent ones are at the top.
• The current implementation already does apply sorting but not based on the date.
• A similar implementation was done for Knowledge
• In the Knowledge section we should sort the list by updatedAt as well and also display it on the UI formatted with date-fns using the formatDistance helper.
• The current Knowledge timestamp is rendered to the UI in src/routes/knowledge/+layout.svelte

When a completion is streaming from the server the variable is constantly being update so we are parsing the markdown response on every token.

This causes a weird behavior where it's hard to select and copy text because it immediately gets replaced with a new version.

• I'm leaning towards Electron mostly to keep the codebase in the same language.
• Do we want to build the app as a static site and run that inside the window? Or do we want to host a local Hollama server?
• Code-signing:
  • https://www.electron.build/code-signing
  • https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/
  • https://help.apple.com/xcode/mac/current/#/dev154b28f09

Steps to reproduce:

• Go to an existing session
• CTRL/CMD + R
• System message No model selected, choose one in the settings. appears instead of the user message.

• <pre> after a <p> has no spacing
• <code> inside <p> is styled but not inside <li>'s
• Content inside <ul>'s should be indented to the right of the bullet point Fixed by #27

Support for Multiple Knowledge Bases per Session

Current Situation

Currently, Hollama allows users to select a single knowledge entry per session. This limits the flexibility and depth of information that can be incorporated into a single conversation.

Feature Request

We propose adding support for selecting and using multiple knowledges within a single session. This would allow users to combine different sources of information, creating more comprehensive and versatile conversational contexts.

Proposed Functionality

1. User Interface Updates:

   • Modify the knowledge selection dropdown to allow multiple selections.

2. Logic Changes:

   • Modify the request payload creation to incorporate information from all selected knowledges.

Benefits

1. More comprehensive responses by combining multiple sources of information.
2. Greater flexibility in tailoring sessions to specific needs.
3. Improved ability to handle complex, multi-domain queries.

Implementation Considerations

• Should there be a limit on the number of knowledge bases that can be selected? I don't think there should be.
• How might this affect the model's context window and response generation time? This is where allowing the user to edit the Ollama num_ctx param would come in handy. See Ollama docs.
• Does Ollama support multiple CONTEXT tags? Here's a relevant snippet from ollama.ts.

	const firstMessage = session.messages[0]
	if (firstMessage.knowledge) {
		payload.prompt = `
			<CONTEXT
				name="${firstMessage.knowledge.name}"
				id="${firstMessage.knowledge.id}"
				updatedAt="${firstMessage.knowledge.updatedAt}"
			>
				${firstMessage.knowledge.content}
			</CONTEXT>

			${payload.prompt}
		`;
	}

• The Message interface would need to be updated to support a list of Knowledges. Maybe these two should be decoupled? Or better yet, maybe only the Session interface should contain the list of Knowledge's. Here's the relevant snippet from sessions.ts:

export interface Message {
	role: 'user' | 'ai' | 'system';
	content: string;
	knowledge?: Knowledge;  // Remove this one?
}

export interface Session {
	id: string;
	model: string;
	messages: Message[];
	context: number[];
	knowledge?: Knowledge;  // Make this an array of Knowledges?
}

Questions for Discussion

1. Are there any concerns about the complexity this might add for new users?
2. Should this be an "advanced" feature, or available to all users by default?

Thanks for your consideration @fmaclen! I might have time to take this one on soon if you'd like, but I know you're working on a major UI overhaul, so maybe I'll wait until that one is merged in.

REF #48

• These functions are 80% identical:
  • lib/components/sessions.ts: loadSession saveSession
  • lib/components/knowledge.ts:loadKnowledge saveKnowledge
• There might be a way to move some of this code to lib/components/store.ts

REF semantic-release https://github.com/fmaclen/svelte-currency-input/blob/main/.github/workflows/release.yml

• Here's an example of a similar implementation I've done in another Svelte project.
• The format of the titles should be:
  • ["Title of the session", "Sessions", "Hollama"]
  • ["Name of the knowledge", "Knowledge", "Hollama"]
  • ["Settings", "Hollama"]

It would be great if you could provide a docker installation....thanks!

This would helpful as a form of token-count compression.
Every 5-10 messages you could summarize and start over at a much lower token count but, hopefully, much more relevant.

• When a session has 2 or more messages in the history a button appears with the label "Summarize"
• Once clicked it changes the view to a full-screen form with these fields:
  • Choose Model select
  • Choose Knowledge select
  • A disabled "Prompt" texarea
  • A "Summarize" button to submit the form
• After summarization the "Prompt" field becomes editable
• The "Summarize" button is replaced with one that reads "New session"
• Clicking "New Session" starts a new session with the summarized session as the new prompt.

Describe:

• Tech stack
• Project setup
• Contribution guidelines
• Add PR/Issues templates

404, 500

REF https://kit.svelte.dev/docs/routing#error

This is desired indentation:

When some HTML elements are a child of something else the margin breaks:

I'm not that familiar with the Vite build process to figure out where exactly this issue is.

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.

Not 100% sure, but I think this is a casualty of having started the project with shadcn-svelte which added a lot of code.

For reference, here is where it was introduced:
#11

And where was removed:
#33

I kept the Tailwind setup and the Lucide icon library so it's possible one of those might be causing the warning.

• From "No sessions in history" to the first session
• From "Write a prompt to start a new session" to the first message in session
• Add transitions to <Article>'s but make sure the the one after handleCompletionDone isn't transitioned.

REF #70

The draggable behavior to resize the height of the text-editor has some limitations that cause the Prompt field to sometimes be too short with vertical scrollbars, among other quirks.

The ability to increase the size of the Prompt field is really useful but we don't necessarily need to allow the field to be resizable with that precision.

Instead let's add a "toggle button" that can switch the height of the prompt area from "5 lines" to "fullscreen".

• Remove PaneGroup, Pane, PaneResizer and the entire paneforge library
• In non-fullscreen mode the input is a regular <textarea /> and in "fullscreen mode" we switch to the <FieldTextEditor />
• When it's a textarea we submit the form by pressing Enter (the way it used to be before this PR), when we switch full screen we keep the same keyboard shortcut: Meta + Enter
• The full screen text editor shouldn't occupy more than 66% of the viewport so the chat history could be referenced while typing on the larger text input.
• Clicking on the fullscreen button again should "shrink" the height of the text box back to the original height.
• The size of the text input should "shrink" back to the original height after submitting a prompt.

Here's a rough mockup:

Pressing Meta + Enter submits the form AND also adds a new line in TextEditor.

It might be being fired twice. Actually, pressing ENTER once also confirms the alert once.
The test is technically also confirming the alert once so 🤷‍♂️

When we parse markdown in sessions we use highlight.js for syntax highlighting of <code> blocks.
In #58 we introduced CodeMirror which also has syntax highlighting for a variety of programming languages.

Ideally we wouldn't need 2 different libraries for syntax highlighting and we can probably use CodeMirror for everything.

Needless to say, this instance of CodeMirror should be readonly

https://github.com/markdown-it/markdown-it?tab=readme-ov-file#syntax-highlighting

• Save session/contex on browser's localStorage
• Add ability to set the Ollama server and model in the UI
• Update config to deploy to Cloudflare Pages

• Should probably need a dedicated UI component for handling error messages, such as a flash alert/toast
• When the prompt fails undo the last prompt into prompt field
• Should implement these tests.

I am trying to completely isolate the Ollama linux server from accessing outside internet and after that cannot load the Hollama UI anymore locally and remotely. Everything else in local network works as usual.

To calculate how fast the response is generated in tokens per second (token/s), divide eval_count / eval_duration.

https://github.com/ollama/ollama/blob/main/docs/api.md#response

• Existing buttons are on src/routes/+page.svelte
• The "delete all" functions are located in the same file.
• The existing tests are available in settings.test.ts
• There is a duplicated test for Delete all sessions in sessions.test.ts.
  • We should get rid of the duplicated part in settings.test.ts
• We should add the new test in knowledge.test.ts