From website to digital space: Technology architecture for Tsukuyomi Space, AI Accompaniment and Future
Tsukuyomi Space was at the beginning a small website to record life, share content and make a difference to Technology.
But with the functional overlaps over and over, it is gradually becoming something else — an integrated content, community, Live2D, LLM, long-term memory and Agent's personal digital space.
Project address:
To date, Tsukuyomi Space has evolved from a relatively simple personal site to an inclusive one. Content systems, user systems, community interactions, Live2D AI escorts, long-term memory, Agent OS, Wiki, pixel workshops, small games, growth systems, object storage, notification systems, etc. Integrated projects.
And the project is going to have a very big change:
Tsukuyomi Space will no longer be restricted to browsers. Follow-up plans to develop a truly stand-alone, platform-wide client using Flutter.
The article details where the current Technology behind Tsukuyomi Space is going to be taken.
First, what is Tsukuyomi Space now?
Tsukuyomi Space may be easily understood as a blog, a personal home page or a binary community if viewed only on page.
But now the project is more than that.
For now, I'd rather understand it as one:
Personal digital space built around “Yachiyo”.
In this space, different functions are not entirely independent.
For example:
- Yes. Stage Reading articles;
- Yes. Plaza Message and communication;
- Yes. Gallery Sharing pictures;
- Yes. Pixel Production of Pixel Art;
- Yes. Wiki (b) To search for information on works and roles;
- Yes. Room Communication with Yachiyo;
- Yachiyo can read the state of some stations;
- Login account numbers to synchronize chat records with long-term memories;
- Agent OS further tries to change AI from a "chat object" to a digital character that can really use tools.
So the project is now developing a complete structure:
text内容
↓
社区
↓
用户
↓
八千代
↓
长期记忆
↓
工具调用
↓
Agent
↓
数字空间
And that's why I didn't just make Tsukuyomi Space a chat page.
I'd rather open Tsukuyomi Space in the future than see one.A digital world that is long-standing and that can accumulate content and relationships。
II. Overall Technology Structure
Tsukuyomi Space master project version already exists 891CommitsIn general, a more traditional set of Web-based structures that are well suited to the ongoing maintenance of individual projects.
The core Technology Inn is as follows:
Structurally, it is broadly understood that:
text ┌──────────────────────┐
│ 用户设备 │
│ Browser / Future App │
└──────────┬───────────┘
│
HTTPS / CDN / API
│
┌────────────────┴────────────────┐
│ │
┌───────▼────────┐ ┌───────▼─────────┐
│ Vue 3 Frontend│ │ Alibaba Cloud │
│ Vite / Live2D │ │ CDN + OSS │
└───────┬────────┘ └─────────────────┘
│
│ REST API
│
┌───────▼────────┐
│ Express Backend │
│ Node.js │
└───────┬────────┘
│
┌──────────┼───────────┬──────────────┐
│ │ │ │
┌──▼───┐ ┌───▼───┐ ┌───▼────┐ ┌────▼────┐
│SQLite│ │ Redis │ │ Mem0 │ │ Milvus │
│ 主库 │ │ Cache │ │Memory │ │ Vector │
└──────┘ └───────┘ └────────┘ └─────────┘
Of which Redis and Milvus are not forced to rely on the project to run.
The advantage of this is that even if only one simpler example is deployed, it can rely on:
textNode.js
+
SQLite
+
Mem0 SQLite Index
Most core functions completed.
If more server resources are available, redis, Milvus, etc. will be gradually activated.
For personal maintenance projects, I think it would be more appropriate than to start with a large pile of intermediates.
Front end: evolution of a unified design system from “page”
The current main frontend of Tsukuyomi Space has been moved to:
textVue 3
+
Vite
+
Vue Router
One of the biggest changes now compared to the early realization of a large number of independent pages is the beginning of a truly unified front-end system.
A set of its own Design Tokens has been established.
For example:
textsrc/frontend/styles/
├── tokens.css
├── themes.css
├── components.css
├── animations.css
└── responsive.css
Responsible for:
- Colours;
- Fonts;
- Spacing;
- Round corners;
- Shadows;
- Deep and light themes;
- Animation;
- buttons;
- Cards;
- Input boxes;
- Navigation;
- Responsive layout.
The new page begins to use the same page gradually --ts-* CSS Variables。
The most important point is not to “beautiful” the code, but to allow the entire site to truly have a unified set of visual languages.
For example:
css--ts-color-bg
--ts-color-surface
--ts-radius-md
--ts-space-lg
--ts-shadow-panel
All you have to do is change the bottom token so you can gradually influence multiple pages, instead of maintaining a completely different set of styles for each page.
And that's why I've invested a lot of effort to optimize UI/UX in recent times.
Tsukuyomi Space has become more and more functional, and without a unified design system, it is easy to become:
Each page is fine by itself, but it's like a dozen different websites.
So UI/UX will still be an important development direction for the project.
IV. ROOM: Tsukuyomi Space ' s Core Experiment Site
If the most special part of the current Tsukuyomi Space is to be chosen, it should be:
Room。
Room does not simply plug an AI chat box in the website.
I hope that it will eventually be:
"Yachiyo really lives in this space."
So now Room has combined a lot of different capabilities.
Including:
textLive2D
+
LLM
+
长期记忆
+
角色知识库
+
TTS
+
天气
+
音乐
+
成长系统
+
MCP
+
站内信息
Users see only a chat page, but in fact there may be multiple contexts behind each conversation.
For example:
text用户消息
│
├── 角色基础人设
│
├── 当前会话
│
├── 长期记忆
│
├── 角色知识库
│
├── 天气信息
│
├── 用户成长状态
│
├── 网站动态
│
└── MCP 工具结果
│
▼
LLM
│
▼
八千代回复
│
├── Live2D 表情
└── TTS 语音
And this is one of the biggest differences between Room and normal chat robots.
The one where Yachiyo livesContextspace with context, history and user status。
Why is LLM not all passing through the Tsukuyomi Space server?
Room has a more important idea when designing:
Minimize user chat content and API Key unnecessarily pass through the Tsukuyomi Space server.
So some of the LLM and TTS requests can be initiated directly by the browser.
For example:
textBrowser
│
│ HTTPS
▼
LLM Provider
Not:
textBrowser
│
▼
月读空间服务器
│
▼
LLM Provider
This has several advantages.
First, to reduce server pressure.
The second is to reduce the handling needs of the server for the user API Key.
Third, it facilitates support for local models.
Room is now connected by browser:
texthttp://localhost:11434
That's the machine, Ollama.
This will result in:
text月读空间页面
│
▼
localhost
│
▼
Ollama
│
▼
本地 LLM
That means:
The web site is still available on the public network, while the model is fully on the user computer.
This is one of the ways I think Room is used very interestingly.
Long-term memory: let Yachiyo really remember
One of the issues that affected the experience was chatting.
It's been a long conversation, as long as it's a new session, it's like the first time I've met you.
As a result, Tsukuyomi Space has now established an independent long-term memory system.
Currently, the main uses are:
textMem0 OSS
+
SQLite
Instead of relying on Mem0 cloud service.
Projects are directly introduced:
textmem0ai@3.3.0
And run in the Node.js process.
Therefore, no additional construction is required:
textPython Mem0 Server
No application for Mem0 Cloud.
Dialogue and memory are not the same thing.
Room will:
text聊天记录
With:
text长期记忆
Separately managed.
Regular chat records are mainly used to maintain the context of the nearest session.
Long-term memories are preserved independently and do not disappear as a result of the recent cutting of chat windows.
For example, users say:
I've been studying Flutter lately.
This sentence may enter long-term memory.
When the client development is discussed a few months later, the retrieval system still has the opportunity to rediscover this information.
This is a truly meaningful long-term memory.
How did long-term memories come back?
Tsukuyomi Space is currently not entirely dependent on a large vector model.
By default, use:
textFeature Hash
+
中文关键词
+
问题类别
+
Mem0 检索评分
Conduct a comprehensive search.
You can also configure remote Embeding service.
The broad process is:
text用户：
“我之前是不是说过想做客户端？”
│
▼
Memory Search
│
┌─────┴─────┐
│ │
Keyword Vector
│ │
└─────┬─────┘
│
▼
Relevant Memories
│
▼
Context Builder
│
▼
LLM
When the system finds the relevant memory, it does not simply shove all the historical chats into the model.
They are:
- Finding relevant long-term memories;
- This post is part of our special coverage Syria Protests 2011.
- Filtered against context budget;
- Add source labels;
- LLM Context.
This way, the longer we talk, the more Token requests, the more exaggerating.
Why should I continue to optimize long-term memory?
While long-term memory has been able to work, this part is far from my ideal.
The solution now is:
"to remember."
What really needs to be addressed is:
"When should I remember?"
These two things are completely different.
I hope to continue to refine a few directions in the future.
1. Memory classification
Not all memories matter the same.
For example:
text身份信息
长期偏好
项目经历
人物关系
临时计划
普通聊天
The future should have different life cycles and weights.
2. Time factor
An interim plan two years ago should not have the same priority as the one just said yesterday.
Memory retrieval therefore needs to be more rationally considered:
text相关度
+
重要度
+
时间
+
出现频率
3. Stronger semantic recall
The default scheme is currently very resource-efficient.
However, with the upgrade of the server and the emergence of a subsequent client, it is possible to gradually increase in the future:
- Better;
- Hybrid Search；
- Rerank；
- Memory Graph；
- Relationship memory.
Let Yachiyo really connect things that have been said at different times.
4. More natural ways of using memory
The ideal long-term memory is not:
"In accordance with Article 3 of the Long-Term Memory, you have..."
And it's natural, like humans, to put past things into chat.
A real good long-term memory should not even be visible to users:
"The system has just implemented a vector database query."
It should just make the character look like:
Really remember.
Nine, Live2D: Make AI more than just text.
Another core part of Yachiyo is Live2D.
The project is now integrated into Cubism Runtme and has a separate Live2D Studio and Room Runtme.
The most basic structures are:
textLLM
│
▼
回复文本
│
├────► TTS
│
└────► Emotion / Expression
│
▼
Live2D
So far, Room has been able to use the dialogue status drive:
- Emoticons;
- Actions;
- State of speech;
- scene feedback.
This is also the direction in which the project will be worth further deepening.
In the end, I hope Yachiyo isn't:
text聊天框 + Live2D 装饰
They are:
textLLM
↓
情绪
↓
表情
↓
动作
↓
语音
↓
Live2D
A truly unified role expression.
X. MCP: Making the tools available to Yachiyo
If long-term memory solves:
Can Yachiyo remember the past.
So MCP solves:
Yachiyo can do something.
Now Room has started supporting MCP.
So theoretically, LLM can be called:
text搜索
文件
API
程序
数据库
本地工具
自定义服务
This is also a critical step in the development of Tsukuyomi Space from AI Chat to Agent.
Traditional chat:
text用户
↓
LLM
↓
文本回复
Agent：
text用户
↓
LLM
↓
判断任务
↓
调用工具
↓
获取结果
↓
继续推理
↓
完成任务
The two experiences will differ in nature.
XI. Agent OS: Put Agent in the Operating System
This is why it happened later:
text/agent-os
Agent OS is a very important try by Tsukuyomi Space.
It is not a traditional operating system, but a set of:
Organization of the interactive environment of Agent, tools and applications in the form of Web OS.
Currently Agent OS is running as an independent application and reverts to Tsukuyomi Space login status and some services.
I want it to solve a problem:
Now a lot of AI functions like this:
textChat
Chat
Chat
Chat
Whether it's a search, a file, a music, a tool, an Agent, it's a chat window.
But the really complex digital space should not be just chat boxes.
So Agent OS begins to try:
textDesktop
├── Agent
├── File
├── Music
├── Tools
├── Terminal
├── Browser
└── Applications
Let AI not be the entire interface itself.
AI should be:
Roles in operating systems.
Agent OS will also continue to perform large-scale optimization in the future, including:
- UI Reconstruct;
- Window management;
- Application systems;
- Agent Schedule;
- MCP tool management;
- Documentation capacity;
- User workspace;
- Yachiyo's integration with Agent OS.
In the end, it is hoped that it will be an important entry point for the entire Tsukuyomi Space Digital World.
XII. CONTEXT AND COMMUNITY remain an important part of Tsukuyomi Space
Although there are now more and more AI-related functions, Tsukuyomi Space will not become a pure AI project.
The project still has a complete content and community system.
Including:
textHub
Stage
Article
Plaza
Gallery
Pixel
Wiki
Friend Links
Growth
Notifications
User Center
Of which:
Stage
Read and write articles.
Plaza
It provides message, response and interaction.
Gallery
It's for display and photo sharing.
Pixel
One fixed:
text192 × 108
Painter's pixel workshop.
Support:
- Painting;
- Publication;
- - Yes.
- Sharing;
- PNG Export;
- Move end touch.
Wiki
This post is part of our special coverage of the United Nations Millennium Development Goals.
- Roles;
- Music;
- Worldview;
- Production of information;
- Terminology.
Growth
The monthly growth system is now in place:
- Daily sign-ins;
- Continuous incentives;
- Daily tasks;
- Level;
- Invitations;
- The growth feedback with Yachiyo.
These systems will eventually continue to be more integrated with Room, Agent OS.
XIII. Server upgrade from 2C2G to 2C4G
As functionality continues to grow, the original server configuration has become increasingly vulnerable to resource bottlenecks.
Other Organiser
text2 Core
2 GB RAM
It has been upgraded to:
text2 Core
4 GB RAM
The number of CPUs has not changed, but the memory has doubled.
This is actually more important for Tsukuyomi Space today.
Because now the server is not just a static blog.
It also includes:
textNode.js
Express
SQLite
Mem0
缓存
任务
后台管理
对象存储逻辑
Room API
通知
用户系统
It is likely to continue to grow in the future:
textRedis
Milvus
Agent
The 2GB memory is already tense in this case.
Upgrade to 4GB to at least:
- Node.js；
- System Cache;
- SQLite；
- Mem0；
- Redis；
- The deployment process;
Leave more.
Of course, server upgrades do not mean an unlimited increase in service.
The use of resources will continue to be controlled.
My direction is not:
"Continue to configure if the server is inadequate."
They are:
Hand-over to CDNs that can be handed over to CDNs, store the hand-over to objects that can be stored by objects, and only real dynamic requests are sent to the source.
14 - Why did you use Aliyun?
Tsukuyomi Space contains a large amount of resources not suitable for long-term pressure on the server disk.
For example:
- User uploading pictures;
- Article cover;
- Gallery；
- Large pictures;
- Audio;
- Video;
- Other annexes.
If all is saved locally:
textUser
↓
Server
↓
Disk
All visits consume:
text服务器磁盘 IO
+
服务器带宽
+
服务器连接数
This is clearly not a good long-term solution as the number of visits and documents increases.
So now we use:
Aliyun OSS.
The structure became:
text ┌── API ─────► 月读空间服务器
用户 ───────────────┤
└── Static ──► OSS
That means:
The server is primarily responsible for:
- (b) Competence;
- Databases;
- API；
- Users;
- AI；
- Dynamic logic.
And OSS is responsible for:
- Pictures;
- Annexes;
- Static resources;
- Big paper.
XV. OSS + CDN: Further reduction of station pressure
It's not enough to have OSS alone.
Tsukuyomi Space is now working further:
Aliyun CDN.
Formation:
textUser
│
▼
Alibaba Cloud CDN
│
├──── Cache Hit
│ │
│ ▼
│ 返回资源
│
└──── Cache Miss
│
▼
Alibaba OSS
Users do not even need to visit the OSS source again when accessing a cached resource.
This is for:
- Pictures;
- JS；
- CSS；
- Fonts;
- Audio;
- Video;
Such resources are very appropriate.
Now the whole structure is coming from:
text所有东西
↓
一台服务器
To:
text ┌── CDN
│
用户 ────────┼── OSS
│
└── Origin Server
Different resources begin to assume different responsibilities.
This is very important for the continued expansion of functionality behind Tsukuyomi Space.
Sixteen, SQLite. Why hasn't he changed yet?
As the project becomes more complex, a natural question is:
Why not MySQL / PostgreSQL?
The reason is simple:
There is no need to change the database for “looks professional”.
SQLite still has many advantages for the present Tsukuyomi Space:
- Simple deployment;
- No independent database server is required;
- Sufficient performance;
- (b) Reliable service;
- Availability of backup;
- Low resource occupancy;
- It's perfect for a single-point personal project.
The project was adopted:
textbetter-sqlite3
Direct database operations.
and has gradually acceded to:
textbackend/db/migrations/
Manage database Schema changes.
The database is therefore no longer simple:
Restructure the table. Library
They are:
textVersion A
│
Migration
▼
Version B
│
Migration
▼
Version C
It would be more reasonable to consider moving PostgreSQL if it really evolved to the point where SQLite became an obvious bottleneck.
XVII. Redis and Milvus: Optional, not mandatory
Another design principle is:
Enhanced capacity could be available, but the most basic deployment must not be made difficult.
The project therefore supports Redis.
For the time being, Redis can participate in:
- Cache;
- (b) Traffic restrictions;
- Token Blacklist;
- Weather caches;
- Authentication code.
However, Redis is not a necessary condition for starting the project.
Similarly, Milvus exists as an optional vector database.
For example, the future can be used on a larger scale:
text角色知识库
+
长期记忆
+
文档
+
语义检索
This would preserve the capacity for future expansion without making ordinary deployments:
textNode
Redis
PostgreSQL
Milvus
MinIO
RabbitMQ
ElasticSearch
...
It takes half a day to get the service started.
For a project like Tsukuyomi Space, I still prefer:
Default is simple, high-level functionality is on demand.
Security is now part of the project.
With:
- User systems;
- Login;
- Uploading;
- OAuth；
- API；
- Managing backstage;
Increasingly, security can no longer be solved by “no one attacks my website”.
The following projects have been added:
- JWT；
- Cookie；
- bcrypt；
- CORS White List;
- CSP；
- Security Headers；
- Request for source verification;
- JSON repeats the Key test;
- Upload file mime check;
- Document characterization;
- SSRF protection;
- External URL verification;
- API restricted;
admin / super_admin Segregation of authority.
For example, in the production environment:
textJWT_SECRET
In a short time, you will refuse to start.
Uploading files not only check:
text.jpg
Such an extension.
It's about taking into account:
textExtension
+
MIME
+
File Signature
These things don't look as obvious as new UIs, but actually, as projects continue to expand, they become more important.
Test: Try to avoid “repair of one place and three places”
Tsukuyomi Space is now more difficult to rely entirely on for manual testing.
As a result, the project began to establish automated testing.
Including:
textnode:test
and:
textPlaywright
The range of tests has been covered:
- API；
- Long-term memory;
- User growth systems;
- Login;
- (b) Competence;
- Information clearance;
- Room；
- TTS；
- Sharing;
- Wiki；
- Navigation;
- (a) Mobile-end layout;
- Live2D；
- Sets the page.
A lot has been said recently:
textRoom 移动端
导航栏
键盘弹出
设置页面
The changes will be synchronized with the addition of Review Test.
As the project grows:
"This change looks okay."
This does not represent:
“There is no problem with the whole project.”
Automation testing will continue to be an important part of the latter development.
XX. Next phase: continuing optimization UI / UX
One of the most intuitive tasks that follows is:
UI / UX。
Tsukuyomi Space has been increasing its functionality very quickly over the past six months.
A lot of pages actually evolved at different stages.
Therefore, one of the most important tasks at this time is not to continue to add to the menus in a crazy way, but to:
text统一
整理
删减
重新组织
The focus will continue in the future:
- Global navigation;
- Room；
- Room Settings；
- User Center；
- Agent OS；
- (a) Mobile-end layout;
- Page level;
- Information density;
- Animation;
- Touch experience.
Especially the moving end.
More and more functions can no longer be performed according to:
"PC page shrink"
The way it is designed.
The desktop and mobile end require a different information organization logic over time.
The next phase: continuing to optimize the conversation with Yachiyo days
Room has many functions, but the final measure of the experience is:
It's not natural to talk to Yachiyo.
Follow-up will continue to optimize:
textPrompt
Memory
Knowledge
Emotion
Live2D
TTS
Context
Tools
In particular, there is a real collaboration of these modules.
For example:
Yachiyo found out the user was talking about the past.
Retrieving long-term memory first.
↓
Discovery related to a particular project.
↓
Loads corresponding memories.
↓
Generates a response.
↓
Analyse the mood in the response.
↓
Switch Live2D expression.
↓
Generates the corresponding TTS.
The whole process should be:
A complete role behavior.
Not six systems that don't know each other exist.
XXII. Next stage: Agent OS will continue to evolve
Agent OS is still in the exploratory phase.
And then I want to move on from it to:
Digital workspace for Yachiyo.
It may evolve:
textAgent OS
│
├── Yachiyo
│
├── Chat
│
├── Files
│
├── Browser
│
├── Terminal
│
├── Music
│
├── Notes
│
├── MCP
│
└── Agent Applications
Compared to the traditional AI website:
text输入框
↓
回答
Agent OS prefers to form:
text目标
↓
Agent Planning
↓
选择工具
↓
执行任务
↓
获得结果
↓
继续执行
↓
最终完成
That means:
Yachiyo's future may be more than just:
"Tell you what to do."
It can:
I'm really involved in this.
Twenty-three, one of the most important things: a platform-wide client
The next largest change in the project as a whole would probably be:
Tsukuyomi Space officially exits the browser.
It has been decided to use the following:
textFlutter
Develop an independent client for Tsukuyomi Space.
The goal here is not:
text打开一个 WebView
↓
加载 yachiyo.hk
It's not simple:
textElectron
+
网页
Instead of rethinking what Tsukuyomi Space should look like on the desktop and move side.
That means:
It would be a truly stand-alone application, not a window for the website.
24, why choose?
Tsukuyomi Space hopes to cover more and more environments in the future.
Including:
textWindows
macOS
Linux
Android
iOS
If each platform is developed separately:
textWindows → C#
macOS → Swift
iOS → Swift
Android → Kotlin
Linux → GTK
The maintenance costs for individual projects are exaggerated.
Flutter allows a lot of:
textUI
状态
逻辑
组件
网络层
Reuse across platforms.
And it's not a simple WebView shell.
It's very appropriate for Tsukuyomi Space.
Twenty-five. Clients don't replace websites.
The future of the Flutter client:
textyachiyo.hk
It will continue.
The Web version is better suited for:
- (a) Content sharing;
- Wiki；
- Public pages;
- Search engines;
- Communities;
- Quick access.
App better fit:
- Yachiyo；
- Agent；
- Live2D；
- Local documents;
- Local models;
- System notifications;
- Desktop-based;
- Offline caches;
- Primary system capacity.
It may eventually result in:
text 月读空间 Backend
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Web Desktop Mobile
yachiyo.hk Flutter Flutter
Share:
text账号
API
内容
记忆
数据
But there are different ways of interacting.
Twenty-six, Flutter will make it possible to do things that were hard before.
The browser is strong.
But there are many limitations to the browser.
For example:
- Local documents;
- System tray;
- Global shortcuts;
- Backstage operations;
- Local notification;
- Primary window;
- Local models;
- Local databases;
- Systemic media control;
- Multiple windows.
After entering the Flutter client, it is more natural to consider:
text八千代桌面常驻
Or:
textAgent 后台任务
Even:
text本地 Ollama
+
本地文件
+
长期记忆
+
MCP
+
Live2D
Formation:
Cloud + Local Hybrid Agent
For example:
text 八千代
│
┌─────────┴─────────┐
│ │
Cloud Local
│ │
月读空间 API Ollama
Account Files
Memory Tools
Community Local DB
This could become a very important Technology route for the future of Tsukuyomi Space.
From the website to the real "Tsukuyomi Space"
If we look back at the development of this project, we will probably go through several stages.
The beginning was just:
text个人主页
After which:
text文章
Add the following:
text用户
+
社区
Later:
textLive2D
+
八千代
After which insert:
textLLM
+
长期记忆
+
MCP
Now again:
textAgent OS
The next phase will be:
textFlutter App
So the course of this project is getting clearer.
textWebsite
↓
Community
↓
AI Character
↓
Memory
↓
Agent
↓
Agent OS
↓
Native Application
↓
Digital Space
This is why the name “Tsukuyomi Space” is now increasingly in line with the project itself.
It's no longer just:
A website on the Internet.
It's becoming:
A digital space capable of carrying content, memories, roles, tools and relationships.
At the end.
Tsukuyomi Space remains a personal maintenance project.
It will not have dozens of development teams, like large commercial products, nor will it complete all the ideas at once.
Many functions are:
text想到
↓
尝试
↓
推翻
↓
重写
↓
发现问题
↓
继续优化
A little bit of it.
The server is now from:
text2C2G
Upgraded to:
text2C4G
Static and user resources are also beginning to be adopted:
textAlibaba Cloud CDN
+
Alibaba Cloud OSS
For distribution.
A few things will continue to be done:
- Continue to harmonize and optimize Tsukuyomi Space UI / UX;
- This is the first time in the world that there have been a number of protests in the world.
- Further improve long-term memory;
- (b) Continue to push Live2D, emotional and voice connections;
- (a) Continue to refine Agent OS;
- Promoting integration of Agent and MCP capabilities;
- Start design and development of a full platform client.
The last of these may also be the most important change in the next phase of Tsukuyomi Space.
The future of Tsukuyomi Space, hopefully not just:
"Open the browser to access a web site."
It could be:
Turn on the computer, Yachio is here.
Turning on the phone, previous conversations, memories and spaces still exist.
She knows what you've done before and can use the tools to help you with your work.
Articles, creations, communities, Agent, Live2D are gradually connected to your digital life.
This is probably the closest I have now to the final form of Tsukuyomi Space:
Leave Journal some moonlight.
Then let the moonlight really have memories.
Related Links
Tsukuyomi Space's current phase of Technology's realization and future direction is recorded here. The project is still under rapid development, so that some of the structures and functions will continue to evolve as the subsequent version.