I just got an idea. I saw Slack’s Modal feature, and I think using it could make the bot cleaner and more interesting.

Here’s the official documentation: https://docs.slack.dev/surfaces/modals/

After using the Ethereal Light theme for a while, I realized that although the core chat interface was done, many secondary pages still looked like they belonged to a completely different application.

So this update wasn’t about adding a flashy new feature, it was about finishing what Ethereal Light was always meant to be.

This is one of those updates where most users probably won’t notice every individual change, but I hope everyone notices that Ethereal Light feels even more beautiful now.

I also realized that good UI isn’t about making one page beautiful, it’s about making every page feel like it was designed together.

Commit

Confession time:
I’m a high school STEM student. I spend far more time studying math, physics, chemistry, and biology than anything related to design.
I have almost no artistic background, and I’m much more of a coder than a designer, so building Ethereal Light has been quite a journey.
Half of the CSS for Ethereal Light only exists because I kept googling, “How do I make this look less ugly?” 😭
Somehow, after countless tiny tweaks, it’s finally starting to look like the theme I imagined.
Anyway, I hope you love Arona Chat.

I’m planning to further polish Ethereal Light theme and address the suggestions mentioned in the rating feedback. Thanks everyone for the support!

Devlog #6: Introducing Hierarchical Storage Management (HSM) and R2 Support

Over the past day, I have been working on a major redesign of Minamo’s storage architecture.

From Single Storage to Multi-Tier Storage

Minamo now supports configurable storage tiers, including:

• Hot tier (tier 0)
• Warm tier (tier 1)
• Cold tier (tier 2)

Minamo can automatically manage data movement between tiers based on configurable policies.

New Storage Management Architecture

To support this, I introduced several new components:

StorageManager

Instead of directly interacting with a specific backend, object operations are now managed by StorageManager, which decides:

• Where new objects should be written
• Which tier should serve read requests
• When objects should be migrated

Cloudflare R2 Backend

Minamo now includes a native Cloudflare R2 backend.

This enables using R2 as one of the storage tiers.

Background Migration and Storage Optimization

A new HsmScheduler was added to handle background tasks:

• Tier migration
• Storage eviction
• Periodic heat score calculation

To make these decisions smarter, Minamo now records access patterns through a dedicated access_logs.db.

This allows Minamo to gradually evolve from rule-based storage movement toward more intelligent storage scheduling.

What’s Next

The next development direction will focus on improving compatibility and expanding storage backend options.

Planned tasks:

• Add Hack Club CDN support as a new storage backend
• Improve configuration documentation and examples
• Continue improving HSM scheduling algorithms

Minamo is gradually becoming a more complete storage management system.

There is still a long way to go!

Commit

Devlog #5: Why is it called Minamo?

Someone recently asked me whether Minamo was named after Mixamo.

It actually wasn’t, but I realized I had never shared where the name came from, so here’s the story.

Minamo is derived from the Japanese word みなも (水面, minamo), meaning “the surface of the water.”

The idea behind this name comes from the relationship between the surface and what lies beneath it. From above, the surface of a lake appears simple, calm, and clear. However, beneath that surface exists a much more complex world that is hidden from view.

This is also the philosophy behind Minamo. For clients, Minamo provides a simple and consistent S3-compatible interface — just like a calm water surface that is easy to interact with. Behind that interface, Minamo handles the complexity of storage systems, including different storage backends, tiering, caching, and data management.

Minamo aims to keep the surface simple while allowing the complexity underneath to remain invisible, creating a clean and reliable experience for clients.

I’m currently adding Cloudflare R2 support to Minamo, and I was wondering: what if I also added Hack Club CDN as an optional backend?
Since it offers free storage, it could be a pretty cool addition. What do you all think? Would love to get some feedback!

Devlog #4: Layered Config, HTTP Range & Multi-Backend Foundations

Over the past couple of days, I’ve been working on one of the biggest refactors since Minamo entered its MVP stage.

This update introduces a layered configuration system, HTTP Range support for S3-compatible downloads, a redesigned CLI, and a cleaner runtime state architecture.

To keep the project moving forward, I ended up working on Minamo almost everywhere I could — on my desktop, in GitHub Codespaces, through remote SSH sessions on a Linux server, and even from GitHub Mobile whenever I had a few spare minutes.

Unfortunately, development time spent through remote SSH sessions and GitHub Mobile isn’t tracked by Hackatime, so those hours don’t appear in my statistics.

Also, because this refactor involved lots of experimentation and incremental changes, I squashed many small commits into a single clean commit before pushing. The history is much cleaner now, even though it hides quite a bit of the work that went into this update.

Highlights

Layered Configuration System

The previous environment-variable-only configuration has been replaced with a layered configuration system:

CLI arguments
    ↓
Environment variables
    ↓
TOML configuration files

This makes deployments much more flexible while still allowing temporary overrides from the command line.

The refactor also introduces:

• ConfigManager
• Automatic configuration scaffolding
• config.example/ templates

HTTP Range Support

Minamo now supports HTTP Range requests for S3-compatible downloads.

Clients such as rclone and the AWS CLI can now download only the required portions of large objects instead of fetching entire files.

Supported formats include:

• bytes=start-end
• bytes=start-
• bytes=-suffix

The implementation correctly returns 206 Partial Content, Content-Range, Accept-Ranges, and proper 416 Range Not Satisfiable responses.

CLI & Runtime State

The CLI has been redesigned around subcommands:

• minamo init
• minamo run

Runtime-generated state has also been separated from user configuration, making deployments cleaner and preparing the project for future storage backends.

What’s Next?

The next milestone is adding additional storage backends.

Current roadmap:

Layered Storage Scheduling

Alongside new storage backends, I’m also redesigning Minamo’s storage scheduling architecture.

The long-term goal is to support a layered storage model, where frequently accessed (“hot”) data stays on fast local storage while less frequently accessed (“cold”) data can be transparently moved to lower-cost backends such as OneDrive.

Since Minamo hasn’t seen production workloads yet, this design is still largely based on theoretical considerations rather than operational experience. I fully expect it to evolve as the project matures and real-world usage reveals better trade-offs.

Cloudflare R2

This will likely be the first backend after the local filesystem.

Cloudflare R2 is surprisingly developer-friendly: it only requires a credit card for verification, includes 10 GB of free storage, and charges no egress fees. For many personal and small projects, I think it’s one of the best object storage services available.

Microsoft OneDrive

After R2, I plan to implement a OneDrive backend.

I wouldn’t recommend using a personal OneDrive account as production object storage. It isn’t designed for that, can be less reliable, and is relatively easy to hit rate limits (HTTP 429).

However, for personal projects or storing infrequently accessed “cold” data, it’s an incredibly cost-effective option and fits Minamo’s planned hot/cold storage architecture quite well.

Commit

Devlog #3: Designing a New Configuration System

I am currently working on gradually refactoring Minamo’s configuration system.

Previously, Minamo relied mainly on MINAMO_* environment variables for configuration. As more features and storage backends are introduced, this approach becomes increasingly difficult to maintain and does not clearly separate normal configuration from sensitive information.

The new design will move towards a TOML based configuration system. Configurations will be split into multiple .toml files. This keeps the configuration structure clearer.

I chose TOML because it is easier to represent options and allows users to directly review and edit their configuration.

Configuration files will be ignored by git and initialized from config.example/ on the first run, ensuring that users have a clear starting point without accidentally committing private information.

I am also implementing a new ConfigManager to unify configuration loading, with the following precedence:
CLI arguments > ENV variables > CONFIG files
This keeps the flexibility of temporary overrides while providing a stable configuration system for deployments.

These changes are still being gradually implemented and have not been released yet. The goal is to make Minamo’s architecture more suitable for long-term usage and easier to extend in the future.

Devlog #2: Local Disk MVP Complete

Today marks an important milestone for Minamo, the Local Disk MVP is now complete.

The first goal of this project was never to build a full storage platform overnight. Instead, I wanted to establish a solid foundation: a correct, well-structured, and S3-compatible server with clean separation between the API, service, metadata, and storage layers.

With the MVP completed, Minamo now supports:

• S3-compatible object and bucket operations
• Multipart uploads
• Presigned URLs
• AWS Signature Version 4 (header & query authentication)
• AWS-chunked streaming uploads
• A pluggable storage backend architecture, with Local Disk as the first implementation

Compatibility has also been continuously validated against the official AWS SDK, giving me confidence that the foundation is ready for what’s next.

That said, this is only the beginning.

The original vision for Minamo has always been much larger than a local storage server. The next stages will focus on turning Minamo into an intelligent storage gateway capable of routing data across multiple storage providers, automatically managing hot and cold data, introducing caching, and making storage both more efficient and more affordable.

There’s still a long road ahead.

Thanks to everyone following the project so far. More exciting updates are coming soon!

Commit

Devlog #1: Building Minamo

I’m excited to share the very first development update for Minamo.

Minamo is an S3-compatible storage gateway designed to reduce storage costs while remaining fully compatible with existing S3 clients. The long-term goal is to intelligently manage object placement, keeping frequently accessed data on fast storage while transparently moving cold data to lower-cost storage.

The project is currently about 50% complete.

Why Minamo?

The idea came from developing my AI chat application, Arona Chat.

While building its attachment system, I noticed that most uploaded files are accessed frequently for only the first few days before becoming “cold” data. They still need to be retained, but keeping everything on expensive hot storage unnecessarily increases operating costs.

That led to a simple question:

What if an S3-compatible gateway could automatically keep hot data on fast storage while moving cold data to lower-cost storage?

That’s how Minamo began.

Development Strategy

Rather than building the complete multi-tier storage system from the beginning, I’m developing Minamo in stages.

The first milestone is a Local Disk-only MVP, focusing on implementing a correct S3-compatible server before introducing additional storage providers.

To make future expansion straightforward, the project already adopts a layered architecture:

• HTTP / S3 API Layer (FastAPI) — request handling, XML responses, AWS Signature Version 4 verification
• S3 Service Layer — business logic and S3 error mapping
• Metadata Layer — provider-independent SQLite metadata
• Storage Backend Interface — pluggable abstraction with a Local Disk backend for the MVP

This separation allows future storage backends to be added with minimal changes.

Current Progress (~50%)

The MVP is actively under development.

Implemented so far:

• PutObject / GetObject / DeleteObject / HeadObject
• ListObjectsV2 (prefix, delimiter, pagination)
• Bucket operations
• Multipart Upload
• Presigned URLs
• AWS Signature Version 4 (header & query authentication)
• AWS-chunked streaming uploads

Compatibility is continuously verified against the official AWS SDK, with 22 boto3 compatibility tests currently passing against a live server.

The remaining work mainly focuses on completing the MVP and polishing compatibility before introducing additional storage providers.

Looking Ahead

Alongside finishing the Local Disk MVP, I’m designing Minamo’s future storage orchestration system.

The long-term vision is an intelligent storage gateway capable of automatically managing data across multiple storage tiers, including high-performance local storage, cache layers, and low-cost cold storage, while remaining fully compatible with the S3 API.

Hopefully Minamo can help make self-hosted object storage both more affordable and more efficient.

Thanks for reading! If you’re interested in the project, feel free to follow the project. I’ll share another devlog once the Local Disk MVP is complete and development moves into the multi-storage stage.

Changes

This update introduces benchmarking and metadata-related features, along with improvements to the trainer engine and documentation.

Detailed changes:

• Add benchmark.py for training performance evaluation
• Add test_benchmark.py and test_metadata_features.py to improve test coverage
• Enhance the trainer engine with advanced evaluation capabilities
• Improve LoRA method exporting with detailed example configurations
• Update documentation with comprehensive usage and configuration examples

Status

With this update completed, the training framework is now ready for official use.

For detailed usage instructions and examples, please refer to:

• Demo Guide: DEMO.md
• Usage Guide: USAGE.md

Minimum Hardware Requirements

Please note that this project has relatively high resource requirements. The following configuration is recommended as the minimum supported environment:

OS: Ubuntu 24.04 LTS
RAM: 64 GB
GPU VRAM: At least 12 GB
NVMe SSD (recommended for latent/text-encoder caching)

Running below these requirements may result in insufficient memory, significantly reduced performance, or inability to complete training.

Thank you for following the development of this project.

Commit

After fixing a number of issues, the Arona Chat Public Demo is finally ready!
You can try it using the link below.

https://aronachat.yearcakes.com/

Changes Made

Checkpoint System:

• Added thread-safe locking for checkpoint writes to prevent corruption
• Required optimizer_state_dict validation for checkpoint integrity
• Stopped background writers in test cleanups to prevent resource leaks
• Added cache_vae_dtype config field with fp32/bf16 tradeoff options

Dataset & Caching:

• Migrated dataset caching from pickle to safetensors format for faster/safer storage
• Added cache_vae_dtype VAE precision control (fp32 safe, bf16 faster/lower VRAM)
• Added seed parameter for reproducible dataset shuffling and deterministic sampling

Performance Optimizations:

• Added TF32 matmul and cuDNN benchmark for CUDA hardware
• Added torch.compile support for UNet with dynamic shapes
• Enabled pin_memory on CUDA for faster data transfer
• Added VRAM monitoring throughout training phases
• Reset peak memory stats per epoch for accurate telemetry

Hardware Guardrails:

• Added GPU-first guard verification test (skips on CUDA-enabled machines)
• Added mixed_precision=‘no’ VRAM usage warnings for <16GB GPUs
• Better handling of CPU RNG states after map_location=“cuda” loads
• GPU memory cleanup after model offloading

Testing:

• Fix test_checkpoint.py to shutdown background writers
• Add GPU-first guard test that requires non-CUDA environment

Commit

Upcoming Changes:

• Add more personalization features, such as customizable tone and emoji usage.
• Refine the Ethereal Light theme.

feat: add gradient accumulation and offload checkpoint writes to a background worker

• Accumulate gradients across micro-steps: zero grad only at window start, scale loss by acc_steps, and step optimizer/scheduler at window end.
• Move snapshot serialization to a background thread so disk I/O and the “latest” copy no longer stall training; recovery checkpoints stay synchronous for crash-durable resume.
• Clone state to CPU (_to_cpu) before enqueueing to avoid GPU OOM and in-place corruption by later training updates.
• Treat rolling recovery checkpoints as a minimal resume set (LoRA+RNG only); full snapshots still store optimizer/scheduler/scaler state. Resume from a rolling checkpoint rebuilds optimizer momentum and LR schedule from scratch.
• Make CaptionProcessor RNG thread-safe with a lock for concurrent prefetch.
• Add flush()/shutdown() for deterministic test state and clean process exit.

Commit

After fixing a number of issues, the Arona Chat Public Demo is finally ready!
You can try it using the link below.

https://aronachat.yearcakes.com/

AronaChat v1.2.0 — A Bigger Update Than The Version Number Suggests

Today, I completed AronaChat v1.2.0!
Although this is only a minor version bump, it actually includes a lot of major improvements and new features.
In this update, I added multi-provider support, custom models, the new Ethereal Light theme, and many other improvements. There are still many things to polish, but I’m working hard to turn AronaChat into something that we can genuinely use in our daily lives — not just a project.
The current codebase has grown into a very complex system, so I’m planning to deploy the Public Demo version tomorrow.
But this Public Demo is not just a temporary showcase. My goal is to make it a long-term usable product. You will be able to connect your own API providers and use AronaChat with your own services.
To protect your privacy and security, the current version includes encrypted API key storage and multiple layers of security protection to keep your credentials as safe as possible.
Due to storage and cost considerations, each user will have a fixed storage quota. If the limit is exceeded, attachments will be automatically removed using a FIFO (First In, First Out) rolling deletion system.
For chat history, I’ll try my best to keep conversations stored for as long as possible while maintaining reasonable operating costs.
Thank you for following the development of AronaChat!
This is still just the beginning, and I hope it can become a tool that people truly enjoy using.