diff --git a/specs/Makefile b/specs/Makefile deleted file mode 100644 index 4646dfdcd2..0000000000 --- a/specs/Makefile +++ /dev/null @@ -1,14 +0,0 @@ -spec: - @echo "Initiating a Spec..." - @last_number=$$(ls $(CURDIR)/jan-[0-9][0-9][0-9]-* | sort -V | tail -n 1 | cut -d '-' -f 2); \ - last_number=$$(echo $$last_number | sed 's/^0*//'); \ - next_number=$$(printf "%03d" $$(( $$last_number + 1 ))); \ - read -p "Enter Spec title: " title; \ - title=$$(echo $$title | tr ' ' '-'); \ - cp $(CURDIR)/spec-template.md $(CURDIR)/jan-$$next_number-$$title.md; \ - date=$$(date +%Y-%m-%d); \ - usernames=$$(git config user.name); \ - sed -i '' 's/{SPEC-NUM}/'$$next_number'/g' $(CURDIR)/jan-$$next_number-$$title.md; \ - sed -i '' 's/{TITLE}/'$$title'/g' $(CURDIR)/jan-$$next_number-$$title.md; \ - sed -i '' 's/{DATE}/'$$date'/g' $(CURDIR)/jan-$$next_number-$$title.md; \ - sed -i '' 's/{USERNAMES}/'$$usernames'/g' $(CURDIR)/jan-$$next_number-$$title.md \ No newline at end of file diff --git a/specs/QA-checklist.md b/specs/QA-checklist.md new file mode 100644 index 0000000000..8bb5168ddb --- /dev/null +++ b/specs/QA-checklist.md @@ -0,0 +1,188 @@ +# Regression test + +**Release Version:** v0.6.0 + +**Operating System:** + +--- + +## A. Installation, Update, and Uninstallation + +### 1. Users install app (New user flow) + +- [ ] :rocket: Installation package is not corrupted and passes all security checks. +- [ ] :key: App launches successfully after installation. + +### 2. Users update app (Existing user flow) + +- [ ] :key: Validate that the update does not corrupt user data or settings. +- [ ] :key: App restarts or prompts the user to restart after an update. +- [ ] When updating the app, check if the `/models` directory has any JSON/YML files that change according to the update. +- [ ] Updating the app also updates extensions correctly, test functionality changes. + +### 3. Users uninstall / close app + +- [ ] :key: After closing the app, all models are unloaded. +- [ ] :key::warning: Uninstallation process removes the app successfully from the system. +- [ ] Clean the data folder and open the app to check if it creates all the necessary folders, especially models and extensions. + + +## B. Overview + +### 1. Shortcut key + +- [ ] :key: Test each shortcut key to confirm it works as described (My models, navigating, opening, closing, etc.). + +### 2. Users check the `active model` + +- [ ] :key: The app correctly displays the state of the loading model (e.g., loading, ready, error). +- [ ] :key: Confirm that the app allows users to switch between models if multiple are available. +- [ ] Check that the app provides feedback or instructions if the model fails to load. +- [ ] Verify the troubleshooting assistant correctly capture hardware / log info [#1784](https://github.com/janhq/jan/issues/1784) + +## C. Thread + +### 1. Users can chat with Jan, the default assistant + +- [ ] :key: Sending a message enables users to receive responses from model. +- [ ] :key: Conversation thread is maintained without any loss of data upon sending multiple messages. +- [ ] ‌Users should be able to edit msg and the assistant will re-generate the answer based on the edited version of the message. +- [ ] Test for the ability to send different types of messages (e.g., text, emojis, code blocks). +- [ ] Check the output format of the AI (code blocks, JSON, markdown, ...). +- [ ] :key: Validate the scroll functionality in the chat window for lengthy conversations. +- [ ] User can copy / delete the response. +- [ ] :key: Check the `clear message` / `delete entire chat` button works. +- [ ] Deleting all the chat retains the model instruction and settings. +- [ ] :key: Appropriate error handling and messaging if the assistant fails to respond. +- [ ] Test assistant's ability to maintain context over multiple exchanges. +- [ ] :key: Check the `create new chat` button, and new conversation will have an automatically generated thread title based on users msg. +- [ ] Changing `models` mid-thread the app can still handle it. +- [ ] Check the `regenerate` button renews the response (single / multiple times). +- [ ] Check the `Instructions` update correctly after the user updates it midway (mid-thread). + +### 2. Users can customize chat settings like model parameters via both the GUI & model.yml + +- [ ] Adjust model parameters (e.g., Temperature, Top K, Top P) from the GUI and verify they are reflected in the chat behavior. +- [ ] :key: Changes can be saved and persisted between sessions. +- [ ] Users can access and modify the model.yml file. +- [ ] :key: Changes made in model.yml are correctly applied to the chat session upon reload or restart. +- [ ] Check the maximum and minimum limits of the adjustable parameters and how they affect the assistant's responses. +- [ ] :key: Users switch between threads with different models, the app can handle it. + +### 3. Model dropdown +- :key: Model list should highlight recommended based on user RAM (this is not really correct, I think it's based on static formula) +- [ ] Model size should display (for both installed and imported models) + +### 4. Users can click on a history thread +- [ ] Chat window displays the entire conversation from the selected history thread without any missing messages. +- [ ] Historical threads reflect the exact state of the chat at that time, including settings. +- [ ] :key: Ability to delete or clean old threads. +- [ ] Changing the title of the thread updates correctly. + +### 5. Users can config instructions for the assistant. +- [ ] Instructions set by the user are being followed by the assistant in subsequent conversations. +- [ ] :key: Changes to instructions are updated in real time and do not require a restart of the application or session. +- [ ] :key: Ability to reset instructions to default or clear them completely. +- [ ] :key: RAG - Users can import documents and the system should process queries about the uploaded file, providing accurate and appropriate responses in the conversation thread. +- [ ] :key: Jan can see - Users can import image and Model with vision can generate responses (e.g. LLaVa model). [#294](https://github.com/janhq/jan/issues/294) + + +## D. Hub + +### 1. Users can discover recommended models +- :key: Each model's recommendations are consistent with the user’s activity and preferences. +- [ ] Search models and verify results / action on the results + +### 2. Users can download models suitable for their devices, e.g. compatible with their RAM + +- [ ] Model list should be in order: Featured > Remote > Local +- [ ] :key: Ensure that models are labeled with RAM requirements. +- [ ] :key: Check the download model functionality and validate if the cancel download feature works correctly. + +### 3. Users can download models via a HuggingFace URL [#1740](https://github.com/janhq/jan/issues/1740) + +- [ ] :key: Import via Hugging Face Id / full HuggingFace URL, check the progress bar reflects the download process +- [ ] :key: Test deeplink import [#2876](https://github.com/janhq/jan/issues/2876) +- [ ] :key: Users can use / remove the imported model. + +### 4. Users can import new models to the Hub + +- [ ] :key: Ensure import successfully via drag / drop or upload GGUF. +- [ ] :key: Verify Move model binary file / Keep Original Files & Symlink option are working +- [ ] Users can add more info to the imported model / edit name +- [ ] :key: Ensure the new model updates after restarting the app. + + +### 5. Users can use the model as they want + +- [ ] :key: Check `start` / `stop` / `delete` button response exactly what it does. +- [ ] Check if starting another model stops the other model entirely. +- [ ] :rocket: Navigate to `hub` > Click `Use` button to use model. Expect to jump to thread and see the model in dropdown model selector. +- [ ] :key: Check when deleting a model it will delete all the files on the user's computer. +- [ ] :warning:The recommended tags should present right for the user's hardware. + +### 6. Users can Integrate With a Remote Server +- [ ] :key: Import openAI GPT model https://jan.ai/guides/using-models/integrate-with-remote-server/ and the model displayed in Hub / Thread dropdown +- [ ] Users can use the remote model properly (openAI GPT, Groq) + +## E. System Monitor + +### 1. Users can see disk and RAM utilization + +- [ ] :key: Verify that the RAM and VRAM utilization graphs accurately reported in real time. +- [ ] :key: Validate that the utilization percentages reflect the actual usage compared to the system's total available resources. +- [ ] :key: Ensure that the system monitors updates dynamically as the models run and stop. + +### 2. Users can start and stop models based on system health + +- [ ] :key: Verify the `Start/Stop` action for a model, the system resource usage reflects this change. +- [ ] Confirm that any changes in model status (start/stop) are logged or reported to the user for transparency. +- [ ] :key: Check the functionality of `App log` to ensure it opens the correct folder in the system file explorer. + +## F. Settings + +### 1. Appearance + +- [ ] :key: Test the `Light`, `Dark`, and `System` theme settings to ensure they are functioning as expected. +- [ ] Confirm that the application saves the theme preference and persists it across sessions. +- [ ] Validate that all elements of the UI are compatible with the theme changes and maintain legibility and contrast. + +### 2. Extensions [TBU] + +- Validate the `Install Extensions` process by selecting and installing a plugin file. +- [ ] Enable / disable extensions and the UI should reflex accordingly + +### 3. Extension group + +- [ ] :key: Users can set valid Endpoint and API Key to use remote models +- [ ] Monitoring extension should allow users to enable / disable log and set log Cleaning Interval + + +### 4. Advanced settings + +- [ ] :key: Test the `Experimental Mode` toggle to confirm it enables or disables experimental features as intended. +- [ ] :key: Check the functionality of `Open App Directory` to ensure it opens the correct folder in the system file explorer. +- [ ] Users can move **Jan data folder** +- [ ] Validate that changes in advanced settings are applied immediately or provide appropriate instructions if a restart is needed. +- [ ] Attemp to test downloading model from hub using **HTTP Proxy** [guideline](https://github.com/janhq/jan/pull/1562) +- [ ] Logs that are older than 7 days or exceed 1MB in size will be automatically cleared upon starting the application. +- [ ] Users can click on Reset button to **factory reset** app settings to its original state & delete all usage data. + - [ ] Keep the current app data location + - [ ] Reset the current app data location +- [ ] Users can enable the setting and chat using quick ask. + +### 5. Engine +- [ ] :key: TensorRT Engine - Users able to chat with the model +- [ ] :key: Onnx Engine - Users able to chat with the model +- [ ] :key: Other remote Engine - Users able to chat with the model + +## G. Local API server + +### 1. Local Server Usage with Server Options +- [ ] :key: Explore API Reference: Swagger API for sending/receiving requests + - [ ] Use default server option + - [ ] Configure and use custom server options +- [ ] Test starting/stopping the local API server with different Model/Model settings +- [ ] Server logs captured with correct Server Options provided +- [ ] Verify functionality of Open logs/Clear feature +- [ ] Ensure that threads and other functions impacting the model are disabled while the local server is running diff --git a/specs/README.md b/specs/README.md deleted file mode 100644 index 25b342ef5e..0000000000 --- a/specs/README.md +++ /dev/null @@ -1,19 +0,0 @@ -# Jan Improvement Proposals - -This is a repo of key architecture decisions for Jan. - -[Read more about ADRs](https://github.com/joelparkerhenderson/architecture-decision-record) - -### Get started: - -```sh -# In root: -make newadr -``` - -### Template: -- **Status**: `pending`, `approved`, or `rejected` -- **Context**: a clearly defined problem/goal -- **Decisions**: the proposed architecture choices & changes -- **Consequences**: pros and cons of the decision -- **References**: any relevant materials to read \ No newline at end of file diff --git a/specs/adrs/adr-001-jan-deployable-cloud-native.md b/specs/adrs/adr-001-jan-deployable-cloud-native.md deleted file mode 100644 index d07bd26ffb..0000000000 --- a/specs/adrs/adr-001-jan-deployable-cloud-native.md +++ /dev/null @@ -1,54 +0,0 @@ -# ADR #001: Jan deployable cloud-native - -## Changelog - -- 23.10.03: Initial unfinished draft -- 23.10.16: Remove authentication - -## Authors - -- @nam-john-ho -- @louis - -## Context - -### Status Quo - -* User doesn't have a local GPU machine but wants to run Jan on a rented server -* User wants a quick, fast way to experiment with Jan on a rented GPU -* https://github.com/janhq/jan/issues/255 - -## Decision - -* This ADR aims to outline design decisions for deploying Jan in cloud native environments such as: Runpod, AWS, Azure, GCP in a fast and simple way. -* The current code-base should not change too much. -* The current plugins must be reusable across environments (Desktop, Cloud-native). - - -### Key Design Decisions -![Key Design](images/adr-001-02.png "Key Design") -#### Why middleware -* The /web codebase needs to operate in both browser and electron environments -* The /web codebase needs to route plugin routes accordingly, either to /server or /electron -* Middleware takes care of this -* We will have a /server codebase that takes care of routing to plugins -#### Unsuitable Alternatives -* Not possible to just run electron headless -* /web is on a different chromium window -* Does not have all the electron handlers -* Does not have the IPC handler - -## Alternative Approaches -Separated server process runs along side with electron. https://github.com/janhq/jan/pull/184/commits/6005409a945bb0e80a61132b9eb77f47f19d0aa6 - -## Considerations -* Due to the limitation of accessing the file system in web browsers, the first version of the web app will load all the current plugins by default, and users will not be able to add, remove, or update plugins. -* Simple authentication will be implemented as a plugin. - -## References - -- https://www.runpod.io/console/templates -- https://repost.aws/articles/ARQ0Tz9eorSL6EAus7XPMG-Q/how-to-install-textgen-webui-on-aws -- https://www.youtube.com/watch?v=_59AsSyMERQ -- https://gpus.llm-utils.org/running-llama-2-on-runpod-with-oobaboogas-text-generation-webui/ -- https://medium.com/@jarimh1984/installing-oobabooga-and-oobabooga-api-to-runpod-cloud-step-by-step-tutorial-47457974dfa5 diff --git a/specs/adrs/adr-002-jan-ai-apps.md b/specs/adrs/adr-002-jan-ai-apps.md deleted file mode 100644 index 61dfde8479..0000000000 --- a/specs/adrs/adr-002-jan-ai-apps.md +++ /dev/null @@ -1,55 +0,0 @@ -# ADR #002: Jan AI apps - -## Changelog -- Oct 4th 2023: Initial draft -- Oct 6th 2023: Update sample API - -## Authors -- @vuonghoainam - Hiro -- @louis-jan - -## Status -Proposed - -## Context - -### Business context -Jan can be a platform and let builders build their own `AI app` using existing tools -- Use-case 1: Medical AI startup uploads "case notes" to Jan, wants to ask it questions (i.e. medical audit) -- Use-case 2: Legal e-discovery: very large amount of documents (~10-15k pages) are uploaded, data is very private and cannot be leaked -- Use-case 3: Jan wants to use Jan to have a QnA chatbot to answer questions on docs -- Use-case 4: Jan wants to use Jan to have a codellama RAG on its own codebase, to generate new PRs - -### Extra context -- There are many use cases that the community can develop and sell to the users through Jan as plugin. Jan needs to streamline higher value chain. -- This brings more value and more option to all kind of user -- This can help building ecosystem and streamline value end to end (Jan, plugins/ model creators, Jan users - enterprise/ individual) -- We at Jan cannot build plugins more on our own, but this one should serve as featured example like [OpenAI Retrieval plugin](https://github.com/openai/chatgpt-retrieval-plugin) does. -- [#232](https://github.com/janhq/jan/issues/232) - -## Decision - -- User can browse and install plugins (with recommended model - llama2, claude, openai …) - This requires plugin dependencies. -- Jan provide consistent interface for plugin developer to use: - - Use LLM (this can be switched in runtime) - i.e Dev in llama2-7b but user can use with llama2-70b. Can choose another model as well - - Plugin can have API for CRUD indices in vectorDB/ DB, and Jan only exposes corresponding data to the app - - A place for a plugin to store the files for persistence -- This works seamlessly on desktop/ Jan hosted version with Jan API abstraction. - -### Simple UX -![UX](images/adr-002-01.png "UX") - -### Component design -![Component design](images/adr-002-02.png "Component design") - -## API -- `jan.plugin..(**args)` - -- `jan.core.db.sql.command()` -> CRUD/ query -- `jan.plugin.vectra.(**args)` -> CRUD/ query for -## Consequences -- Jan user can build their own AI apps (and buy from others too) in an easy way -- Clear design for plugin and Jan platform development - -## Reference -- [ADR-003](adr-003-jan-plugins.md) \ No newline at end of file diff --git a/specs/adrs/adr-003-jan-plugins.md b/specs/adrs/adr-003-jan-plugins.md deleted file mode 100644 index 8dd5b282a7..0000000000 --- a/specs/adrs/adr-003-jan-plugins.md +++ /dev/null @@ -1,65 +0,0 @@ -# ADR 003: JAN PLUGINS - -## Changelog - -- Oct 5th 2023: Initial draft - -## Status - -Accepted - -## Context - -Modular Architecture w/ Plugins: - -- Jan will have an architecture similar to VSCode or k8Lens -- "Desktop Application" whose functionality can be extended thru plugins -- Jan's architecture will need to accommodate plugins for (a) Persistence(b) IAM(c) Teams and RBAC(d) Policy engines(e) "Apps" (i.e. higher-order business logic)(f) Themes (UI) -- Nitro's architecture will need to accommodate plugins for different "model backends"(a) llama.cpp(b) rkwk (and others)(c) 3rd-party AIs - -## Decision - -![Architecture](./images/adr-003-01.png) - -## Consequences - -What becomes easier or more difficult to do because of this change? - -## CoreService API - -Jan frontend components will communicate with plugin functions via Service Interfaces: - -All of the available APIs are listed in [CoreService](../web/shared/coreService.ts) - -- Data Service: - - - GET_CONVERSATIONS: retrieve all of the conversations - - CREATE_CONVERSATION: start a new conversation - - DELETE_CONVERSATION: delete an existing conversation - - GET_CONVERSATION_MESSAGES: retrieve a certain conversation messages - - CREATE_MESSAGE: store a new message (both sent & received) - - UPDATE_MESSAGE: update an existing message (streaming) - - STORE_MODEL: store new model information (when clicking download) - - UPDATE_FINISHED_DOWNLOAD: mark a model as downloaded - - GET_UNFINISHED_DOWNLOAD_MODELS: retrieve all unfinished downloading model (TBD) - - GET_FINISHED_DOWNLOAD_MODELS: retrieve all finished downloading model (TBD) - - DELETE_DOWNLOAD_MODEL: delete a model (TBD) - - GET_MODEL_BY_ID: retrieve model information by its ID - -- Inference Service: - - - INFERENCE_URL: retrieve inference endpoint served by plugin - - INIT_MODEL: runs a model - - STOP_MODEL: stop a running model - -- Model Management Service: (TBD) - - - GET_AVAILABLE_MODELS: retrieve available models (deprecate soon) - - GET_DOWNLOADED_MODELS: (deprecated) - - DELETE_MODEL: (deprecated) - - DOWNLOAD_MODEL: start to download a model - - SEARCH_MODELS: explore models with search query on HuggingFace (TBD) - -- Monitoring service: - - GET_RESOURCES_INFORMATION: retrieve total & used memory information - - GET_CURRENT_LOAD_INFORMATION: retrieve CPU load information diff --git a/specs/adrs/adr-004-UI-Service.md b/specs/adrs/adr-004-UI-Service.md deleted file mode 100644 index cb15e9f99e..0000000000 --- a/specs/adrs/adr-004-UI-Service.md +++ /dev/null @@ -1,52 +0,0 @@ -# ADR 004: UI Service - -## Changelog - -- 10 Oct 2023: initial vision @dan-jan @0xSage - -## Status - -Proposed - -## Context - -Plugin devs need an API to change the Jan UI. Before we layer on more features, let's ensure good devex for feature building. - -## Decision - -![Jan UI Framework](./images/jan-ui-framework.png) - -- Side-Ribbon: Jan Apps - - - This is a protected area, for Apps - - Apps can define Left Panel, Center, and Right Panel - - We will only have 1 App for now (no need to build this abstraction yet) - - Future: Server mode (see LMStudio), Art Studio (Stable Diffusion) - -- Side-Ribbon: Global Settings - - - These will all open in a modal - - Currently: Model Store, Running Models - - Currently: User Login, Settings - -- Main Window and Right Panel - - - These will mainly be session-based - -- Console: production logs - -## UiService API - -We need a UI API for Plugins - -- e.g. Model Store plugin -> Registers "Global Settings" Icon, defines what will show up in the Modal -- e.g. Model Runner plugin -> Inference Parameters - -## Consequences - -- Increased code complexity - -## Reference - -- VSCode -- Obsidian diff --git a/specs/adrs/adr-005-model-installation.md b/specs/adrs/adr-005-model-installation.md deleted file mode 100644 index f0f45ffb17..0000000000 --- a/specs/adrs/adr-005-model-installation.md +++ /dev/null @@ -1,48 +0,0 @@ -# ADR 005: model-installation - -## Changelog - -- 2023-10-18: Initial draft - -## Authors - -- 0xSage - -## Status - -Proposed - -## Context - -There are a few issues with our current model installation method (hardcoding jsons in /models repo): - -- Users want to add their own model binaries -- Maintaining /models is too manual - -## Decision - -Let Users download models on their own & manually import them to Jan via a "add a model" UI - -Links: - -- Github issue: https://github.com/janhq/jan/issues/359 -- Related issue: https://github.com/janhq/jan/issues/304 -- Designs: https://www.figma.com/file/JdK7cNIBeVdYeHxKiYeWtk/JAN---Web?type=design&node-id=4092-58218&mode=design&t=8OmFSG0E6I8Y3IjY-0 - -## Consequences - -Closed alternate solutions: - -- https://github.com/janhq/jan/issues/328 - -## Alternatives - -Thinking through the model selection experience, there are a few possibilities: - -1. [current] We hardcode models (via Github) to show up in Explore Models => unnecessarily manual, missing models users want -1. We mirror HF models for a faster download => users can also do nitro add llama2 -1. [CHOSEN] Users download models on their own & manually import them to Jan via a "add a model" UI => I like this option actually -1. [LATER] Users paste in a HF link and download the model in Explore Models => do we still render model cards for them? -1. Users manage their own models folder, e.g. /Users/nicole/models, then they set folder path in Jan. => this one needs a lot of designs/fe work - -## Reference diff --git a/specs/adrs/adr-006-jan-core-module.md b/specs/adrs/adr-006-jan-core-module.md deleted file mode 100644 index 5f3dd1ccb9..0000000000 --- a/specs/adrs/adr-006-jan-core-module.md +++ /dev/null @@ -1,36 +0,0 @@ -# ADR 006: jan-core-module - -## Changelog - -- 2023-10-19: Initial draft - -## Authors - -- Louis - -## Status - -Accepted - -## Context - -Currently, developers face several challenges while writing a plugin, which include: -- Registering functions using the function name as a string -- Invoking anonymous functions -- No access to native APIs or common functions for data insertion or retrieval -- Lack of communication between the app and plugins. - -## Decision - -Let developers install and import an npm module to develop our Plugin easier. - -Upon boot, Web plugs in window modules. Its components and plugins can then import the core to access exposed functions. - -![Jan Core Module](./images/jan-core-module.png) -## Consequences - -Separate PRs should be created for updating the core and app. For instance, if a new app enhancement requires the core module to expose a new API, a new core update must be published on npm to prevent CI failure. - -## Alternatives - -## Reference diff --git a/specs/adrs/adr-007-jan-plugin-catalog.md b/specs/adrs/adr-007-jan-plugin-catalog.md deleted file mode 100644 index 0ba495471e..0000000000 --- a/specs/adrs/adr-007-jan-plugin-catalog.md +++ /dev/null @@ -1,35 +0,0 @@ -# ADR 007: jan-plugin-catalog - -## Changelog - -- 2023-10-19: Initial draft - -## Authors - -- Louis - -## Status - -Proposed - -## Context - -Users should be able to explore plugins, and developers need a channel to publish their plugins - -Lesson learned from the Model Catalog: we hosted everything on Github and attempted to retrieve it anonymously, which cost us a lot of effort and led to a limit rate issue. Let's say there are N items in the catalog, and we attempted to send N+1 requests at a time. It was costly and led to an API limit rate issue. - -## Decision - -1. Combine all JSON items in the catalog into one JSON catalog. Now we just need to work with one catalog file, which means only one request, but the rate limit issue still exists. -2. CDN - there are cool services out there which support OSS projects, such as [JSDELIVR](https://www.jsdelivr.com). -3. Downloading a JSON file is not a good approach, though. Exporting a module works better. Webpack + DefinePlugin should work. -4. Since we have created a new module, we want to publish it as well. Let's publish it on npm so everyone can install and use it. This is also to add a versioning feature. -5. Installing this npm module would require the user to update their app to the latest version. Instead, let's import the remote module via CDN, which requires just a few lines of code. - -![Jan Plugin Catalog](./images/jan-plugin-catalog.png) - -## Consequences - -## Alternatives - -## Reference diff --git a/specs/adrs/adr-008-Extensible-Jan-with-Docker.md b/specs/adrs/adr-008-Extensible-Jan-with-Docker.md deleted file mode 100644 index 05e72956a1..0000000000 --- a/specs/adrs/adr-008-Extensible-Jan-with-Docker.md +++ /dev/null @@ -1,36 +0,0 @@ -# ADR 008: Extensible-Jan-with-Docker - -## Changelog - -- 2023-10-24: Initial draft - -## Authors - -- @vuonghoainam - -## Status -Proposed - -## Context - -What is the issue that we're seeing that is motivating this decision or change? -- The A.I world is moving fast with multiple runtime/ prebaked environment. We or the builder cannot cover just everything but rather we should adopt it and facilitate it as much as possible within Jan. -- For `Run your own A.I`: Builder can build app on Jan (NodeJS env) and connect to external endpoint which serves the real A.I - - e.g 1: Nitro acting as proxy to `triton-inference-server` running within a Docker container controlled by Jan app - - e.g 2: Original models can be in many formats (pytorch, paddlepaddle). In order to run it with the most optimized version locally, there must be a step to transpile the model ([Ollama import model](https://github.com/jmorganca/ollama/blob/main/docs/import.md), Tensorrt). Btw Jan can prebuilt it and let user pull but later -- For `Build your own A.I`: User can fine tune model locally (of course Jan help it with remote but later) - -## Decision - -What is the change that we're proposing and/or doing? -- Add Docker client as Core module - [Docker node](https://github.com/apocas/dockerode) -- 2 example A.I app (adr-002) to demonstrate it and actually use! - -## Consequences - -What becomes easier or more difficult to do because of this change? -- We can extend limitlessly :D - -## Alternatives - -## Reference diff --git a/specs/images/adr-001-01.png b/specs/images/adr-001-01.png deleted file mode 100644 index c56ebb530c..0000000000 Binary files a/specs/images/adr-001-01.png and /dev/null differ diff --git a/specs/images/adr-001-02.png b/specs/images/adr-001-02.png deleted file mode 100644 index 8649b671a6..0000000000 Binary files a/specs/images/adr-001-02.png and /dev/null differ diff --git a/specs/images/adr-002-01.png b/specs/images/adr-002-01.png deleted file mode 100644 index 18b1df775e..0000000000 Binary files a/specs/images/adr-002-01.png and /dev/null differ diff --git a/specs/images/adr-002-02.png b/specs/images/adr-002-02.png deleted file mode 100644 index 2c2cb1b520..0000000000 Binary files a/specs/images/adr-002-02.png and /dev/null differ diff --git a/specs/images/adr-003-01.png b/specs/images/adr-003-01.png deleted file mode 100644 index 6328ede263..0000000000 Binary files a/specs/images/adr-003-01.png and /dev/null differ diff --git a/specs/images/jan-core-module.png b/specs/images/jan-core-module.png deleted file mode 100644 index 2aa6272ba9..0000000000 Binary files a/specs/images/jan-core-module.png and /dev/null differ diff --git a/specs/images/jan-plugin-catalog.png b/specs/images/jan-plugin-catalog.png deleted file mode 100644 index e6885e60ed..0000000000 Binary files a/specs/images/jan-plugin-catalog.png and /dev/null differ diff --git a/specs/images/jan-ui-framework.png b/specs/images/jan-ui-framework.png deleted file mode 100644 index 24beeefd5f..0000000000 Binary files a/specs/images/jan-ui-framework.png and /dev/null differ diff --git a/specs/jan-001-log-framework.md b/specs/jan-001-log-framework.md deleted file mode 100644 index 5af88d423a..0000000000 --- a/specs/jan-001-log-framework.md +++ /dev/null @@ -1,101 +0,0 @@ -# jan-001: Application Logs Framework - -| Proposal | jan-001 | -| ---------- | ----------------------------------------------------- | -| Title | App Logging | -| Authors | @louis-jan | -| Permalink | | -| Discussion | [issue #528](https://github.com/janhq/jan/issues/528) | -| Status | Idea | - -## Changelog - -| Date | Author | Changes | -| ------------ | ---------- | ------------- | -| Nov 2nd 2023 | @louis-jan | Initial Draft | - -## Summary - -This proposal suggests the implementation of an "App logging as file and log window" feature, which aims to address the problem of limited visibility into the operation of a production application. Currently, logs (info, verbose, error) are hidden, making it challenging for both users and developers to debug and support the application. The proposed solution involves logging application-wide activities to a file while also enabling real-time log monitoring through a dedicated log window within the application. - -## Motivation - -### Problem Description -The lack of proper logging in production applications results in several challenges: - -1. Debugging Difficulty: When an issue arises in a production environment, developers have limited access to essential information about what happened, making it challenging to diagnose and resolve problems effectively. -2. Support Challenges: Users often encounter errors or unexpected behavior, and support teams struggle to gather the necessary logs to understand the issue and provide a solution promptly. -3. Lack of Real-time Insights: Real-time monitoring is essential for identifying and responding to critical events. The absence of a log window within the application prevents timely reactions to events. - -### Use Case Example -Consider an e-commerce application. In the current state, when a user faces an issue during checkout, there's no easy way for support or development teams to see what went wrong in real time. This results in frustration for the user and a loss of business for the company - -```ts -# Current Status (Without the Feature) -try: - # Checkout logic - # ... -except Exception as e: - # Error handling - console.log(err) - # Insufficient logging -``` - -Without proper logging, it is challenging to diagnose the issue and provide immediate assistance. - -## Proposed solution - -### High-level overview -The proposed solution introduces the following key changes: - -1. Application-wide Logging: Implement a logging mechanism that logs application-wide activities to a designated log file. This ensures that all relevant information is captured for later analysis and debugging. -2. Real-time Log Window: Create a log window within the application that displays log entries in real time. Users and developers can open this window to monitor logs, allowing them to react promptly to events and errors. - -```ts -# With the Proposed Feature -try: - # Checkout logic - # ... -except Exception as e: - # Error handling - log.error(f"Error when downloading model: {e}") - # Proper logging - -``` - -![Image](https://github.com/janhq/jan/assets/133622055/b60f6976-8138-438e-aa4f-7e103037e124) - - -### Specification - -- The logging system will support different log levels (e.g., info, verbose, error) to ensure that the right level of detail is captured. -- Log entries will be timestamped and categorized to aid in the analysis and debugging process. -- The log window will provide options for filtering and searching log entries for ease of use. - - -### Compatibility - -This proposal aims to preserve backward compatibility by ensuring that the new logging system does not break existing functionality or affect existing applications negatively. It should not alter the semantics of valid programs. - - -### Other concerns - -- Implementation: Careful consideration should be given to the choice of logging framework and implementation details. -- Security: Access to logs and log window functionality should be restricted to authorized users to prevent potential security risks. - -### Open questions - -- What will be the default log file location, and how will it be configurable? -- Should log entries be persisted and rotated over time to prevent excessive file size? - -## Alternatives - -Alternative approaches may involve integrating with existing third-party logging systems or cloud-based log management platforms. However, this proposal focuses on a built-in solution for application-wide logging and real-time monitoring. - -## Related work - -This proposal is inspired by similar features in various application development frameworks and tools. - -## FAQ - -No frequently asked questions at this time. \ No newline at end of file diff --git a/specs/spec-template.md b/specs/spec-template.md deleted file mode 100644 index 32929affb6..0000000000 --- a/specs/spec-template.md +++ /dev/null @@ -1,33 +0,0 @@ -# jan-{SPEC-NUM}: {TITLE} - -| Proposal | jan-{SPEC-NUM} | -| ---------- | -------------- | -| Title | {TITLE} | -| Authors | | -| Permalink | | -| Discussion | | -| Status | Idea | - -## Changelog - -| Date | Author | Changes | -| ---- | ------ | ------------- | -| | | Initial Draft | - -## Abstract - -Summary. Please keep it very short. - -## Motivation - -Why? - -## Specification - -What, how? -- UX Mockups -- Code Interfaces - -## Appendix - -Everything else goes here. \ No newline at end of file