add REALITY in inbound

[lk29]

example

  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "show": true, // Optional, if true, output debugging information
      "dest": "dl.google.com:443", // Required, the format is the same as the dest of VLESS fallbacks
                "xver": 0, // Optional, the format is the same as xver of VLESS fallbacks
                "serverNames": [
                    "dl.google.com"
                ], // Required, the serverName list available to the client, does not support * wildcards
                "privateKey": "2LpjSS6H6AmwN9_NJI2vL9qcdiPwZaw-TzF5lajy804", // Mandatory, execute ./xray x25519 to generate
                "minClientVer": "1.7.5", // Optional, minimum client Xray version, format is x.y.z
                "maxClientVer": "1.8.0", // Optional, the highest version of client Xray, the format is x.y.z
                "maxTimeDiff": 0, // Optional, the maximum time difference allowed, in milliseconds
                "shortIds": [ //
                    "",
                    "0123456789abcdef"
                ],
      "alpn": []
    },
    "tcpSettings": {
      "acceptProxyProtocol": false,
      "header": {
        "type": "none"
      }

[alireza0]

Do you have any information about how we could generate shortIds ? There are lots of same questions which there isn't any response or documentation provided yet!

[ariandcir]

Hey mate @alireza0 Feel free to use this step by step process to replicate a reality connection successfully: https://github.com/XTLS/Xray-core/discussions/1702

[lk29]

shortIds

Required. The shortId list available to the client, which can be used to distinguish different clients. If set to an empty string, the client shortId can be empty. If non-empty, should be a multiple of 2 hexadecimal digits, with a maximum of 16 hexadecimal digits

random, ideally non-repeating value assigned per client for greater security

[alireza0]

@lk29 @ariandcir Thank you for your comments. Actually, I have read the documents, but this documents could not answer mass usages like what we could use in x-ui. It is enough to use it manually in config.json for xray-core, but I am thinking about how we could store these data in x-ui structure and make it compatible. Another confusion is that what we should do if admin decided to change xray-core version.

[lk29]

colleague, I have been thinking for several days about the legacy we inherited from HexaSoftwareTech / x-ui storing and processing in json "clients": [ { "id": "6c...", "flow": "xtls-rprx-vision", "email": "test...", "totalGB": 107374182400, "expiryTime": 1678590925635 },

I suggest changing this and store records in the database separately for each client then we can store additional fields like ray version and v2ray/xray variant

but this will require reworking the frontend & backend /inbound/addClient/ /inbound/list /inbound/delClient/.... /inbound/updateClient/0

but this will greatly simplify life in the future.

What do you think about it?

[alireza0]

Changing in database will affect previous data and the poeple who wants to migrate to this panel or from this panel. APIs are currently changed by this way. Check this

For any change in the structure, it is better to create new panel from the scatch.

[lk29]

my x-ui collection already has 4 different versions I hoped to find those who want to go ahead. It seems to me that we need to change the skeleton of the old x-ui.

maybe I'll gather my strength and start my independent fork.

[alireza0]

We thought about this fact and it is not avoidable. X-UI was not desined for some kind of usages. I should work on another projects as well.