好久不见，2024年一整年没有更新 bubble，因为实在是经历了太多丰富的事情了。

具体干啥了​

首先我的网站虽然首页没有更新，但我的 self-host 清单却变多了，而这些服务大多数都运行良好，SLA也超过了 99.9%。这些服务包括但不限于邮件的收发、CICD、运维监控、笔记、工作流等，并且这些业务中的绝大多数都能完美接入 SSO 服务，我想如果我有时间，我会分享一下这些项目。

与此同时我发起并参与的项目“米物百科”也上线了小程序和网页版，并且新增了几位核心合作伙伴。这个项目应该会持续下去，并且后续会继续新增更多的功能。如检索、更多的信息、对比等。可以去围观一下：https://mijia.wiki 。

2024年我还参与了一个较大的开源项目发布前的开发工作，感谢小米及生态链的各位大佬以及米粉朋友们，我也认识了不少可爱的小伙伴~ 另外欢迎点 Star（虽然点了我也不会有奖金）：https://github.com/XiaoMi/ha_xiaomi_home 。

饼​

对，还有之前画的饼。

limail 的项目其实已经可以用了，并且我也在用，非常好用。但未公开，因为成本实在是太太太高了。 其实项目主要分为两部分：

1. 邮件匿名平台：提供一个匿名邮件地址，类似 iCloud 的隐私转发邮箱。可以实现一网站一邮箱，有效避免垃圾广告。
2. 消息处理平台：将接收到的邮件或其它通知，经过大模型进行分类及压缩，对推送的消息进行压缩，并推送到指定渠道（比如飞书、bark等）以实现验证码、邮件的摘要发送。避免每次阅读验证码需要花费大量时间寻找。

看到这里各路大佬们应该猜到成本巨高的部分了。我正在考虑将第一部分开放出来，允许注册与非注册用户使用。

• 如果你有统一身份管理信息，可以到 https://scarborough.lzj.ac.cn/ 使用
• 出于合规原因，下面提及的功能目前不对互联网开放注册使用（仅科研及测试使用）。如果你是高校、科研机构的导师、或者我的朋友，请通过其它方式或邮件与我联系 jimmy@lzj.ac.cn。我会很高兴收到你的信息。

Scarborough 斯卡布罗​

Scarborough 是服务台框架，类似一个 Console，用户可以在 Scarborough 平台使用各种科学研究与服务工具。

平台作用​

我规划了许多的项目正在开发，包括知识库、数据仓、智能流控制系统、Limail 等工具。这些工具可以相互配合使用，比如可以使用 数据仓 的指定内容可以使用 智能流控制系统 自动归纳到个人的知识库中。

如果为每个平台独立开发一个 Console 将会无限增大开发与维护难度，也会造成使用的割裂感（特别是在移动端，不方便切换多页面的时候）。Scarborough 就像 一个巨大的集市一样，为各种工具提供一个统一的使用入口。以后会可能会陆续提及这些功能。

Limail 身份系统​

Limail 狸猫是一个消息与身份管理平台，旨在合法的情况下从根源上解决账号安全问题、消息混杂问题。

• 统一信息管理拟解决的问题：

1. 消息来源渠道过多，过于混乱问题。
2. 信息或通知信息熵与信息价混乱，错过重要信息或被无关消息浪费时间问题。
3. 验证码在一堆无关文字中无法迅速找到的问题。
4. 通过邮件或其它方式发送的验证码，无法快速复制的问题。
5. 消息来源无法验证，消息内容可能存在有害信息的问题。

• 在信息安全方面拟解决的问题：

1. 当你的一些识别信息，比如电子邮箱、手机号或者用户名被知晓后，这些信息可能会被用于尝试登录其他平台，以检查你是否在那些平台上也拥有账号的问题。
2. 在网购活动后，可能会出现频繁接到自动语音电话的情况的问题。
3. 点开一份邮件后，对方就已经收到你已读邮件的信息的问题。

上面的问题只是冰山一角，狸猫系统需要解决的问题不仅仅于此。

上图了​

这个网站终于终于，我把图片功能开发好了，丢张AI生成的图纪念一下：

提示词： 想象一个古代欧洲宫廷风格的数据中心油画：一座豪华的大厅，墙壁上挂着精美的壁毯和典雅的画作，天花板上有精致的雕刻和金箔装饰。在大厅中央，放置着服务器大型机柜排列着，上面装满了服务器设备。机柜之间，穿着传统宫廷服饰的人物（男性和女性，展现不同种族）忙碌地在机柜间来回走动，手持羽毛笔和硬盘。在一角，一个穿着华丽服饰的贵族（白人男性）正凝视着一个装饰繁复的屏幕，侧面还有几个人在使用MacBook。整个场景融合了古代欧洲宫廷的奢华与现代数据中心的科技感，展现了一种独特的时空融合。

让我们根据这个描述来生成相应的图像。

Recently, I have been busy with learning English and dealing with a sudden pile of school assignments. The homepage will be temporarily updated with content, and features will be added later as needed.

This is a history of my development in account management. If you're only interested in the technology I am currently using, please skip this historical part.

History​

• Back in 2008, when I set up my first page, I wanted to implement login and registration features. During my elementary school years, the most I could do was manage logins with Excel.
• Then in middle school, I came across VisualBasic, which made it easy to implement a login system. However, I faced two problems: VB programs were easily decompiled to reveal passwords, and I didn't know how to do online authentication (or even write server-side code). The second issue was that an exe program, especially one that was frequently updated, was hard to demonstrate to friends and difficult to distribute (after all, who knows if your program contains viruses).
• Still in middle school, I used VisualBasic to implement monitoring and basic management of multiple Windows servers, and a basic Web backend (returning a string or something similar, without any standards or JSON). Of course, I also implemented web login: account and password verification based on a 404 error for xxx.com/password.html not found.
• By high school, PHP had become "the best language in the world". I implemented login, but the account and password storage method was based on file storage. Looking back, using a database would have been much simpler than what I did with file-based storage, but I chose the most difficult path among the odd and challenging ones.
• In university, with more time on my hands, not only did I start using databases, but I also employed various databases and encryption methods. Below is the latest update on my account management mechanism.

Using Open Source Account Management​

Selection Introduction​

Currently, my approach to account management is domain control + single sign-on. Although I understand most of the principles and have implemented them, creating a complete visual interface is a huge task. So I turned my attention to current open-source projects, such as Zitadel. I have successfully integrated several platforms using Zitadel's SDK, but I've also encountered some pitfalls. I won't go into the specifics of integration and deployment in this blog, but I'll organize this information once I'm more settled (at least one foot on solid ground).

Concerns and Solutions (Out of Sight, Out of Mind)​

1. Could such a project suddenly start harvesting users? I think, if they do, then it's time to build my own (or find another one).
2. What if I encounter a bug I can't fix? Since it's an open-source project, just submit a PR and become a part of the open-source community.
3. Will publicizing my tech stack lead to targeted attacks? Yes, but it's inevitable. Even building my own system won't avoid vulnerabilities, and intentionally hiding my tech stack isn't easy, requiring changes at the core or foundational level. So for most of my projects, I choose not to deliberately hide any technology stack I use. I rely on honeypots, attack tracing, firewalls, and separating services from data for security.
4. Will the authentication system be subject to traffic attacks? Yes, but using a CDN is only for faster static responses. The defense steps are as follows: regional cleaning (region, ASN, operator), then full cleaning, attack tracing, and feature recording (the rest depends on the law). The intent of the attack is also important. I categorize them into three types: accidental, unavoidable. For random attacks, if it's just for fun... why not consider contacting me and becoming friends rather than enemies? For malicious attacks... well, thanks?

Account Allocation​

Currently, I will make as many tools and services publicly available as possible, but some resources are either too costly or need to be protected (like my graduation project), so I have to implement identity verification. Please understand.

Can I get an account? For compliance reasons, I currently do not provide any information registration channels. If you are a faculty member of a college, a scientific research institution, or a good friend of mine, please contact me via email or other means at jimmy@lzj.ac.cn. I would be delighted to hear from you.

I have migrated the website architecture from Next.js to the open-source Docusaurus, and simultaneously transitioned the server from the previous service+CDN architecture to a fully Serverless environment.

1. About Migrating to Docusaurus​

Currently, my development speed alone is not sufficient to support the platform I envision. Therefore, I have decided to invest more resources into developing what I consider to be more critical and exciting features. This may, of course, result in some inconveniences, such as the inability to perform certain advanced web operations that were possible before. However, this will not hinder me from continuing to use the previous design and my user interface (UI) design. Additionally, my development work will continue, including the design of components and icons.

If you are not a professional developer and are not familiar with what Docusaurus is:

• Docusaurus is a comprehensive page design tool that allows me (as a user) to fully focus on content creation without worrying about various formatting issues. Of course, if I need special formatting or additional functionality, customization can be done on top of it.
• The biggest benefit, in my opinion, is that Docusaurus is based on the open-source community, so I can always get new features provided by the community, such as new buttons, input fields, etc., without spending too much time on it.

2. About Abandoning Traditional Service Architecture​

One of the most significant changes in this update is my abandonment of the previous traditional service architecture in favor of a fully Serverless architecture. While I could list many theoretical reasons for adopting Serverless, the following are the ones that truly convinced me:

1. Cost Savings​

Transitioning from a traditional server architecture to a microservices architecture resulted in a reduction of approximately 60% in my actual expenditure for the same computing capacity.

2. Streamlined Operations​

There is almost no need for tedious operational work.

• Firstly, load balancing: While we still need to consider load balancing at the CDN level, we no longer have to worry about load balancing at the server level. And if it happens to involve stateless services, we can achieve load balancing at the CDN level, significantly reducing maintenance burdens and costs.
• Next is server-related issues: including networking, system, security, and system updates. Although these operational issues still arise when using Self Host Serverless, there is no longer the worry of an entire server crashing due to the failure of one service, thanks to a simple and cost-effective load balancing solution. Of course, for well-funded enterprises that have always used dedicated load balancing, this may not be an issue.
• Then comes deployment: Traditional deployment methods usually involve shutting down services, copying files, and restarting. However, with the help of container technology and Serverless technology, these processes are no longer required. Combined with modern automated deployment workflows, most of my websites (about 90%) are now automated deployments.

3. Security​

This is quite interesting. While it cannot be said that Serverless is necessarily more secure, at least the issues regarding system security have become more abstract. Let me briefly outline the timeline of security evolution:

• 2020: Logging into servers via passwords over public networks, with databases also hosted on servers.
• 2021: Logging into servers via certificates, and placing the database on a separate server isolated from the internet.
• 2022: Logging into servers via certificates, with no dedicated server for the database.
• 2023: All public services no longer rely on dedicated servers.

Here are some past musings

• 5/22/2023 Page title gradually adapted, with a frontend cache hit rate of 98%.
• 5/16/2023 Updated a bunch of things, really a bunch.
• 5/12/2023 Perfect, now this page can be edited with dedicated tools without modifying the code!
• 5/9/2023 When you see this text, it means I have once again rebuilt the frontend of this website using Next.js:
  1. The frontend now implements SSR+SSD+CSR, greatly reducing the initial load time and improving SEO. Utilizing Next.js technology.
  2. Since SSR is in place, the old OSS approach is not very viable, and maintaining cloud servers is cumbersome, so Serverless + cloud virtual containers have been implemented.
  3. Login and registration are currently being researched for SSO+AD integration, because... there are too many platforms to integrate with.
  4. The main direction for the development of this website is technology sharing and resource sharing, with some personal tools and private features. I'm not in a hurry, after all, my little site doesn't have much traffic. The above technologies will be shared in articles in the future (setting expectations).
• 2/23/2023 Added a batch of private systems, and the cluster is basically complete. The homepage is being refactored using React to quickly implement cross-page functionality.
• 2/22/2023 The login system has transitioned from a locally built OAuth stack to LDAP/SSO research.
• 2/11/2022 Features are quite challenging, but this website shouldn't be abandoned since I've invested money in the servers.
• 8/10/2022 The website's UI is in its early stages of completion.
• 1/30/2022 Recently working on the cloud storage module, launched some small features for testing and to share with a few friends who chat often. The stability is good, but data backup is a major challenge (mainly due to cost).