Some To-Do Items
It's February 4, 2026, 00:00.
Worked all day, overall a process of letting AI do the work while thinking. A bit tired, will continue tomorrow.
There are some worthwhile things to do, jotting them down.
1. Opening Up Our System
Regarding permissions within Yuan's host, can the permissions for connecting to the host be designed asymmetrically? That is, not all terminals connecting to the host obtain the same permissions. This would help us better control permissions and thus better open up our data. Currently, due to the lack of a permission mechanism within the host, we have to temporarily close off some data sources and dare not casually expose them to AI. Ultimately, this affects the progress of experiments.
Specifically, can read permissions for SQL be granted? Can write permissions for SQL be granted? At the Method level, should access be allowed by default or denied by default? How should authorization be carried out? These questions all need careful design.
The benefit is that we can grant Yuan CLI higher permissions, allowing AI to work better.
In the future, Yuan might become a data source and order placement platform. The strategies in between will likely be diverse. For now, besides Yuan's built-in Kernel+Agent strategy platform, there's also the TimeLab strategy platform developed by Mage, and the persistent warfare experiment repository I've been working on recently. They are based on different design philosophies and tech stacks and may coexist in the future. However, these strategy platforms all need access to Yuan's data and order placement interfaces.
Therefore, how to design a good permission system is an important issue. To open up, one must first set up defenses (Fenghua accent).
2. Capability for AI Assetization
Recently, while using some relay APIs, I noticed they are using the New API project for user management and billing. Essentially, they are assetizing their subscription pools, buying wholesale and selling retail to users. However, this sales method, because it's not tied to business, prevents selling at a high price. The bargaining power here is conceded to the upstream business side.
To some extent, they represent AI API assetization, a primary form of AI assetization. Building upstream AI products can leverage underlying API assets to smooth upstream business operations, allowing users to avoid directly facing the complexity of API configuration, thereby improving user experience. Direct product subscriptions, or pay-as-you-go products! Users only care about the combined product, not how the underlying APIs are configured. This creates another layer of profit margin.
Currently, API KEY management remains a barrier for ordinary users. Many users are not clear about the concept of API KEY, or even how to apply for and manage one. Therefore, intermediaries in the AI business still have significant opportunities. This is essentially a problem of knowledge gap. This type of profit is highly scalable.
Of course, I believe BYOK (Bring Your Own Key) will definitely be a trend in the future. Users will want to use their own API Keys to avoid data leakage issues. On the other hand, users also hope to purchase AI services at API cost price, rather than paying a markup to intermediaries. Actually, intermediaries also perform a lot of business assembly, which is valuable. BYOK on the business side can be an option, but in the next few years, before the concept of API KEY is fully popularized, BYOK will not become mainstream.
3. Enhancement of the User System
Supabase is still a good choice, but its user system still has some shortcomings. For example, it doesn't support passwordless login methods like PassKey. I thought of a solution to make Supabase support PassKey, which comes from:
Using the admin (service_role) identity in an Edge Function to create a Supabase session for a specific user and obtain the access_token / refresh_token, then return it to the frontend.
- Supabase doesn't have an official API for "admin directly generating a session for any user."
- The official recommended approach: Use the combination of
auth.admin.generateLink+auth.verifyOtpin the backend (Edge Function) to simulate a magic link login flow, thereby obtaining the user's session object (which contains access_token / refresh_token, etc.). - This process can be completed entirely within the Edge Function, without actually sending an email to the user or requiring the user to click a link.
Therefore, we can fully implement PassKey login functionality via Edge Functions. From then on, based on the Supabase user system, users can register with email, log in with email, and then also log in with PassKey. The entire process is passwordless, providing a better user experience. However, PassKey is a heavyweight interaction method, not suitable for every operation. It's only suitable for binding with initial login and some important operations (e.g., changing passwords, modifying payment methods, etc.). For regular session maintenance, simply reuse Supabase's access_token / refresh_token mechanism; the JWT mechanism works well.
4. Payment System
A very old and realistic problem: how to get users to pay? How to legally transfer money to the company's collection account? How can we bind a QR code so that users scan to pay, and the money goes to the company's account? These issues all need to be resolved.
We will have several solutions; integrating with a payment platform might be a good choice. Must go through the process, will share later.
