-
Notifications
You must be signed in to change notification settings - Fork 20
Open webui dev #118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Open webui dev #118
Conversation
- Add Dia-TTS-Server submodule with package.json - Complete TypeScript integration layer - Docker container ready for deployment - Scripts for Super Protocol tunneling Ready for deployment in Super Protocol TEE
- TypeScript integration layer with HTTPS support - Docker container configuration - Super Protocol deployment scripts - Build configuration and dependencies - Working integration ready for deployment Note: dia-tts-server source will be added separately
- Python source files for TTS server - UI components and configuration - Requirements and documentation - Exclude heavy model files and cache (3GB+) Models will be downloaded during Docker build
- Keep only TypeScript source files (.ts) - Compiled .js files generated during build - Added build artifacts to .gitignore
- Delete all .js files from src/ directory - These are build artifacts and should not be in git - Keep only TypeScript source files (.ts) - Files will be generated during npm run build
- Remove local dia-tts-server directory copy - Add proper git submodule pointing to github.com/devnen/Dia-TTS-Server.git - Clean up old submodule references - This allows proper version tracking and easier updates
Dia tts solution - tunnel client integration
…-0001 to input-0002
…ility to load your own models
WalkthroughThis update introduces two new submodules, "Dia TTS Server" and "open_webui," each with their own Docker, TypeScript, and configuration setups. Both projects add environment templates, ignore files, build scripts, and TypeScript code for configuration, logging, and server orchestration. The root Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant TunnelClient
participant Server (Node.js)
participant PythonBackend
User->>TunnelClient: Start application
TunnelClient->>Server (Node.js): Initialize with config, logger, env
Server (Node.js)->>PythonBackend: Spawn backend (uvicorn / Open WebUI)
PythonBackend-->>Server (Node.js): Ready signal / process running
Server (Node.js)-->>TunnelClient: Service available
TunnelClient-->>User: Tunnel client operational
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 10
♻️ Duplicate comments (2)
Dia TTS Server/src/config.ts (2)
13-17: Remove unnecessary type casting for environment variables.Same issue as in the open_webui config - the type casting is redundant.
23-23: Improve error handling for numeric parsing.Same
Number.parseInt()issue as in the open_webui config - potential NaN runtime errors.
🧹 Nitpick comments (30)
.gitignore (2)
113-114: No objections to ignoringCLAUDE.md, but watch for file-name drift.If
CLAUDE.mdis intentionally generated or used only for local experimentation, ignoring it here is sensible.
However, if the filename ever changes (e.g.,claude.md,CLAUDE-notes.md) you’ll need to keep this rule in sync. Consider a pattern (CLAUDE*.md) if multiple variants are expected.
1-106: Duplicate.ideaentry – keep the list DRY.
.ideaappears twice (lines 3 and 105). While harmless, removing the duplicate keeps the ignore list concise and avoids future merge conflicts.-# IDE/Code edotors -.devcontainer -.idea +# IDE/Code editors / devcontainer +.devcontainerDia TTS Server/tsconfig.build.json (1)
2-4: Consider declaring an explicitincludelist for clarityWhile TypeScript will pick up all non-excluded files by default, adding an
includeclause makes intent crystal-clear (and prevents stray files in future from being compiled unintentionally)."extends": "./tsconfig.json", "exclude": ["node_modules", "dist", "**/*.test.ts"], + "include": ["src/**/*.ts"]Dia TTS Server/dia-tts-server (1)
1-1: Consider renaming the submodule path to avoid spacesHaving a space in the directory name (
Dia TTS Server/…) can break Docker build-args, shell scripts, CI steps, and any tooling that forgets to quote paths. It’s safer to use kebab-case or snake_case (e.g.dia-tts-server/) to minimise cross-platform pitfalls.Please verify:
- All references in Dockerfiles,
docker-compose, TypeScriptimports, and CI scripts correctly quote this path..gitmodulescontains the exact same path (spaces included); mismatches will breakgit submodule update.open_webui/tsconfig.build.json (1)
2-3: Consider tightening the build-only config.
tsconfig.build.jsonis meant for production compilation. Omitting an"include"(or an explicit"files") section means every.tsfile not underexcludeis compiled, which can pull in benches, scripts, etc. that you probably don’t want indist.{ "extends": "./tsconfig.json", + "include": ["src/**/*.ts"], "exclude": ["node_modules", "dist", "**/*.test.ts"] }Keeps the build scope predictable and shortens compile time.
Dia TTS Server/.env.example (1)
1-4: Replace concrete values with placeholders in example files.Example
.envfiles should guide users without hard-coding project-specific values. Using a real RPC URL and contract address invites accidental misuse in other environments.-LOG_LEVEL=trace -BLOCKCHAIN_URL=http://127.0.0.1:8545 -BLOCKCHAIN_CONTRACT_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 +LOG_LEVEL=trace +# e.g. http://127.0.0.1:8545 +BLOCKCHAIN_URL=<BLOCKCHAIN_RPC_URL> +# e.g. 0x0000000000000000000000000000000000000000 +BLOCKCHAIN_CONTRACT_ADDRESS=<CONTRACT_ADDRESS>Helps prevent misconfiguration and clarifies intent.
open_webui/.env.example (1)
1-3: Align ordering & add trailing newline for lint clean-ness.
dotenv-linterwarnings are harmless but easy to silence:-BLOCKCHAIN_URL=http://127.0.0.1:8545 -BLOCKCHAIN_CONTRACT_ADDRESS=0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0 +BLOCKCHAIN_CONTRACT_ADDRESS=<CONTRACT_ADDRESS> +BLOCKCHAIN_URL=http://127.0.0.1:8545 +(Not critical, purely cosmetic.)
Dia TTS Server/src/logger.ts (1)
4-9: Expose both root and app-scoped loggers for flexibility.
pino(pinoConfig).child({ … })already yields a child logger, yet the symbol is namedrootLogger. If other modules later callpino()directly, log meta will diverge.-const pinoConfig = { level: config.logLevel }; - -export const rootLogger = pino(pinoConfig).child({ - app: config.appName, - version: config.appVersion, -}); +const pinoConfig = { level: config.logLevel }; + +export const baseLogger = pino(pinoConfig); +export const appLogger = baseLogger.child({ + app: config.appName, + version: config.appVersion, +});Retains a true root while still providing enriched logs.
Dia TTS Server/.dockerignore (1)
1-3: Double-checkdistexclusion vs. multi-stage build.The Dockerfile appears to compile TS inside the container, so ignoring
distis fine. If you ever switch to “compile locally then copy”, this rule will silently break the image. Pin a comment for future maintainers?-dist +# dist – generated in the build stage inside the image +distTiny doc helps avoid head-scratching later.
Dia TTS Server/src/env-utils.ts (1)
1-7: LGTM with a minor consideration for edge cases.The function logic is correct and follows best practices for environment variable validation. The error message is clear and descriptive.
Consider whether empty strings should be treated as valid values for some use cases:
- if (!value) { + if (!value || value.trim() === '') {This change would reject empty strings and whitespace-only values, which might be more appropriate for most environment variables.
open_webui/src/env-utils.ts (1)
1-7: LGTM! Note potential code duplication.The function implementation is correct and follows the same pattern as
Dia TTS Server/src/env-utils.ts.Consider extracting this common utility to a shared library in future iterations to avoid code duplication between projects, especially if both projects are maintained together.
open_webui/.gitignore (1)
1-14: Clean up duplicate entries in .gitignore.The ignore patterns are appropriate for excluding certificates, build artifacts, dependencies, and user data. However, there are duplicate entries that should be removed:
certs/* tunnel-client-certs/* # TypeScript build artifacts src/*.js src/*.js.map dist/ node_modules/ # Open WebUI data directory (contains user data, databases, uploads) open-webui-data/ - -# Build artifacts -dist/ -node_modules/The patterns correctly exclude sensitive and generated files from version control.
Dia TTS Server/.gitignore (1)
24-28: Ignore patterns only cover root-level JS artifacts
src/*.jsandsrc/*.js.mapskip JavaScript emitted inside nested folders (src/utils/foo.js, etc.). TypeScript’s compiler often mirrors the source tree, so these files may leak into the repo.- src/*.js - src/*.js.map + src/**/*.js + src/**/*.js.mapThe same applies to
dist/; keeping it already covers compiled code, but tightening thesrc/**pattern prevents accidental commits during localts-nodetranspilation.Dia TTS Server/docker-compose.yml (1)
3-17: Harden the service definition (restart policy, non-root user, env-file)Current compose spec works but misses a few production-grade defaults:
- Add
restart: unless-stopped(oron-failure) to auto-recover the container.- Run the service as a non-root UID/GID to reduce blast radius (
user: "1000:1000").- Instead of inlining model vars, reference an
.envorenv_fileto keep compose clean and avoid accidental commit of secrets.Example patch:
dia-tts-server: @@ volumes: - ./dia-tts-server/model_cache:/sp/inputs/input-0001 + restart: unless-stopped + user: "1000:1000" - environment: - - DIA_MODEL_REPO_ID=ttj/dia-1.6b-safetensors - - DIA_MODEL_CONFIG_FILENAME=config.json - - DIA_MODEL_WEIGHTS_FILENAME=dia-v0_1_bf16.safetensors + env_file: + - .envopen_webui/tsconfig.json (1)
1-20: Consider enabling faster incremental builds and explicit module resolution
tsccan feel sluggish in multi-service monorepos. Two small compiler-option tweaks improve DX without changing output:{ "compilerOptions": { + "incremental": true, + "tsBuildInfoFile": "./dist/.tsbuildinfo", + "moduleResolution": "node", ... } }
incrementalstores build info in.tsbuildinfofor ≈ 3-5× faster subsequent compiles, and explicit"moduleResolution": "node"removes ambiguity when Node upgrades the default.Dia TTS Server/package.json (1)
16-22: Pin exact dependency versions to avoid unexpected breakagesUsing caret (
^) ranges for core Super Protocol libs means any future minor/major release can silently introduce breaking changes. In production-grade images, prefer exact versions (or at least tilde ranges) and update intentionally.- "@super-protocol/sdk-js": "^3.11.5", + "@super-protocol/sdk-js": "3.11.5",(Apply to all deps listed here.)
Dia TTS Server/src/server-config.ts (1)
11-17: Resolve paths from project root and pass radix explicitly
path.join(__dirname, …)will resolve relative to the compileddistdirectory at runtime, not the project root. That may break certificate discovery when the code is transpiled.
Also,parseIntwithout a radix is discouraged.- privateKeyFilePath: path.join(__dirname, config.certPrivateKeyFileName), - certificateFilePath: path.join(__dirname, config.certFileName), - port: Number.parseInt(getEnvValueOrFail('HTTPS_PORT')), + privateKeyFilePath: path.resolve(__dirname, '..', config.certPrivateKeyFileName), + certificateFilePath: path.resolve(__dirname, '..', config.certFileName), + port: Number.parseInt(getEnvValueOrFail('HTTPS_PORT'), 10),open_webui/docker-compose.yml (1)
25-26: Add a trailing newline and quote multiline secretsYAML-lint flags the missing EOF newline. Also, raw
TLS_KEY/TLS_CERTlines containing literal line-breaks require quoting; using dummy placeholders now is fine, but quote them to avoid parse surprises.- - TLS_KEY=dummy_key - - TLS_CERT=dummy_cert + - TLS_KEY="dummy_key" + - TLS_CERT="dummy_cert" +open_webui/package.json (1)
16-22: Lock dependency versions to deterministic buildsReplicate the pinning advice given for the Dia-TTS package to keep Open WebUI images reproducible.
open_webui/src/server-config.ts (1)
11-17: Same path & radix concerns as Dia-TTSConsider the analogous fix to ensure certificates resolve correctly after transpilation and avoid implicit-radix
parseInt.open_webui/src/index.ts (1)
17-41: Verify tunnel client configuration and error handling.The tunnel client initialization logic looks correct, but consider adding validation for the configuration parameters before creating the TunnelClient instance.
Consider adding configuration validation:
+ if (!tunnelsConfiguration) { + throw new Error('Tunnels configuration is required'); + } + + if (!domainConfigs.length) { + throw new Error('No domain configurations found'); + } const options: TunnelClientOptions = { logger: rootLogger, applicationPort: config.clientServerPort, localServerStartTimeout: config.localServerStartTimeoutMs, };open_webui/src/server.ts (2)
1-10: Remove unused import and unclear comment.The
parentPortimport is unused, and the comment about unchanged code is unclear and potentially misleading.- import { parentPort } from 'worker_threads'; - // ... (код terminationHandler и parentPort остается без изменений) ...
20-35: Consider improving Ollama startup reliability.The hardcoded 3-second delay and detached mode may not be the most reliable approach for process management.
Consider implementing a more robust health check instead of a hardcoded delay:
- // Даем Ollama пару секунд на запуск - await new Promise(resolve => setTimeout(resolve, 3000)); + // Wait for Ollama to be ready + const waitForOllama = async (maxRetries = 10) => { + for (let i = 0; i < maxRetries; i++) { + try { + const response = await fetch('http://localhost:11434/api/version'); + if (response.ok) return; + } catch (error) { + // Ollama not ready yet + } + await new Promise(resolve => setTimeout(resolve, 1000)); + } + throw new Error('Ollama failed to start within timeout'); + }; + await waitForOllama();Dia TTS Server/src/server.ts (1)
33-47: Verify hardcoded model cache path.The hardcoded
DIA_MODEL_CACHE_PATHmay not be flexible for different deployment environments.Consider making the model cache path configurable:
env: { ...process.env, - DIA_MODEL_CACHE_PATH: '/sp/inputs/input-0001' + DIA_MODEL_CACHE_PATH: process.env.DIA_MODEL_CACHE_PATH || '/sp/inputs/input-0001' },Dia TTS Server/Dockerfile (1)
20-24: Consider security implications of curl piping to bash.While functional, piping curl output directly to bash poses security risks. Consider using package managers when possible.
For better security, consider using a multi-step approach:
- RUN apt-get update && apt-get install -y curl \ - && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \ - && apt-get install -y nodejs git git-lfs build-essential libgl1-mesa-glx libsndfile1 ffmpeg \ - && apt-get clean && rm -rf /var/lib/apt/lists/* + RUN apt-get update && apt-get install -y curl gnupg \ + && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /usr/share/keyrings/nodesource.gpg \ + && echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main" > /etc/apt/sources.list.d/nodesource.list \ + && apt-get update && apt-get install -y nodejs git git-lfs build-essential libgl1-mesa-glx libsndfile1 ffmpeg \ + && apt-get clean && rm -rf /var/lib/apt/lists/*open_webui/Dockerfile (1)
28-32: Security concern with curl piping to bash.Similar to the Dia TTS Server Dockerfile, piping curl output directly to bash poses security risks.
Consider using a more secure Node.js installation approach:
- RUN apt-get update && apt-get install -y curl \ - && curl -fsSL https://deb.nodesource.com/setup_20.x | bash - \ - && apt-get install -y nodejs git build-essential \ - && apt-get clean && rm -rf /var/lib/apt/lists/* + RUN apt-get update && apt-get install -y curl gnupg \ + && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /usr/share/keyrings/nodesource.gpg \ + && echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_20.x nodistro main" > /etc/apt/sources.list.d/nodesource.list \ + && apt-get update && apt-get install -y nodejs git build-essential \ + && apt-get clean && rm -rf /var/lib/apt/lists/*open_webui/src/config.ts (3)
13-13: Remove unnecessary type casting.The type casting
(process.env.LOG_LEVEL as string)is redundant sinceprocess.envvalues are alreadystring | undefined.- logLevel: (process.env.LOG_LEVEL as string) || 'trace', + logLevel: process.env.LOG_LEVEL || 'trace',
14-17: Remove unnecessary type casting for environment variables.The type casting
(process.env.* as string)is redundant sinceprocess.envvalues are alreadystring | undefined.- inputDataFolder: (process.env.INPUT_DATA_FOLDER as string) || '/sp/inputs', - secretsDataFolder: (process.env.SECRETS_DATA_FOLDER as string) || '/sp/secrets', - certFileName: (process.env.CERT_FILE_NAME as string) || 'certificate.crt', - certPrivateKeyFileName: (process.env.CERT_PRIVATE_KEY_FILE_NAME as string) || 'private.pem', + inputDataFolder: process.env.INPUT_DATA_FOLDER || '/sp/inputs', + secretsDataFolder: process.env.SECRETS_DATA_FOLDER || '/sp/secrets', + certFileName: process.env.CERT_FILE_NAME || 'certificate.crt', + certPrivateKeyFileName: process.env.CERT_PRIVATE_KEY_FILE_NAME || 'private.pem',
19-19: Remove unnecessary type annotation.The type annotation
as numberis redundant since1is already inferred as a number literal.- configSearchFolderDepth: 1 as number, + configSearchFolderDepth: 1,Dia TTS Server/src/index.ts (1)
29-32: Potential information leakage in debug logs.The debug log exposes domain configurations which might contain sensitive information. Consider whether this level of detail should be logged in production environments.
- logger.debug( - { domains: domainConfigs.map((config) => config.site.domain) }, - 'Found tunnel client domain configs', - ); + logger.debug( + { domainCount: domainConfigs.length }, + 'Found tunnel client domain configs', + );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
Dia TTS Server/package-lock.jsonis excluded by!**/package-lock.jsonopen_webui/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (34)
.gitignore(1 hunks).gitmodules(1 hunks)Dia TTS Server/.dockerignore(1 hunks)Dia TTS Server/.env.example(1 hunks)Dia TTS Server/.gitignore(1 hunks)Dia TTS Server/Dockerfile(1 hunks)Dia TTS Server/dia-tts-server(1 hunks)Dia TTS Server/docker-compose.yml(1 hunks)Dia TTS Server/package.json(1 hunks)Dia TTS Server/src/config.ts(1 hunks)Dia TTS Server/src/env-utils.ts(1 hunks)Dia TTS Server/src/index.ts(1 hunks)Dia TTS Server/src/logger.ts(1 hunks)Dia TTS Server/src/server-config.ts(1 hunks)Dia TTS Server/src/server.ts(1 hunks)Dia TTS Server/src/types.ts(1 hunks)Dia TTS Server/tsconfig.build.json(1 hunks)Dia TTS Server/tsconfig.json(1 hunks)open_webui/.env.example(1 hunks)open_webui/.gitignore(1 hunks)open_webui/Dockerfile(1 hunks)open_webui/docker-compose.yml(1 hunks)open_webui/open-webui(1 hunks)open_webui/package.json(1 hunks)open_webui/src/config.ts(1 hunks)open_webui/src/env-utils.ts(1 hunks)open_webui/src/index.ts(1 hunks)open_webui/src/logger.ts(1 hunks)open_webui/src/server-config.ts(1 hunks)open_webui/src/server.ts(1 hunks)open_webui/src/types.ts(1 hunks)open_webui/tsconfig.build.json(1 hunks)open_webui/tsconfig.json(1 hunks)readme.md(0 hunks)
💤 Files with no reviewable changes (1)
- readme.md
🧰 Additional context used
🧠 Learnings (2)
open_webui/open-webui (2)
undefined
<retrieved_learning>
Learnt from: tinovyatkin
PR: #101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
</retrieved_learning>
<retrieved_learning>
Learnt from: tinovyatkin
PR: #101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
</retrieved_learning>
.gitmodules (4)
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:44:51.328Z
Learning: ComfyUI Manager repository has moved from jiangyangfan/ComfyUI-Manager to Comfy-Org/ComfyUI-Manager, and the comfy CLI handles this change transparently when using the --manager-commit parameter.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:49:17.947Z
Learning: ComfyUI uses versioned tags with "v" prefix (like v0.3.29) in its GitHub repository at comfyanonymous/ComfyUI.
Learnt from: tinovyatkin
PR: Super-Protocol/solutions#101
File: ComfyUI/Dockerfile.local-cpu:29-30
Timestamp: 2025-04-24T09:49:17.947Z
Learning: ComfyUI Manager uses versioned tags without "v" prefix (like 3.31.12) in its GitHub repository at Comfy-Org/ComfyUI-Manager.
🧬 Code Graph Analysis (7)
Dia TTS Server/src/logger.ts (1)
Dia TTS Server/src/config.ts (1)
config(8-24)
open_webui/src/logger.ts (1)
open_webui/src/config.ts (1)
config(8-24)
open_webui/src/server-config.ts (3)
open_webui/src/types.ts (1)
IServerConfig(1-8)open_webui/src/config.ts (1)
config(8-24)open_webui/src/env-utils.ts (1)
getEnvValueOrFail(1-7)
open_webui/src/server.ts (3)
Petals/src/server-config.ts (1)
serverConfig(4-13)open_webui/src/server-config.ts (1)
getServerConfig(8-21)open_webui/src/logger.ts (1)
rootLogger(6-9)
Dia TTS Server/src/server.ts (2)
Dia TTS Server/src/logger.ts (1)
rootLogger(6-9)Dia TTS Server/src/server-config.ts (1)
getServerConfig(8-21)
Dia TTS Server/src/config.ts (1)
Dia TTS Server/src/env-utils.ts (1)
getEnvValueOrFail(1-7)
open_webui/src/config.ts (1)
open_webui/src/env-utils.ts (1)
getEnvValueOrFail(1-7)
🪛 dotenv-linter (3.3.0)
Dia TTS Server/.env.example
[warning] 2-2: [UnorderedKey] The BLOCKCHAIN_URL key should go before the LOG_LEVEL key
[warning] 3-3: [UnorderedKey] The BLOCKCHAIN_CONTRACT_ADDRESS key should go before the BLOCKCHAIN_URL key
open_webui/.env.example
[warning] 2-2: [UnorderedKey] The BLOCKCHAIN_URL key should go before the LOG_LEVEL key
[warning] 3-3: [EndingBlankLine] No blank line at the end of the file
[warning] 3-3: [UnorderedKey] The BLOCKCHAIN_CONTRACT_ADDRESS key should go before the BLOCKCHAIN_URL key
🪛 YAMLlint (1.37.1)
open_webui/docker-compose.yml
[error] 26-26: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (28)
Dia TTS Server/tsconfig.build.json (1)
1-4: Build-onlytsconfig.build.jsonlooks goodThe file cleanly extends the base config and excludes typical non-build artifacts (
node_modules,dist, tests). 👍open_webui/src/logger.ts (1)
1-9: LGTM! Clean logging setup with proper configuration.The logging implementation follows best practices:
- Uses pino for structured logging
- Externalizes configuration to a config module
- Creates a child logger with useful context (app name and version)
- Clean and focused implementation
The setup provides a solid foundation for logging throughout the application.
Dia TTS Server/tsconfig.json (1)
1-20: LGTM! Comprehensive TypeScript configuration.The TypeScript configuration is well-structured and follows best practices:
- ES2018 target is appropriate for Node.js applications
- Strict mode enabled for better type safety
- Proper source and output directory structure
- Declaration files and source maps enabled for development
- Correct include/exclude patterns
The configuration provides a solid foundation for TypeScript development.
open_webui/docker-compose.yml (1)
3-13: Container is not exposed to the host; verify that this is intentionalThe
open-webuiservice listens onHTTPS_PORT=9000but noports:mapping exists. If you intend local browsing/testing, add:ports: - "9000:9000"Otherwise confirm that the tunnel client alone will handle ingress.
open_webui/src/index.ts (3)
1-11: Good import organization and module structure.The imports are well-organized with clear separation between external dependencies and local modules.
13-15: Proper error handling setup.The global error handlers are correctly set up to ensure graceful shutdown on unhandled rejections, exceptions, and signals.
43-46: Proper error handling for main function execution.The error handling correctly logs fatal errors and exits with appropriate exit code.
open_webui/src/server.ts (3)
11-18: Good security practices for TLS certificate handling.The TLS certificates are correctly written with secure permissions (0o600) to prevent unauthorized access.
37-51: Proper uvicorn configuration for HTTPS.The uvicorn configuration is correct with proper SSL certificates, host binding, and working directory setup.
53-56: Good error handling for startup failures.The error handling properly logs fatal errors for debugging purposes.
Dia TTS Server/src/server.ts (4)
1-6: Clean and necessary imports.All imports are being used and appropriately organized.
7-19: Proper process lifecycle management.The termination handler and signal handling setup provides good process management for graceful shutdown.
21-31: Secure TLS certificate handling.The TLS certificates are written with appropriate secure permissions (0o600) consistent with security best practices.
49-51: Appropriate error handling for startup failures.The error handling correctly logs fatal errors for debugging server startup issues.
Dia TTS Server/Dockerfile (5)
1-8: Standard Node.js build stage implementation.The build stage follows Docker best practices with proper dependency installation and production build.
10-18: Appropriate environment configuration for PyTorch runtime.The environment variables are properly set for non-interactive installs and Python buffering, which is good for containerized environments.
26-32: Proper artifact copying from builder stage.The copying of built artifacts and dependencies follows Docker multi-stage build best practices.
34-37: Efficient PyTorch installation with CUDA support.The PyTorch installation with CUDA-specific wheels and requirements installation is properly configured.
39-42: Appropriate directory structure and entrypoint.The directory creation and Node.js entrypoint are correctly configured for the application requirements.
open_webui/Dockerfile (6)
1-8: Standard Node.js wrapper build stage.The build stage follows Docker best practices with proper dependency management and production builds.
10-16: Efficient frontend build stage.The frontend build stage is well-structured with proper dependency installation and build process.
18-26: Appropriate Python base image and environment setup.The Python slim base image and environment variables are properly configured for the application requirements.
34-40: Proper Node.js application integration.The copying of built Node.js artifacts and dependencies is correctly implemented.
42-52: Good integration of Open WebUI components.The backend copying, Python dependency installation, frontend integration, and Python path setup are well-coordinated.
57-67: Proper directory structure and environment configuration.The directory creation and Open WebUI environment variables are appropriately configured for the application requirements.
Dia TTS Server/src/index.ts (3)
13-15: Good error handling setup.The global error handlers for unhandled rejections, uncaught exceptions, and termination signals are properly configured with logging. This ensures graceful shutdown and proper error visibility.
43-46: Proper error handling in main execution.The catch block appropriately logs fatal errors and exits with a non-zero code, which is good practice for containerized applications.
22-27: Ensure robust error handling aroundgetDomainConfigs
The call togetDomainConfigs(imported from@super-protocol/solution-utils) may throw on network or blockchain failures. Since its implementation lives outside this repo, please verify that either:
getDomainConfigsinternally catches and wraps connectivity errors with clear messages, or- you wrap this call in a
try…catch(or use.catch()) here to handle timeouts, bad contract responses, and log/recover appropriately.• File: Dia TTS Server/src/index.ts, lines 22–27
• Similar calls exist in other services—apply consistent handling.
| [submodule "Dia TTS Server/dia-tts-server"] | ||
| path = Dia TTS Server/dia-tts-server | ||
| url = https://github.com/devnen/Dia-TTS-Server.git | ||
| [submodule "open_webui/open-webui"] | ||
| path = open_webui/open-webui | ||
| url = https://github.com/open-webui/open-webui.git |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
🧩 Analysis chain
Submodule paths with spaces are brittle – rename or quote consistently.
Dia TTS Server/dia-tts-server contains spaces, which can break tooling (CI scripts, Docker COPY, Makefiles) unless every reference is properly quoted. Consider switching to a hyphenated path, or—at minimum—verify all scripts handle it correctly.
-[submodule "Dia TTS Server/dia-tts-server"]
- path = Dia TTS Server/dia-tts-server
+[# example – pick a consistent, no-space alias]
+[submodule "Dia-TTS-Server"]
+ path = Dia-TTS-ServerWould you confirm whether any existing scripts already assume a no-space path? If so, renaming now will prevent silent breakage later.
🏁 Script executed:
#!/bin/bash
# Search for any references to the submodule path with and without spaces
rg -n "Dia TTS Server"
rg -n "dia-tts-server"
rg -n "Dia-TTS-Server"Length of output: 1003
Rename submodule directory to a hyphenated path (no spaces)
We found several unquoted references that will break if the on-disk path contains spaces:
• Dockerfile (Dia TTS Server/Dockerfile):
COPY dia-tts-server ./dia-tts-server
• docker-compose.yml (Dia TTS Server/docker-compose.yml):
volumes:
- ./dia-tts-server/model_cache:/sp/inputs/input-0001
• server-config.ts (Dia TTS Server/src/server-config.ts):
diaServerPath: path.join(__dirname, '../dia-tts-server')
Please update your .gitmodules entry and corresponding directory name:
-[submodule "Dia TTS Server/dia-tts-server"]
- path = Dia TTS Server/dia-tts-server
+[submodule "Dia-TTS-Server"]
+ path = Dia-TTS-Server
url = https://github.com/devnen/Dia-TTS-Server.gitThen rename the folder on disk (and in any CI/Makefiles) to Dia-TTS-Server or flatten to dia-tts-server, and adjust all relative paths accordingly.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| [submodule "Dia TTS Server/dia-tts-server"] | |
| path = Dia TTS Server/dia-tts-server | |
| url = https://github.com/devnen/Dia-TTS-Server.git | |
| [submodule "open_webui/open-webui"] | |
| path = open_webui/open-webui | |
| url = https://github.com/open-webui/open-webui.git | |
| [submodule "Dia-TTS-Server"] | |
| path = Dia-TTS-Server | |
| url = https://github.com/devnen/Dia-TTS-Server.git | |
| [submodule "open_webui/open-webui"] | |
| path = open_webui/open-webui | |
| url = https://github.com/open-webui/open-webui.git |
🤖 Prompt for AI Agents
In the .gitmodules file around lines 9 to 14, the submodule directory "Dia TTS
Server/dia-tts-server" contains spaces which cause issues in unquoted path
references. Rename the submodule directory path to use hyphens instead of
spaces, such as "Dia-TTS-Server/dia-tts-server" or
"dia-tts-server/dia-tts-server". Update the .gitmodules file accordingly and
rename the actual folder on disk to match. Also, adjust all related references
in Dockerfile, docker-compose.yml, server-config.ts, CI scripts, and Makefiles
to use the new hyphenated path.
| @@ -0,0 +1 @@ | |||
| Subproject commit 2470da833679f61619f2275862185259fe7f5168 | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
🧩 Analysis chain
Pinning to an un-tagged SHA complicates provenance & future upgrades
The submodule is locked to a bare commit hash. Unless you have strong reasons, prefer referencing a signed tag or release to improve traceability and make git submodule update --remote upgrades easier. At minimum, document the upstream repo/commit in CHANGELOG and ensure CI fetches submodules.
🏁 Script executed:
#!/bin/bash
# Verify the exact commit exists upstream and that CI can fetch it quickly.
git submodule update --init --depth 1 open_webui/open-webuiLength of output: 402
🏁 Script executed:
#!/bin/bash
# Check if the pinned commit corresponds to any tag in upstream repo
git ls-remote --tags https://github.com/open-webui/open-webui.git | grep 2470da833679f61619f2275862185259fe7f5168 || echo "no matching tag"Length of output: 156
Use a tagged release for the open-webui submodule
The commit 2470da833679f61619f2275862185259fe7f5168 isn’t referenced by any upstream tag, so pinning to this SHA makes provenance and future updates harder. Please either:
- Update the submodule to point at the latest signed tag or release in open-webui/open-webui.git
- If no suitable tag exists, create one upstream and retarget this submodule to it
- At minimum, document the upstream repo URL and exact commit in your CHANGELOG
- Ensure your CI config initializes and updates submodules (e.g.
git submodule update --init --recursive)
🤖 Prompt for AI Agents
In open_webui/open-webui at line 1, the submodule is pinned to a specific commit
SHA without referencing a tagged release, which complicates provenance and
updates. Fix this by updating the submodule to point to the latest signed tag or
release in the upstream repository. If no suitable tag exists, create one
upstream and retarget the submodule to that tag. Additionally, document the
upstream repository URL and exact commit in the CHANGELOG, and verify that the
CI configuration properly initializes and updates submodules using commands like
'git submodule update --init --recursive'.
| export interface IServerConfig { | ||
| privateKeyFilePath: string; | ||
| certificateFilePath: string; | ||
| port: number; | ||
| tlsKey: string; | ||
| tlsCert: string; | ||
| openWebUIPath: string; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Unify duplicated server-config interfaces and mark immutables as readonly
The exact same IServerConfig shape appears in both the Open WebUI and Dia-TTS projects with only a single path-property difference.
Duplicating it risks the two copies drifting out of sync. Consider moving this interface to a small shared @sp/server-config package (or a common/ folder) and extending it where the path diverges:
export interface IBaseServerConfig {
readonly privateKeyFilePath: string;
readonly certificateFilePath: string;
readonly port: number;
readonly tlsKey: string;
readonly tlsCert: string;
}
export interface IOpenWebUIServerConfig extends IBaseServerConfig {
readonly openWebUIPath: string;
}Marking the fields readonly documents that the object is effectively immutable after construction and enables a few extra compiler checks.
🤖 Prompt for AI Agents
In open_webui/src/types.ts lines 1 to 8, the IServerConfig interface duplicates
a similar interface in another project and lacks readonly modifiers. To fix
this, extract the common properties into a new IBaseServerConfig interface with
all fields marked readonly, then extend it in IOpenWebUIServerConfig to add the
openWebUIPath property also marked readonly. Consider moving IBaseServerConfig
to a shared package or common folder to avoid duplication and keep interfaces in
sync.
| export interface IServerConfig { | ||
| privateKeyFilePath: string; | ||
| certificateFilePath: string; | ||
| port: number; | ||
| tlsKey: string; | ||
| tlsCert: string; | ||
| diaServerPath: string; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
DRY violation – extract common IServerConfig instead of copy-pasting
This interface is byte-for-byte identical to the one in open_webui/src/types.ts, bar the path field. Duplicate definitions will inevitably diverge, leading to subtle runtime bugs when a new property is added to one service but not the other.
Refactor to import a shared base interface (see suggestion in the previous comment) and extend it with the project-specific diaServerPath.
🤖 Prompt for AI Agents
In Dia TTS Server/src/types.ts lines 1 to 8, the IServerConfig interface
duplicates the one in open_webui/src/types.ts except for the diaServerPath
field. To fix this, create a shared base interface in a common module and import
it here. Then extend that base interface with the diaServerPath property instead
of redefining all fields, ensuring consistency and avoiding duplication.
| "scripts": { | ||
| "build": "tsc -p tsconfig.build.json" | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add a production-ready start script
Only a build script is declared. Without a start script, npm start or common Docker CMDs will fail at runtime.
"scripts": {
"build": "tsc -p tsconfig.build.json",
+ "start": "node dist/index.js"
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "scripts": { | |
| "build": "tsc -p tsconfig.build.json" | |
| }, | |
| "scripts": { | |
| "build": "tsc -p tsconfig.build.json", | |
| "start": "node dist/index.js" | |
| }, |
🤖 Prompt for AI Agents
In Dia TTS Server/package.json around lines 6 to 8, add a production-ready
"start" script to the "scripts" section. This script should run the compiled
output of the TypeScript build, typically using "node" to execute the main
JavaScript file generated by the build process. This ensures that running "npm
start" or Docker CMD commands will correctly start the application in
production.
| "scripts": { | ||
| "build": "tsc -p tsconfig.build.json" | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Add a start script for runtime execution
Same reasoning as in Dia-TTS package.
"scripts": {
"build": "tsc -p tsconfig.build.json",
+ "start": "node dist/index.js"
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "scripts": { | |
| "build": "tsc -p tsconfig.build.json" | |
| }, | |
| "scripts": { | |
| "build": "tsc -p tsconfig.build.json", | |
| "start": "node dist/index.js" | |
| }, |
🤖 Prompt for AI Agents
In open_webui/package.json around lines 6 to 8, the scripts section lacks a
"start" script for runtime execution. Add a "start" script that runs the built
application, typically using a command like "node dist/index.js" or the
appropriate entry point file, to enable easy startup of the app after building.
| # Install Ollama | ||
| RUN curl -fsSL https://ollama.com/install.sh | sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Security risk with Ollama installation.
Piping curl output to shell presents a security vulnerability. Consider alternative installation methods.
For better security, consider using a more secure installation approach:
- # Install Ollama
- RUN curl -fsSL https://ollama.com/install.sh | sh
+ # Install Ollama with verification
+ RUN curl -fsSL https://ollama.com/install.sh -o /tmp/install-ollama.sh \
+ && chmod +x /tmp/install-ollama.sh \
+ && /tmp/install-ollama.sh \
+ && rm /tmp/install-ollama.sh📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Install Ollama | |
| RUN curl -fsSL https://ollama.com/install.sh | sh | |
| # Install Ollama with verification | |
| RUN curl -fsSL https://ollama.com/install.sh -o /tmp/install-ollama.sh \ | |
| && chmod +x /tmp/install-ollama.sh \ | |
| && /tmp/install-ollama.sh \ | |
| && rm /tmp/install-ollama.sh |
🤖 Prompt for AI Agents
In open_webui/Dockerfile at lines 54 to 55, the current installation of Ollama
uses curl piped directly to sh, which is a security risk. To fix this, download
the install script first, verify its integrity (e.g., checksum or signature),
then execute it separately. Alternatively, use a trusted package manager or
official installation method that does not involve piping unverified scripts
directly to the shell.
| clientServerPort: 9000, | ||
| serverFilePath: path.join(__dirname, './server.js'), | ||
| configurationPath: process.env.CONFIGURATION_PATH || '/sp/configurations/configuration.json', | ||
| localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Improve error handling for numeric parsing.
Number.parseInt() can return NaN if the environment variable contains invalid numeric data, which could cause runtime issues. Consider adding validation or using a more robust parsing approach.
- localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min
+ localServerStartTimeoutMs: (() => {
+ const value = Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000');
+ return Number.isNaN(value) ? 900000 : value;
+ })(),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min | |
| localServerStartTimeoutMs: (() => { | |
| const value = Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'); | |
| return Number.isNaN(value) ? 900000 : value; | |
| })(), |
🤖 Prompt for AI Agents
In open_webui/src/config.ts at line 23, the use of Number.parseInt on the
environment variable may result in NaN if the value is invalid. To fix this, add
validation after parsing to check if the result is NaN, and if so, fallback to a
default value or throw a clear error. This ensures the configuration always has
a valid numeric timeout value.
| import dotenv from 'dotenv'; | ||
| import path from 'path'; | ||
| import packageJson from '../package.json'; | ||
| import { getEnvValueOrFail } from './env-utils'; | ||
|
|
||
| dotenv.config(); | ||
|
|
||
| export const config = { | ||
| appName: packageJson.name, | ||
| appVersion: packageJson.version, | ||
| blockchainUrl: getEnvValueOrFail('BLOCKCHAIN_URL'), | ||
| blockchainContractAddress: getEnvValueOrFail('BLOCKCHAIN_CONTRACT_ADDRESS'), | ||
| logLevel: (process.env.LOG_LEVEL as string) || 'trace', | ||
| inputDataFolder: (process.env.INPUT_DATA_FOLDER as string) || '/sp/inputs', | ||
| secretsDataFolder: (process.env.SECRETS_DATA_FOLDER as string) || '/sp/secrets', | ||
| certFileName: (process.env.CERT_FILE_NAME as string) || 'certificate.crt', | ||
| certPrivateKeyFileName: (process.env.CERT_PRIVATE_KEY_FILE_NAME as string) || 'private.pem', | ||
| configFileName: 'tunnel-client-config.json', | ||
| configSearchFolderDepth: 1 as number, | ||
| clientServerPort: 9000, | ||
| serverFilePath: path.join(__dirname, './server.js'), | ||
| configurationPath: process.env.CONFIGURATION_PATH || '/sp/configurations/configuration.json', | ||
| localServerStartTimeoutMs: Number.parseInt(process.env.LOCAL_SERVER_START_TIMEOUT_MS || '900000'), // 15 min | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Significant code duplication detected.
This configuration file is nearly identical to open_webui/src/config.ts, which violates the DRY principle and increases maintenance overhead. Consider extracting the common configuration logic into a shared module or base configuration that both submodules can extend.
Consider creating a shared configuration module:
// shared/src/base-config.ts
export const createBaseConfig = (packageJson: any) => ({
appName: packageJson.name,
appVersion: packageJson.version,
blockchainUrl: getEnvValueOrFail('BLOCKCHAIN_URL'),
blockchainContractAddress: getEnvValueOrFail('BLOCKCHAIN_CONTRACT_ADDRESS'),
// ... other common config
});Then each submodule can extend this base configuration with specific overrides.
🤖 Prompt for AI Agents
In Dia TTS Server/src/config.ts lines 1 to 24, the configuration code duplicates
logic found in open_webui/src/config.ts, violating DRY principles. To fix this,
extract the shared configuration properties into a new shared module, for
example, shared/src/base-config.ts, which exports a function returning the
common config. Then, import and extend this base config in both Dia TTS Server
and open_webui config files, adding only module-specific overrides locally to
reduce duplication and ease maintenance.
| const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options); | ||
| await tunnelClient.start(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Missing resource cleanup for tunnel client.
The tunnel client is started but there's no explicit cleanup mechanism. Consider adding a shutdown handler to properly close the tunnel client on process termination.
const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options);
+
+ // Add cleanup handler
+ process.on('SIGTERM', async () => {
+ logger.info('Received SIGTERM, shutting down tunnel client');
+ await tunnelClient.stop();
+ process.exit(0);
+ });
+
await tunnelClient.start();📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options); | |
| await tunnelClient.start(); | |
| const tunnelClient = new TunnelClient(config.serverFilePath, domainConfigs, options); | |
| // Add cleanup handler | |
| process.on('SIGTERM', async () => { | |
| logger.info('Received SIGTERM, shutting down tunnel client'); | |
| await tunnelClient.stop(); | |
| process.exit(0); | |
| }); | |
| await tunnelClient.start(); |
🤖 Prompt for AI Agents
In Dia TTS Server/src/index.ts around lines 39 to 40, the TunnelClient is
started but lacks a cleanup mechanism. Add a shutdown handler for process
termination signals (e.g., SIGINT, SIGTERM) that calls a method on tunnelClient
to properly close or stop it, ensuring resources are released gracefully when
the application exits.
feat: Add Open WebUI integration with Super Protocol tunnel client
│ - Add Open WebUI as git submodule for AI chat interface
│ - Implement TypeScript wrapper with tunnel client integration
│ - Configure Docker setup with multi-stage build for frontend and backend
│ - Add Ollama integration for local LLM inference
│ - Set up proper data directory structure at /opt/app/data
│ - Configure SSL/TLS support for secure connections
│ - Add environment variables for blockchain and tunnel configuration
│ - Optimize Dockerfile by removing unnecessary build checks
│ - Add comprehensive .gitignore for certificates, build artifacts, and user data
Summary by CodeRabbit
New Features
Chores
Documentation