diff --git a/docs/docs/docs/introduction.md b/docs/docs/docs/01_introduction.md similarity index 87% rename from docs/docs/docs/introduction.md rename to docs/docs/docs/01_introduction.md index 4213b14a9..0904218da 100644 --- a/docs/docs/docs/introduction.md +++ b/docs/docs/docs/01_introduction.md @@ -23,6 +23,8 @@ Jan can be used to build a variety of AI use cases, at every level of the stack: ### Modules +Jan is comprised of system-level modules that mirror OpenAIโ€™s, exposing similar APIs and objects + - Modules are modular, atomic implementations of a single OpenAI-compatible endpoint - Modules can be swapped out for alternate implementations - The default `messages` module persists messages in thread-specific `.json` @@ -38,8 +40,7 @@ Jan can be used to build a variety of AI use cases, at every level of the stack: ### Local Filesystem -- Jan runs on top of standard structure of local files on user's filesystem -- This allows for composability and tinkerability +Jan use the local filesystem for data persistence, similar to VSCode. This allows for composability and tinkerability. ```sh= /janroot # Jan's root folder (e.g. ~/jan) @@ -89,7 +90,9 @@ Jan can be used to build a variety of AI use cases, at every level of the stack: ### Jan: a "global" assistant -Jan provides `/jan`, a default assistant that is available to users out-of-the-box. It is a generic assistant to illustrate power of Jan. In the future, it will support additional features e.g. multi-assistant conversations +Jan ships with a default assistant "Jan" that lets users chat with any open source model out-of-the-box. + +This assistant is defined in `/jan`. It is a generic assistant to illustrate power of Jan. In the future, it will support additional features e.g. multi-assistant conversations - Your Assistant "Jan" lets you pick any model that is in the root /models folder - Right panel: pick LLM model and set model parameters diff --git a/docs/docs/docs/02_quickstart.md b/docs/docs/docs/02_quickstart.md new file mode 100644 index 000000000..18f6fc0aa --- /dev/null +++ b/docs/docs/docs/02_quickstart.md @@ -0,0 +1,3 @@ +--- +title: Quickstart +--- diff --git a/docs/docs/docs/apps/app-anatomy.md b/docs/docs/docs/apps/app-anatomy.md deleted file mode 100644 index 93b2d6ba8..000000000 --- a/docs/docs/docs/apps/app-anatomy.md +++ /dev/null @@ -1,202 +0,0 @@ ---- -title: Anatomy of ๐Ÿ‘‹Jan ---- - -This page explains all the architecture of [Jan](https://Jan/). - -## Synchronous architecture - -![Synchronous architecture](../img/arch-async.drawio.png) - -### Overview - -The architecture of the Jan application is designed to provide a seamless experience for the users while also being modular and extensible. - -### BackEnd and FrontEnd - -**BackEnd:** - -- The BackEnd serves as the brain of the application. It processes the information, performs computations, and manages the main logic of the system. - -:::info -This is like an [OS (Operating System)](https://en.wikipedia.org/wiki/Operating_system) in the computer. -::: - -**FrontEnd:** - -- The FrontEnd is the interface that users interact with. It takes user inputs, displays results, and communicates with the BackEnd through Inter-process communication bi-directionally. - -:::info -This is like [VSCode](https://code.visualstudio.com/) application -::: - -**Inter-process communication:** - -- A mechanism that allows the BackEnd and FrontEnd to communicate in real time. It ensures that data flows smoothly between the two, facilitating rapid response and dynamic updates. - -### Plugins and Apps -**Plugins:** - -In Jan, Plugins contains all the core features. They could be Core Plugins or [Nitro](https://github.com/janhq/nitro) - -- **Load:** This denotes the initialization and activation of a plugin when the application starts or when a user activates it. - -- **Implement:** This is where the main functionality of the plugin resides. Developers code the desired features and functionalities here. This is a "call to action" feature. - -- **Dispose:** After the plugin's task is completed or deactivated, this function ensures that it releases any resources it uses, providing optimal performance and preventing memory leaks. - -:::info -This is like [Extensions](https://marketplace.visualstudio.com/VSCode) in VSCode. -::: - -**Apps:** - -Apps are basically Plugin-like. However, Apps can be built by users for their own purposes. - -> For example, users can build a `Personal Document RAG App` to chat with specific documents or articles. - -With **Plugins and Apps**, users can build a broader ecosystem surrounding Jan. - -## Asynchronous architecture - -![Asynchronous architecture](../img/arch-async.drawio.png) - -### Overview - -The asynchronous architecture allows Jan to handle multiple operations simultaneously without waiting for one to complete before starting another. This results in a more efficient and responsive user experience. The provided diagram breaks down the primary components and their interactions. - -### Components - -#### Results - -After processing certain tasks or upon specific triggers, the backend can broadcast the results. This could be a processed data set, a calculated result, or any other output that needs to be shared. - -#### Events - -Similar to broadcasting results but oriented explicitly towards events. This could include user actions, system events, or notifications that other components should be aware of. - -- **Notify:** - -Upon the conclusion of specific tasks or when particular triggers are activated, the system uses the Notify action to send out notifications from the **Results**. The Notify action is the conduit through which results are broadcasted asynchronously, whether they concern task completions, errors, updates, or any processed data set. - -- **Listen:** - -Here, the BackEnd actively waits for incoming data or events. It is geared towards capturing inputs from users or updates from plugins. - -#### Plugins - -These are modular components or extensions designed to enhance the application's functionalities. Each plugin possesses a "Listen" action, enabling it to stand by for requests emanating from user inputs. - -### Flow - -1. Input is provided by the user or an external source. -2. This input is broadcasted as an event into the **Broadcast event**. -3. The **BackEnd** processes the event. Depending on the event, it might interact with one or several Plugins. -4. Once processed, **Broadcast result** can be sent out asynchronously through multiple notifications via Notify action. - -## Jan workflow - -![Workflow](../img/arch-flow.drawio.png) - -### Overview - -The architecture of the Jan desktop application is structured into four primary modules: "Prompt Template," "Language Model," "Output Parser," and "Apps." Let's break down each module and understand its components. - -### Prompt Template - -This is where predefined templates are stored. It sets the format and structure for user interactions. It contains: - -- **Character's definition:** - -Definitions of various characters or entities that may be interacted with or invoked during user requests (e.g., name, personality, and communication style). - -- **Model's definition:** - -Definitions related to the different language models (e.g., objectives, capabilities, and constraints) - -- **Examples:** - -Sample inputs and outputs for guidance. If given good examples, LLM could enable basic reasoning or planning skills. - -- **Input:** - -The actual user query or request that is being processed. - -### Large Language Model - -This processes the input provided. - -- **Local models:** - -These are the downloaded models that reside within the system. They can process requests without the need to connect to external resources. - -- **OpenAI:** - -This will connect you with OpenAI API, allowing the application to utilize powerful models like GPT-3.5 and GPT-4. - -:::info -To use OpenAI models, you must have an OpenAI account and secret key. You can get your [OpenAI key](https://platform.openai.com/account/api-keys) here. -::: - -- **Custom Agents:** - -These are user-defined or third-party models that can be integrated into the Jan system for specific tasks. - -### Output Parser - -Language models produce textual content. However, often, there's a need for more organized data instead of plain text. This is achieved using output parsers. - -- **Parser:** - -This component ensures that the output conforms to the desired structure and format, removing unwanted information or errors. - -### Apps - -This represents applications or extensions that can be integrated with Jan. - -- **Characters:** Characters or entities that can be utilized within the applications. - -- **Models:** Different Large Language Models, Large Multimodal Models, and Stable Diffusion models that the apps might use. - -- **RAG:** Represents a "Retrieval Augmented Generation" functionality, which helps in fetching relevant data and generating responses based on it. - -## Jan Platform - -![Platform](../img/arch-connection.drawio.png) - -### Overview - -The architecture of Jan can be thought of as a layered system, comprising of the FrontEnd, Middleware, and BackEnd. Each layer has distinct components and responsibilities, ensuring a modular and scalable approach. - -#### FrontEnd -The **FrontEnd** is the visible part of Jan that interacts directly with the user. - -- **Controller:** This is the main control unit of the FrontEnd. It processes the user's inputs, handles UI events, and communicates with other layers to fetch or send data. - -- **Apps:** This represents applications or extensions that can be integrated with Jan. - -- **Execute Request** act as the initial triggers to initiate processes within the application. - -#### Middleware - -It's a bridge between the FrontEnd and BackEnd. It's responsible for translating requests and ensuring smooth data flow. - -- **SDK:** Stands for Software Development Kit. It provides a set of tools, libraries, and guidelines for developers to build and integrate custom applications or features with Jan. - -- **Core:** It's tasked with managing the connections between the FrontEnd and BackEnd. It ensures data is routed correctly and efficiently between the two. - -- **Local Native:** Refers to the connectors that enable communication with local services or applications. This will use your own hardware to ddeploy models. - -- **Cloud Native:** As the name suggests, these connectors are tailored for cloud-based interactions, allowing Jan to leverage cloud services or interact with other cloud-based applications. - -:::info -The Middleware communicates with the BackEnd primarily through **IPC** for Local and **Http** for Cloud. -::: - -#### BackEnd - -It is responsible for data processing, storage, and other core functionalities. - -- **Plugins:** Extendable modules that can be added to the Jan system to provide additional functionalities or integrations with third-party applications. - -- **Nitro:** This is a high-performance engine or a set of services that power specific functionalities within Jan. Given its placement in the architecture, it's reasonable to assume that Nitro provides acceleration or optimization capabilities for tasks. \ No newline at end of file diff --git a/docs/docs/docs/apps/build-an-app.md b/docs/docs/docs/apps/build-an-app.md deleted file mode 100644 index 8d110424c..000000000 --- a/docs/docs/docs/apps/build-an-app.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: Build an app ---- - -# Build and publish an app - -You can build a custom AI application on top of Jan. -In this tutorial, you'll build a sample app and load it into Jan Desktop. - -## What you'll learn - -After you've completed this tutorial, you'll be able to: - -- Configure an environment for developing Jan apps. -- Compile a app from source code. -- Reload a app after making changes to it. - -## Prerequisites - -To complete this tutorial, you'll need: - -- [Git](https://git-scm.com/) installed on your local machine. -- A local development environment for [Node.js](https://node.js.org/en/about/). -- A code editor, such as [Visual Studio Code](https://code.visualstudio.com/). - -> When developing apps, one mistake can lead to unintended changes to your app. Please backup your data. - -## Development - -### Step 1: Download the sample app - -- Go to [Jan sample app](https://github.com/janhq/jan-sample-app) -- Select `Use this template button` at the top of the repository -- Select `Create a new repository` -- Select an owner and name for your new repository -- Click `Create repository` -- Git clone your new repository - -### Step 2: Installation - -> [!NOTE] -> -> You'll need to have a reasonably modern version of -> [Node.js](https://nodejs.org) handy. If you are using a version manager like -> [`nodenv`](https://github.com/nodenv/nodenv) or -> [`nvm`](https://github.com/nvm-sh/nvm), you can run `nodenv install` in the -> root of your repository to install the version specified in -> [`package.json`](./package.json). Otherwise, 20.x or later should work! - -1. :hammer_and_wrench: Install the dependencies - - ```bash - npm install - ``` - -1. :building_construction: Package the TypeScript for distribution - - ```bash - npm run bundle - ``` - -1. :white_check_mark: Check your artifact - - There will be a tgz file in your src directory now - -### Step 3: Update the App Manifest - -The [`package.json`](package.json) file lets you define your apps metadata, e.g. -app name, main entry, description and version. - -### Step 4: Implementation - -The [`src/`](./src/) directory is the heart of your app! You can replace the contents of this directory with your own code. - -- `index.ts` is your app's mainentrypoint. You can access the Web runtime and define UI in this file. -- `module.ts` is your Node runtime in which functions get executed. You should define core logic and compute-intensive workloads in this file. -- `index.ts` and `module.ts` interact with each other via RPC (See [Information flow](./app-anatomy.md#information-flow)) via [`invokePluginFunc`](../../reference/01_init.md#invokepluginfunc) - -Import the Jan SDK - -```typescript -import { core } from "@janhq/core"; -``` - -#### index.ts - -Think of this as your "app frontend". You register events, custom functions here. - -Note: Most Jan app functions are processed asynchronously. In `index.ts`, you will see that the extension function will return a `Promise`. - -```typescript -import { core } from "@janhq/core"; - -function onStart(): Promise { - return core.invokePluginFunc(MODULE_PATH, "run", 0); -} -``` - -Define custom functions and register your implementation. - -```javascript -/** - * The entrypoint for the app. - */ - -import { PluginService, RegisterExtensionPoint, core } from "@janhq/core"; - -/** - * Invokes the `run` function from the `module.js` file using the `invokePluginFunc` method. - * "run" is the name of the function to invoke. - * @returns {Promise} A promise that resolves with the result of the `run` function. - */ -function onStart(): Promise { - return core.invokePluginFunc(MODULE_PATH, "run", 0); -} - -/** - * Initializes the plugin by registering the extension functions with the given register function. - * @param {Function} options.register - The function to use for registering the extension functions - */ -export function init({ register }: { register: RegisterExtensionPoint }) { - register(PluginService.OnStart, PLUGIN_NAME, onStart); -} -``` - -#### module.ts - -Think of this as your "app backend". Your core logic implementation goes here. - -```javascript -const path = require("path"); -const { app } = require("electron"); - -function run(param: number): [] { - console.log(`execute runner ${param} in main process`); - // Your code here - return []; -} - -module.exports = { - run, -}; -``` - -## App installation - -![Manual installation](../img/build-app-1.png) - -- `Select` the built `*.tar.gz` file -- Jan will reload after new apps get installed - -## App uninstallation - -To be updated - -## App update - -To be updated diff --git a/docs/docs/docs/apps/publish-jan-app.md b/docs/docs/docs/apps/publish-jan-app.md deleted file mode 100644 index dbdfbfd10..000000000 --- a/docs/docs/docs/apps/publish-jan-app.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Publishing an app ---- - -After you have completed with local app development and want to publish to `Jan marketplace` for other to reuse, please follow the following steps - -- Step 1: Update your local `package.json` and configure `npm login` correctly -- Step 2: Run `npm publish` and set to public NPM package (so that other can install) - Please refer to our example [NPM retrieval plugin](https://www.npmjs.com/package/retrieval-plugin) -- Step 3: Go to `Jan plugin catalog`(https://github.com/janhq/plugin-catalog) and create a `Pull request` for new `App artifact` (which is a renamed version of your App `package.json`) - Please refer to example [retrieval-plugin](https://github.com/janhq/plugin-catalog/blob/main/retrieval-plugin.json) -- Step 4: We at Jan will be responsible to review and merge to `main` -- Step 5: Once your new app is on `main`, you and other Jan users can find it in `Jan marketplace` diff --git a/docs/docs/docs/img/app-anatomy-1.drawio.jpg b/docs/docs/docs/img/app-anatomy-1.drawio.jpg deleted file mode 100644 index 644acb43c..000000000 Binary files a/docs/docs/docs/img/app-anatomy-1.drawio.jpg and /dev/null differ diff --git a/docs/docs/docs/img/app-anatomy-2.drawio.jpg b/docs/docs/docs/img/app-anatomy-2.drawio.jpg deleted file mode 100644 index d8564cbc4..000000000 Binary files a/docs/docs/docs/img/app-anatomy-2.drawio.jpg and /dev/null differ diff --git a/docs/docs/docs/img/app-anatomy-3.drawio.jpg b/docs/docs/docs/img/app-anatomy-3.drawio.jpg deleted file mode 100644 index 4f2abcc7c..000000000 Binary files a/docs/docs/docs/img/app-anatomy-3.drawio.jpg and /dev/null differ diff --git a/docs/docs/docs/img/app-anatomy-4.drawio.jpg b/docs/docs/docs/img/app-anatomy-4.drawio.jpg deleted file mode 100644 index c0ca79cf1..000000000 Binary files a/docs/docs/docs/img/app-anatomy-4.drawio.jpg and /dev/null differ diff --git a/docs/docs/docs/img/app-anatomy-5.drawio.png b/docs/docs/docs/img/app-anatomy-5.drawio.png deleted file mode 100644 index 5caebb994..000000000 Binary files a/docs/docs/docs/img/app-anatomy-5.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/arch-async.drawio.png b/docs/docs/docs/img/arch-async.drawio.png deleted file mode 100644 index 85ec07c88..000000000 Binary files a/docs/docs/docs/img/arch-async.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/arch-connection.drawio.png b/docs/docs/docs/img/arch-connection.drawio.png deleted file mode 100644 index 0a9cd8927..000000000 Binary files a/docs/docs/docs/img/arch-connection.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/arch-flow.drawio.png b/docs/docs/docs/img/arch-flow.drawio.png deleted file mode 100644 index f0cbea035..000000000 Binary files a/docs/docs/docs/img/arch-flow.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/arch-sync.drawio.png b/docs/docs/docs/img/arch-sync.drawio.png deleted file mode 100644 index 191d0b4f8..000000000 Binary files a/docs/docs/docs/img/arch-sync.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/architecture-0.drawio.png b/docs/docs/docs/img/architecture-0.drawio.png deleted file mode 100644 index 55534a7e2..000000000 Binary files a/docs/docs/docs/img/architecture-0.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/architecture-1.drawio.png b/docs/docs/docs/img/architecture-1.drawio.png deleted file mode 100644 index 4897343b4..000000000 Binary files a/docs/docs/docs/img/architecture-1.drawio.png and /dev/null differ diff --git a/docs/docs/docs/img/architecture.png b/docs/docs/docs/img/architecture.png deleted file mode 100644 index 15ad4208c..000000000 Binary files a/docs/docs/docs/img/architecture.png and /dev/null differ diff --git a/docs/docs/docs/img/build-app-1.png b/docs/docs/docs/img/build-app-1.png deleted file mode 100644 index 36538ce9c..000000000 Binary files a/docs/docs/docs/img/build-app-1.png and /dev/null differ diff --git a/docs/docs/docs/img/cloudnative.png b/docs/docs/docs/img/cloudnative.png deleted file mode 100644 index 8d6268c39..000000000 Binary files a/docs/docs/docs/img/cloudnative.png and /dev/null differ diff --git a/docs/docs/guides/install/install.md b/docs/docs/guides/install/install.md deleted file mode 100644 index 5bc823348..000000000 --- a/docs/docs/guides/install/install.md +++ /dev/null @@ -1,3 +0,0 @@ ---- -title: Installation ---- \ No newline at end of file diff --git a/docs/docs/nitro/nitro.md b/docs/docs/nitro/nitro.md deleted file mode 100644 index 48092605b..000000000 --- a/docs/docs/nitro/nitro.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Nitro -slug: /nitro ---- - -Nitro, is the inference engine that powers Jan. Nitro is written in C++, optimized for edge deployment. - -โšก Explore Nitro's codebase: [GitHub](https://github.com/janhq/nitro) - -## Dependencies and Acknowledgements: - -- [llama.cpp](https://github.com/ggerganov/llama.cpp): Nitro wraps Llama.cpp, which runs Llama models in C++ -- [drogon](https://github.com/drogonframework/drogon): Nitro runs Drogon, which is a fast, C++17/20 HTTP application framework. -- (Coming soon) tensorrt-llm support. - -## Features - -In addition to the above features, Nitro also provides: - -- OpenAI compatibility -- HTTP interface with no bindings needed -- Runs as a separate process, not interfering with main app processes -- Multi-threaded server supporting concurrent users -- 1-click install -- No hardware dedendencies -- Ships as a small binary (~3mb compressed on average) -- Runs on Windows, MacOS, and Linux -- Compatible with arm64, x86, and NVIDIA GPUs - -## HTTP Interface - -Nitro offers a straightforward HTTP interface. With compatibility for multiple standard APIs, including OpenAI formats. - -```bash -curl --location 'http://localhost:3928/inferences/llamacpp/chat_completion' \ - --header 'Content-Type: application/json' \ - --header 'Accept: text/event-stream' \ - --header 'Access-Control-Allow-Origin: *' \ - --data '{ - "messages": [ - {"content": "Hello there ๐Ÿ‘‹", "role": "assistant"}, - {"content": "Can you write a long story", "role": "user"} - ], - "stream": true, - "model": "gpt-3.5-turbo", - "max_tokens": 2000 - }' -``` - -## Using Nitro - -**Step 1: Obtain Nitro**: -Access Nitro binaries from the release page. -๐Ÿ”— [Download Nitro](https://github.com/janhq/nitro/releases) - -**Step 2: Source a Model**: -For those interested in the llama C++ integration, obtain a "GGUF" model from The Bloke's repository. -๐Ÿ”— [Download Model](https://huggingface.co/TheBloke) - -**Step 3: Initialize Nitro**: -Launch Nitro and position your model using the following API call: - -```bash -curl -X POST 'http://localhost:3928/inferences/llamacpp/loadmodel' \ - -H 'Content-Type: application/json' \ - -d '{ - "llama_model_path": "/path/to/your_model.gguf", - "ctx_len": 2048, - "ngl": 100, - "embedding": true - }' -``` - -## Architecture diagram - -![Nitro Architecture](../docs/img/architecture.png) diff --git a/docs/docs/reference/01_init.md b/docs/docs/reference/01_init.md deleted file mode 100644 index ad1acc956..000000000 --- a/docs/docs/reference/01_init.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "init" ---- - -`init` is the entrypoint for your application and its custom logic. `init` is a reserved function that Jan will look for to initialize your application. - -## Usage - -Importing - -```js -// javascript -const core = require("@janhq/core"); - -// typescript -import * as core from "@janhq/core"; -``` - -Setting up event listeners - -```js -export function init({ register }) { - myListener(); -} -``` - -Setting up core service implementation - -```js -export function init({ register }: { register: RegisterExtensionPoint }) { - register(DataService.GetConversations, "my-app-id", myImplementation); -} -``` - -## RegisterExtensionPoint - -`RegisterExtensionPoint` is used for app initialization. - -It lets you register `CoreService` functions/methods with the main application. - -```js -import { RegisterExtensionPoint } from "@janhq/core"; -``` - -```js -type RegisterExtensionPoint = ( - extensionName: string, - extensionId: string, - method: Function, - priority?: number -) -``` - -## invokePluginFunc - -`invokePluginFunc` is a way to invoke your custom functions (defined in your `module.ts`) from your application client (defined in your `index.ts`) - -```js -// index.ts: your application "frontend" and entrypoint -function foo(id: number) { - return core.invokePluginFunc(MODULE_PATH, "foo", param1, ...); -} - -export function init({ register }: { register: RegisterExtensionPoint }) { - register(Service.Foo, "my-app-id", foo); -} -``` - -```js -// module.ts: your application "backend" -export function foo(param1, ...) { - // Your code here -} -``` diff --git a/docs/docs/reference/02_coreservice.md b/docs/docs/reference/02_coreservice.md deleted file mode 100644 index d9b0a80c7..000000000 --- a/docs/docs/reference/02_coreservice.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: "CoreService" ---- - -`CoreService` provides an interface for implementing custom methods in Jan. -It lets you define shared behavior across your custom application, like how your app handles state, models, or inferencing behavior. - -## Usage - -```js -import { CoreService, ... } from "@janhq/core"; -``` - -## CoreService - -The `CoreService` type bundles the following services: - -- `StoreService` -- `DataService` -- `InferenceService` -- `ModelManagementService` -- `SystemMonitoringService` -- `PreferenceService` - -## StoreService - -The `StoreService` enum represents available methods for managing the database store. It includes the following methods: - -- `CreateCollection`: Creates a new collection in the data store. -- `DeleteCollection`: Deletes an existing collection from the data store. -- `InsertOne`: Inserts a new value into an existing collection in the data store. -- `UpdateOne`: Updates an existing value in an existing collection in the data store. -- `UpdateMany`: Updates multiple records in a collection in the data store. -- `DeleteOne`: Deletes an existing value from an existing collection in the data store. -- `DeleteMany`: Deletes multiple records in a collection in the data store. -- `FindMany`: Retrieves multiple records from a collection in the data store. -- `FindOne`: Retrieves a single record from a collection in the data store. - -## DataService - -The `DataService` enum represents methods related to managing conversations and messages. It includes the following methods: - -- `GetConversations`: Gets a list of conversations from the data store. -- `CreateConversation`: Creates a new conversation in the data store. -- `DeleteConversation`: Deletes an existing conversation from the data store. -- `CreateMessage`: Creates a new message in an existing conversation in the data store. -- `UpdateMessage`: Updates an existing message in an existing conversation in the data store. -- `GetConversationMessages`: Gets a list of messages for an existing conversation from the data store. - -## InferenceService - -The `InferenceService` enum exports: - -- `InitModel`: Initializes a model for inference. -- `StopModel`: Stops a running inference model. - -## ModelManagementService - -The `ModelManagementService` enum provides methods for managing models: - -- `GetDownloadedModels`: Gets a list of downloaded models. -- `GetAvailableModels`: Gets a list of available models from data store. -- `DeleteModel`: Deletes a downloaded model. -- `DownloadModel`: Downloads a model from the server. -- `SearchModels`: Searches for models on the server. -- `GetConfiguredModels`: Gets configured models from the data store. -- `StoreModel`: Stores a model in the data store. -- `UpdateFinishedDownloadAt`: Updates the finished download time for a model in the data store. -- `GetUnfinishedDownloadModels`: Gets a list of unfinished download models from the data store. -- `GetFinishedDownloadModels`: Gets a list of finished download models from the data store. -- `DeleteDownloadModel`: Deletes a downloaded model from the data store. -- `GetModelById`: Gets a model by its ID from the data store. - -## PreferenceService - -The `PreferenceService` enum provides methods for managing plugin preferences: - -- `ExperimentComponent`: Represents the UI experiment component for a testing function. - -## SystemMonitoringService - -The `SystemMonitoringService` enum includes methods for monitoring system resources: - -- `GetResourcesInfo`: Gets information about system resources. -- `GetCurrentLoad`: Gets the current system load. - -## PluginService - -The `PluginService` enum includes plugin cycle handlers: - -- `OnStart`: Handler for starting. E.g. Create a collection. -- `OnPreferencesUpdate`: Handler for preferences update. E.g. Update instances with new configurations. - -For more detailed information on each of these components, please refer to the source code. diff --git a/docs/docs/reference/03_events.md b/docs/docs/reference/03_events.md deleted file mode 100644 index 0e0c8104d..000000000 --- a/docs/docs/reference/03_events.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "events" ---- - -`events` lets you receive events about actions that take place in the app, like when a user sends a new message. - -You can then implement custom logic handlers for such events. - -## Usage - -```js -import { events } from "@janhq/core"; -``` - -You can subscribe to NewMessageRequest events by defining a function to handle the event and registering it with the events object: - -```js -import { events } from "@janhq/core"; - -function handleMessageRequest(message: NewMessageRequest) { - // Your logic here. For example: - // const response = openai.createChatCompletion({...}) -} -function registerListener() { - events.on(EventName.OnNewMessageRequest, handleMessageRequest); -} -// Register the listener function with the relevant extension points. -export function init({ register }) { - registerListener(); -} -``` - -In this example, we're defining a function called handleMessageRequest that takes a NewMessageRequest object as its argument. We're also defining a function called registerListener that registers the handleMessageRequest function as a listener for NewMessageRequest events using the on method of the events object. - -```js -import { events } from "@janhq/core"; - -function handleMessageRequest(data: NewMessageRequest) { - // Your logic here. For example: - const response = openai.createChatCompletion({...}) - const message: NewMessageResponse = { - ...data, - message: response.data.choices[0].message.content - } - // Now emit event so the app can display in the conversation - events.emit(EventName.OnNewMessageResponse, message) -} -``` - -## EventName - -The `EventName` enum bundles the following events: - -- `OnNewConversation` -- `OnNewMessageRequest` -- `OnNewMessageResponse` -- `OnMessageResponseUpdate` -- `OnDownloadUpdate` -- `OnDownloadSuccess` -- `OnDownloadError` - -## event.on - -Adds an observer for an event. - -```js -const on: (eventName: string, handler: Function) => void = (eventName, handler); -``` - -## event.emit - -Emits an event. - -```js -const emit: (eventName: string, object: any) => void = (eventName, object); -``` - -## event.off - -Removes an observer for an event. - -```js -const off: (eventName: string, handler: Function) => void = - (eventName, handler); -``` diff --git a/docs/docs/reference/04_store.md b/docs/docs/reference/04_store.md deleted file mode 100644 index 5da2ee15a..000000000 --- a/docs/docs/reference/04_store.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: "store" ---- - -`store` is a helper object for working with Jan app's local storage database. - -By default, Jan ships with a [pouchDB](https://pouchdb.com/) client side noSQL db to persist usage state. - -_Note: default `store` logic is from [@data-plugin](https://www.npmjs.com/package/@janhq/data-plugin) which implements `StoreService`._ - -## Usage - -```js -import { store } from "@janhq/core"; -``` - -## Insert Data - -You can use the store.insertOne function to insert data into a specific collection in the local data store. - -```js -import { store } from "@janhq/core"; - -function insertData() { - store.insertOne("conversations", { name: "meow" }); - // Insert a new document with { name: "meow" } into the "conversations" collection. -} -``` - -## Get Data - -To retrieve data from a collection in the local data store, you can use the `store.findOne` or `store.findMany` function. It allows you to filter and retrieve documents based on specific criteria. - -store.getOne(collectionName, key) retrieves a single document that matches the provided key in the specified collection. -store.getMany(collectionName, selector, sort) retrieves multiple documents that match the provided selector in the specified collection. - -```js -import { store } from "@janhq/core"; - -function getData() { - const selector = { name: "meow" }; - const data = store.findMany("conversations", selector); - // Retrieve documents from the "conversations" collection that match the filter. -} -``` - -## Update Data - -You can update data in the local store using these functions: - -store.updateOne(collectionName, key, update) updates a single document that matches the provided key in the specified collection. -store.updateMany(collectionName, selector, update) updates multiple documents that match the provided selector in the specified collection. - -```js -function updateData() { - const selector = { name: "meow" }; - const update = { name: "newName" }; - store.updateOne("conversations", selector, update); - // Update a document in the "conversations" collection. -} -``` - -## Delete Data - -You can delete data from the local data store using these functions: - -store.deleteOne(collectionName, key) deletes a single document that matches the provided key in the specified collection. -store.deleteMany(collectionName, selector) deletes multiple documents that match the provided selector in the specified collection. - -```js -function deleteData() { - const selector = { name: "meow" }; - store.deleteOne("conversations", selector); - // Delete a document from the "conversations" collection. -} -``` diff --git a/docs/docs/reference/05_filesystem.md b/docs/docs/reference/05_filesystem.md deleted file mode 100644 index baa1fa30a..000000000 --- a/docs/docs/reference/05_filesystem.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: "filesystem" ---- - -The core package also provides functions to perform file operations. Here are a couple of examples: - -## Usage - -```js -// javascript -const core = require("@janhq/core"); - -// typescript -import * as core from "@janhq/core"; -``` - -## Download a File - -You can download a file from a specified URL and save it with a given file name using the core.downloadFile function. - -```js -function downloadModel(url: string, fileName: string) { - core.downloadFile(url, fileName); -} -``` - -## Delete a File - -To delete a file, you can use the core.deleteFile function, providing the path to the file you want to delete. - -```js -function deleteModel(filePath: string) { - core.deleteFile(path); -} -``` diff --git a/docs/docs/reference/06_preferences.md b/docs/docs/reference/06_preferences.md deleted file mode 100644 index 15e72e57d..000000000 --- a/docs/docs/reference/06_preferences.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "preferences" ---- - -`preferences` is a helper object for adding settings fields to your app. - -## Usage - -To register plugin preferences, you can use the preferences object from the @janhq/core package. Here's an example of how to register and retrieve plugin preferences: - -```js -import { PluginService, preferences } from "@janhq/core"; - -const pluginName = "your-first-plugin"; -const preferenceKey = ""; -const preferenceName = "Your First Preference"; -const preferenceDescription = "This is for example only"; -const defaultValue = ""; - -export function init({ register }: { register: RegisterExtensionPoint }) { - // Register preference update handlers. E.g. update plugin instance with new configuration - register(PluginService.OnPreferencesUpdate, pluginName, onPreferencesUpdate); - - // Register plugin preferences. E.g. Plugin need apiKey to connect to your service - preferences.registerPreferences < - string > - (register, - pluginName, - preferenceKey, - preferenceName, - preferenceDescription, - defaultValue); -} -``` - -In this example, we're registering preference update handlers and plugin preferences using the preferences object. We're also defining a PluginName constant to use as the name of the plugin. - -To retrieve the values of the registered preferences, we're using the get method of the preferences object and passing in the name of the plugin and the name of the preference. - -```js -import { preferences } from "@janhq/core"; - -const pluginName = "your-first-plugin"; -const preferenceKey = "apiKey"; - -const setup = async () => { - // Retrieve apiKey - const apiKey: string = - (await preferences.get(pluginName, preferenceKey)) ?? ""; -}; -``` - -## registerPreferences - -## get - -## set - -## clear diff --git a/docs/docs/tutorials/build-chat-app.md b/docs/docs/tutorials/build-chat-app.md deleted file mode 100644 index 5ab6eec6b..000000000 --- a/docs/docs/tutorials/build-chat-app.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -sidebar_position: 1 -title: Building a chat app ---- - -TODO diff --git a/docs/docs/tutorials/build-rag-app.md b/docs/docs/tutorials/build-rag-app.md deleted file mode 100644 index a5b54c5f2..000000000 --- a/docs/docs/tutorials/build-rag-app.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -sidebar_position: 2 -title: Building a RAG app ---- - -TODO diff --git a/docs/sidebars.js b/docs/sidebars.js index 627b51238..ea6a22a71 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -35,8 +35,7 @@ const sidebars = { type: "category", label: "Installation", collapsible: true, - collapsed: true, - link: { type: "doc", id: "guides/install/install" }, + collapsed: false, items: [ { type: "autogenerated", @@ -49,6 +48,7 @@ const sidebars = { docsSidebar: [ "docs/introduction", + "docs/quickstart", { type: "category", label: "Modules",