Propose a standardized vmess:// URI scheme following RFC3986

[Cenmrev]

As the developer of clients V2RayX and V2RayW, here I sincerely propose a
standardized vmess:// URI scheme such that users can share and configure server information more easily and different developers can save time on parsing
different share links as there have already been different types of vmess://
URI schemes and not all of them are compatible with each other. Please see issue #174 and issue #185.

Inspired by SIP002 URI Scheme and Following RFC3986,

VMESS-URI = "vmess://" userinfo "@" hostname ":" port ["/"] ["?" other_settings_encoded] [ "#" tag ]

where

• userinfo = base64-encode-utf8(UserObject)
• tag = the tag used in an OutboundObject, white space should be escaped
• other_settings_encoded = other key-values appeared in an OutboundObject except proxySettings, encoded as a query string

For example, if we have an OutboundObject of vmess protocol like this

{
  "sendThrough": "0.0.0.0",
  "mux": {
    "enabled": false,
    "concurrency": 8
  },
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "myserver.cc",
        "users": [
          {
            "id": "23ad6b10-8d1a-40f7-8ad0-e3e35cd38257",
            "alterId": 64,
            "security": "auto",
            "level": 0
          }
        ],
        "port": 10086
      }
    ]
  },
  "tag": "my server",
  "streamSettings": {
    "quicSettings": {
      "key": "abcde",
      "header": {
        "type": "dtls"
      },
      "security": "chacha20-poly1305"
    },
    "security": "none",
    "network": "quic"
  }
}

The corresponding URI would be:

vmess://eyJpZCI6IjIzYWQ2YjEwLThkMWEtNDBmNy04YWQwLWUzZTM1Y2QzODI1NyIsImFsdGVySWQiOjY0LCJzZWN1cml0eSI6ImF1dG8iLCJsZXZlbCI6MH0=@myserver.cc:10086/?sendThrough=0.0.0.0&mux=enabled=false&concurrency=8&streamSettings=quicSettings=key=abcde&header=type=dtls&security=chacha20-poly1305&security=none&network=quic#my%20server

where

• eyJpZCI6IjIzYWQ2YjEwLThkMWEtNDBmNy04YWQwLWUzZTM1Y2QzODI1NyIsImFsdGVySWQiOjY0LCJzZWN1cml0eSI6ImF1dG8iLCJsZXZlbCI6MH0= is base64 encode

{"id":"23ad6b10-8d1a-40f7-8ad0-e3e35cd38257","alterId":64,"security":"auto","level":0}

• sendThrough=0.0.0.0&mux=enabled=false&concurrency=8&streamSettings=quicSettings=key=abcde&header=type=dtls&security=chacha20-poly1305&security=none&network=quic#my%20server is converted from

{"sendThrough":"0.0.0.0","mux":{"enabled":false,"concurrency":8},"streamSettings":{"quicSettings":{"key":"abcde","header":{"type":"dtls"},"security":"chacha20-poly1305"},"security":"none","network":"quic"}}

This includes all possible information in a complete OutboundObject of vmess protocol except "proxySettings". Some details:

• I do not include proxySettings because this is related to routing, different users have their own routing rules.
• In an OutboundObject, "users" is an array. In this URI scheme, we only include the first element, since to me, it is meaningless for a single user to use multiple identities
• We only include one vnext in a single URI, because it is not guaranteed that different vnext servers share the same streamSettings.

I see some previous discussions on this topic, like #279, #1392, #1139, but seems there no solutions yet. I understand that the purpose of Project V is to build a unified platform and only including outbound information in the URI scheme makes the powerful routing function lost. To solve this issue, we can later scandalize a scheme like v2ray:// or use other methods(but personally sharing the whole config.json should be the best answer). But can we just take one small step forward to solve the issue of vmess:// ?

I also understand that this scheme is not related to the function of v2ray-core. But without an official standard, the fact is what I mentioned in the beginning: there have already been different types of vmess://
URI schemes and not all of them are compatible with each other.

This is just my proposal and more details may need further discussions. What I really want is that vmess can have an official and standardized URI scheme to be posted on v2ray.com so that every client developer and vmess service provider can follow and further we can generate corresponding QR codes.

Edit:
The scheme above has a severe problem. I think @society765 's suggestions is better: #1487 (comment)

[tjLEIIQM3]

支持标准化vmess://但是反对后面那些&key1=value1&k2=v2#tag1
如果只用 vmess://{ base64 encoded string}的形式，可以很容易通过正则匹配出链接
也就是说在一个包含多个分享链接的网页中，不用“每个写一行”，“以回车结尾”之类的限制
直接复制整个页面的源码，然后通过正则就可以抽取出所有链接
而加了后面那些&key1=value1&k2=v2#tag1时，匹配起来就比较麻烦而且容易出错
然后base64主体中用{"id":"xxx","alterId": ...}的形式在有新的配置项时会很尴尬
v2rayN已经遇到一次这个问题，所以从v1升级到v2，然而现在又一次面临这个问题

发现原提议有安全问题,所以删除

[xwang233]

I agree that we really should have a standard and officially recommended vmess:// link.

I notice one problem of your scheme above @Cenmrev. In principle the query string should not contain hierarchical data (RFC3986 3.4.Query). For example, if we parse the example above back, we will get

{
  "sendThrough": "0.0.0.0",
  "mux": "enabled": "false",
  "concurrency": "8",
  "streamSettings": "quicSettings": "key": "abcde",
  "header": "type": "dtls",
  "security": "chacha20-poly1305",
  "security": "none",
  "network": "quic"
}

which is NOT the original data.

I suggest that we also encode the json into base64 codes and the above example will be

vmess://eyJpZCI6IjIzYWQ2YjEwLThkMWEtNDBmNy04YWQwLWUzZTM1Y2QzODI1NyIsImFsdGVySWQiOjY0LCJzZWN1cml0eSI6ImF1dG8iLCJsZXZlbCI6MH0=@myserver.cc:10086/?outbound=eyJzZW5kVGhyb3VnaCI6IjAuMC4wLjAiLCJtdXgiOnsiZW5hYmxlZCI6ZmFsc2UsImNvbmN1cnJlbmN5Ijo4fSwic3RyZWFtU2V0dGluZ3MiOnsicXVpY1NldHRpbmdzIjp7ImtleSI6ImFiY2RlIiwiaGVhZGVyIjp7InR5cGUiOiJkdGxzIn0sInNlY3VyaXR5IjoiY2hhY2hhMjAtcG9seTEzMDUifSwic2VjdXJpdHkiOiJub25lIiwibmV0d29yayI6InF1aWMifX0=#my%20server

where the outbound is encoded json below (white space removed)

{
  "sendThrough": "0.0.0.0",
  "mux": {
    "enabled": false,
    "concurrency": 8
  },
  "streamSettings": {
    "quicSettings": {
      "key": "abcde",
      "header": {
        "type": "dtls"
      },
      "security": "chacha20-poly1305"
    },
    "security": "none",
    "network": "quic"
  }
}

or we can URL-encode the JSON string, see https://stackoverflow.com/questions/15872658/standardized-way-to-serialize-json-to-query-string. Either way should be OK.

[Cenmrev]

@society765 Thanks for the suggestions. I did not notice this severe problem. I think the form of /?outbound={base64-encode} is better since URL-encoded JSON string is much longer than base64-encoded JSON string.

[tjLEIIQM3]

10天过去了，看来这个提案又一次落空了。
默哀。

[VictoriaRaymond]

I second the idea by @society765. I will provide a detailed design later. Please stay tuned.

[Justsoos]

Suggestion: use gzip compress the config file of v2ray, and then base64, could get about 1k bytes URI, and lose none details, easy to run as CLI parameter.

Got smart brains to more valuable things~

[tjLEIIQM3]

Actually, I have tried to compress the entire configuration file, but I found this method worthless.
At the same time, sharing the entire configuration may be a bad idea. Because a hacker can use revers proxy to expose some sensitive local ports, such as 22 3389.

[2dust]

其实分享的目的主要是给多人使用
这样的前提就需要服务器的配置具有通用性，所以很奇怪的复杂的配置基本不会出现，大部分都是简单的配置。然后要考虑各个客户端的实现难度了.如果把每个可能的配置都考虑进去,那么分享出来的内容还原难度就很大,而且v2ray还在不停的改进中,很难保证可用性
以上就是设计v2rayN分享格式的想法，抛弃兼容所有格式，只保留部分简单的配置。大而全的完美兼容的分享格式在v2ray上基本不可能实现
如果你需要超级复杂的配置，那么请用完整版的原始配置吧。

[Justsoos]

复杂也要看数据量，config file 以 gzip压缩后再base64得到1k到2k左右字节，是二维码能容忍的最大数据量50%左右，技术标准上是安全的。
问题是V2ray分享配置没有标准，每个客户端有一套自己解析方式，甚至还版本不同不兼容，这就尴尬了，还不如直接分享原始config file更有效。
说白了，还是v2ray-core功能自由度太高，原罪带来的大号configuration问题

[tjLEIIQM3]

2018.12.25 - 2019.02.22 = 59

[VictoriaRaymond]

Closing in favor of #1569