Alternative for clients storage

[torikki-tou]

Disclaimer: i don't speak Chinese so i may not know about similar discussion in Chinese

As far as i know Xray-core has only 2 ways to store clients for VLESS.

1. Config file – can't be changed without restart, become hard to read if has too much clients, hard to scale.
2. Managing clients by API calls – not persistent.

There is workaround if we combine 2 strategies (API call + file change) but it does not resolve 2 last problems with file storage.

My proposal is to allow alternative storages for clients. The ideal scenario is if i can store clients in Redis (or other DB) or integrate with third-party REST API and also have some in-memory cache for performance.

Inbound config can look like this:

{
  "inbounds": [
    {
      "protocol": "vless",
      "settings": {
      // Clients section is ignored if clientsStorage specified 
        "clients": [
          {
            "id": "4c3fe585-ac09-41df-b284-70d3fbe18884",
            "email": "user1@myserver",
            "flow": "xtls-rprx-vision"
          }
        ],
        // Storage config
        "clientsStorage" : {
          // Required Enum field with storage type
          "type": "redis",
          // Required field with custom setting for choosen storage type 
          "settings": {
            // Some Redis settings
            "connectionString": "redis:6379",
            "prefix": "xray",
            "delimiter" : ":",
            // Let's say our storage supports cache
            "cache": {
              "ttl": "5m",
              "maxSize": 100
            },
            // Default flow for clients in storage
            "defaultFlow": "xtls-rprx-vision"
          }
        },
        "decryption": "none"
      }
    }
  ]
}

To implement this Validator must become an interface, custom storages must be written and we need to change config scheme. It is a perfect place to use plugins to let people write their own storages, but i find it too hard to implement, while things i described i can make myself.

My questions:

1. Do you accept that problem with clients configs exists?
2. Do you like my solution? Do you see problems or ways to make it better?

[mmmray]

If you want advanced client management, I suggest to look into Marzban. I still agree that xray could have a different API for it (I quite like the one that Hysteria2 has, where it calls an HTTP endpoint to help with auth)

[mmmray]

but they are still using config file to store user-password

the example file may be misleading, but you have the choice of either enumerating all users in the config file, or using a HTTP callback to validate a user when they connect. it's not that both userpass and http are required

[torikki-tou]

Oh, then i got it

It is exactly what i propose for Xray in my first message, but i also wanted other options for auth providers. Now i am curios about performance of Hysteria with HTTP auth

[torikki-tou]

I took a look at implementation and it is exactly what i was imaging, simple and straight forward. But HTTP call for each connection is not what i would call performant (comparing to sync.Map implementation in Xray). Cache is definitely needed.

At this point, when we even have such example i would ask @RPRX to take a look at this conversation

[mmmray]

So, the problem is what to do with the existing APIs. My impression is that core devs already think there are too many APIs and are tired of maintaining so many features (correct me if I'm wrong)

If there is a proposal to deprecate them, and agreement from the panel maintainers (Marzban, x-ui, etc), then it could be done. I think it is however unlikely that core devs will write the PR themselves, because mostly commercial VPN vendors need this feature. So somebody else would have to come up with a complete proposal for API changes, implement, port panels to new API, etc.

[torikki-tou]

I am going to implement this feature myself anyways, just want to hear from core devs if they want to include it into main project

Waiting