Hey guys!
I’m currently working on a new theme (Ethereal Dark) for Arona Chat, and it will probably introduce a very large diff with many UI/CSS/component changes.
I’m thinking about creating a dedicated feature branch (theme/ethereal-dark) for this work instead of directly committing everything to main. The idea is to keep the development process transparent and easier to review for future reviewers and users.
After the theme is complete, I’ll merge it back into main.
So I’d like to get your opinion:

• Do you prefer seeing the full development history through a feature branch?
• Or do you think keeping a cleaner main history with a larger commit is better?

Thanks!

Settings now save automatically as soon as you make changes, so there’s no more clicking Save everywhere. The user list also shows each user’s email when available (falling back to the Clerk ID). Improved auth by showing a recovery screen if initialization gets stuck for 12 seconds, and hardened SSRF protection against alternative IPv4 bypass tricks. I’ve already started designing the Ethereal Dark theme too, but since it’s unrelated to this commit I didn’t include it yet. Still probably another 8–10 hours to go before it’s ready.

Commit

This update mainly focuses on improving the logging system to make operations and maintenance much easier. Logs are now more structured and include more useful context.

Commit

I found a few issues in the code, including thread safety bugs, race conditions (which could even corrupt the database), and some resource leaks. So most of my current work has been fixing those.
After that, I’m planning to add HackClub CDN as a storage backend and edit it to my new dynamic storage backend loading system.
ps writing the code is fun, but honestly I think designing the architecture is even more fun. I’ve learned a ton from it, so I’d recommend trying it if you get the chance. If anyone has ideas or feedback on my project architecture, I’d love to hear them!

I added /asachan-settings, now you can configure AsaChan through a Slack modal instead of using multiple commands. This update also brings AQI, sunrise/sunset, and weather warning support, plus a new /asachan-admin command for basic debugging and more detailed stats for admins. I also added automatic timezone detection from city geocoding.

Commit

I redesigned the settings using Slack Modals. Before, you had to use several different commands to configure everything. Now, you can just run /asachan-settings to open the settings page and manage everything in one place. It’s much easier to use now.
Next, I’m planning to improve AQI display and weather alerts display, and fix a few small issues that don’t affect functionality but still aren’t quite perfect.

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