# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [x] Have you added type definitions?
# Description
This PR introduces the persona sorting feature.
**Changes:**
1. Uses the `sortable` library, consistent with other sorting
functionalities.
2. To prevent desynchronization between the selected persona and the UI
value during sorting:
* `OnStart`: Saves the currently selected persona.
* `OnEnd`: Switches selection to the first persona without saving the
initial selection.
I believe I've tested this sufficiently, but please feel free to point
out any potential issues or edge cases I might have missed.
Thank you for your time and review!
# PR Checklist
- ❌ Have you checked if it works normally in all models? *Ignore this if
it doesn't use models.*
- Not applicable
- ✅ Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- Done
- ❌ Have you added type definitions?
- Not applicable
# Description
In the previous commit, a new proxy endpoint was added to the backend to
resolve CORS errors that occurred when the frontend directly fetched
data from Risu Realm.
However, 403 errors were occurring because the POST requests sent from
the loadRisuAccountData() function in the frontend were not being
properly processed.
Additionally, the backend was inefficiently handling complex body
processing.
The updated backend code now provides a more efficient and stable
solution by directly piping the original request.
Furthermore, an issue where UserSettings.svelte couldn't handle tokens
received through the backend proxy after successfully logging into a
Risu account has also been fixed.
# PR Checklist
- [x] Have you added type definitions?
# Description
This PR aims to address the following issues:
* Fixed problems where prefixes and suffixes in the Lorebook prompt were
affecting keyword matching logic.
1. In full word matching, the first and last words of the body text
would consistently fail to match.
2. In general matching, using a persona name as a keyword would always
result in a match, regardless of context.
* I tried to preserve the original code structure as much as possible
while implementing these fixes. Please feel free to suggest changes to
the approach if you see a better way.
Thank you for your time and review.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [ ] Have you added type definitions?
# Description
In a previous commit, a new proxy endpoint was added to the backend to resolve CORS errors that occurred when the frontend directly fetched data from Risu Realm.
However, the proxy endpoint handler failed to properly process POST requests, causing account login failures. Additionally, the backend was inefficiently performing complex body processing.
The updated code now directly pipes the original request, providing a more efficient and reliable solution.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [ ] Have you added type definitions?
# Description
### Since this PR affects both editRequest mode and editDisplay mode, I
recommend reviewing #812 first for context.
This PR aims to:
1. Fix an issue where the current regex caching is incompatible with
modules.
2. Slightly modify the hashing structure to handle non-deterministic
regex with cbs. Verified that this correctly handles expressions like
`{{#if A}}`.
Thanks for your time.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [x] Have you added type definitions?
# Description
This PR addresses an issue where `luaFactory` fails to initialize
correctly in 'editDisplay' mode under specific conditions.
## Problem Reproduction:
The initialization failure can be reliably reproduced under the
following conditions:
1. Disable all modules.
2. Select any chatbot with 'editDisplay' in trigger lua.
3. Select or make chat with length of 2 or more.
4. Restart app and revisit the chatbot
## Changes:
1. Guaranteed `luaFactory` initialization completes successfully during
concurrent calls.
2. Added `Promise Map` to ensure only one Lua engine instance is created
per mode, preventing redundant initializations.
3. Moved variable updates within mutex scope to prevent potential issues
during concurrent operations.
4. Resolved merge conflicts with another PR. During the resolution:
* Removed logic related to caching or updating methods for Global Vars.
* **Reasoning:** Since Global Vars are stored directly in the database
and are not chat-specific, I believe caching/updating these methods to
be unnecessary, so I've simply made it calls exported one directly
without frequently re-cache itself.
* **Verification:** Re-validated that this change does not negatively
impact functionality.
* **Note:** Please let me know if anyone has concerns about this
approach to conflict resolution.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [ ] Have you added type definitions?
# Improved performance
The picture above was taken when I sent a chat.
As you can see, the encode function occupies **0.68 seconds** out of 1.8
seconds.
This is **36.5%** of sending time
This is a picture taken after adding a caching function.
encode time Reduced from **0.68 seconds to 0.12 seconds, an improvement
of 27.2%**
Since configuration values are also used as key values in the hash
function,
it is guaranteed that **different results will be produced when the
configuration changes**.
I tested this myself by changing the bot settings
# Implementation
I added the `mnemonist` library to implement this. At first, I used
lru-cache, but that library recommended using this one if performance is
important.
It actually performed better too.
# Integrity Check
Lastly,
the encoding result calculated without caching when sending the first
chat,
the newly calculated value when sending the second chat, and
the result cached when sending the first chat were all the same.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [ ] Have you added type definitions?
# Description
This PR introduces following:
- fix: check empty summarization result in HypaV3
- fix: handle similarity search error in HypaV3
# PR Checklist
- [❌] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- Not applicable
- [✅] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- Done
- [❌] Have you added type definitions?
- Not applicable
# Description
## Problem
The Node.js hosted version of RisuAI encountered an issue where it
failed to fetch data from the Risu Realm server when accessed remotely.
RisuAI's frontend directly fetches data from the Realm server (e.g.,
sv.risuai.xyz). While the official web version did not exhibit CORS
errors (potentially due to same-origin deployment or specific
server-side CORS configurations), running the Node.js version on a
self-hosted server and accessing it remotely resulted in browser CORS
policy violations.
## Solution
The fix involves detecting when the frontend runs in the Node.js host
environment.
When this environment is detected, instead of requesting Realm data
directly from the external server (sv.risuai.xyz), the frontend now
directs the request to a new proxy endpoint (`/hub-proxy/*`) on its own
backend server.
The backend proxy then fetches the required data (including JSON and
images) from the actual Realm server, correctly handles content types
and compression, and relays the response back to the frontend.
This ensures that, from the browser's perspective, the frontend is
communicating with its same-origin backend, effectively bypassing
browser CORS restrictions and resolving the data fetching issue.
# PR Checklist
- [ ] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- [ ] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- [ ] Have you added type definitions?
# Description
Add and enable temporary settings for NovelAI V4 models.
Character-specific prompt settings have been temporarily forcibly added,
so modifications are needed to allow custom prompt values to be input
later.
NovelAI V4 모델 추가.
캐릭터별 프롬프트는 임시추가 했기때문에 추후 커스텀 설정 할 수 있도록 변경해야함.
Problem:
The Node.js hosted version of RisuAI encountered an issue where it failed to fetch data from the Risu Realm server when accessed remotely.
RisuAI's frontend directly fetches data from the Realm server (e.g., sv.risuai.xyz). While the official web version did not exhibit CORS errors (potentially due to same-origin deployment or specific server-side CORS configurations), running the Node.js version on a self-hosted server and accessing it remotely resulted in browser CORS policy violations.
Solution:
The fix involves detecting when the frontend runs in the Node.js host environment.
When this environment is detected, instead of requesting Realm data directly from the external server (sv.risuai.xyz), the frontend now directs the request to a new proxy endpoint (`/hub-proxy/*`) on its own backend server.
The backend proxy then fetches the required data (including JSON and images) from the actual Realm server, correctly handles content types and compression, and relays the response back to the frontend.
This ensures that, from the browser's perspective, the frontend is communicating with its same-origin backend, effectively bypassing browser CORS restrictions and resolving the data fetching issue.
# PR Checklist
- [❌] Have you checked if it works normally in all models? *Ignore this
if it doesn't use models.*
- N/A
- [❌] Have you checked if it works normally in all web, local, and node
hosted versions? If it doesn't, have you blocked it in those versions?
- node hosted version only
- [❌] Have you added type definitions?
- N/A
# Description
The Node.js hosting version of RisuAI previously used simple app.listen
for server execution, which didn't support native HTTPS. This caused
several functionality issues due to browser security restrictions when
accessing RisuAI externally, such as realm loading failures and
inability to insert prompt presets.
The updated code now checks for certificate files named server.key and
server.crt in the /server/node/ssl/certificate directory. If found, the
server will start using HTTPS.
The /ssl directory includes a script to generate a self-signed SSL
certificate using OpenSSL. To use it, add the server's public IP to the
[ alt_names ] section in server.conf before generating the certificate.
The CA certificate should be installed on the operating system or
browser of devices remotely accessing RisuAI.
