关于标准分享链接的疑问？ about xray-core HOT 23 CLOSED

vless://

分享链接不只是分享链接，推出了就难改协议了，目前还有些增强在等着

from xray-core.

感谢回复，我们不想翻了一个墙，进入另一个墙，这个任何场景都一样。

您说的还是之前上面的说法，我还是那句话，机场给JSON不向下兼容。做出界面不向下兼容，按您的说法更加会毁了协议。
恰恰分享链接的兼容成本是最小的。VLESS出来的时间已经不短了，可以告知哪些东西将来不会变，例如主机、端口、UUID这些将来会不会删除？！确定一些这些不可能会导致“毁了协议”。

可以考虑制定一个可扩展的、灵活的VLESS协议，我们举个实际的例子，例如现阶段没有flow这个东西,未来某一天新增一个出站参数flow，那么客户端应当直接把这个参数从URL参数里原封不动的传给Xray Core，千万别像V2RayN那样自己发明一套字段名，例如把address改叫add、或者server等等 - 这样向下兼容就会很困难。

那么将来Xray Core更新的处理就非常简单。用户只要直接更新Core的版本就可以，客户端几乎不要改动，他可以在界面上增加这个选框 - 也可以没有。而Xray Core对于没有指定flow参数的旧版链接，可以直接指定默认值:"xtls-rprx-direct"

不使用分享链接，才会导致“毁了协议”
官方迟迟不制定分享链接标准，才会导致出现大量不兼容的标准。

from xray-core.

一直都觉得，愿意折腾这类玩意的人都不在乎多点几下在各种软件里填东西，毕竟填空也就是偶尔几次

只会或者只愿意通过分享使用的用户，你最好不要分享给他，免得他“不知情”的情况下干出什么事，自己惹得一身*

from xray-core.

一直都觉得，愿意折腾这类玩意的人都不在乎多点几下在各种软件里填东西，毕竟填空也就是偶尔几次

只会或者只愿意通过分享使用的用户，你最好不要分享给他，免得他“不知情”的情况下干出什么事，自己惹得一身*

分享链接的意义在于快速分发大量节点

至于主要使用环境

我猜你已经猜到了

):

from xray-core.

一直都觉得，愿意折腾这类玩意的人都不在乎多点几下在各种软件里填东西，毕竟填空也就是偶尔几次
只会或者只愿意通过分享使用的用户，你最好不要分享给他，免得他“不知情”的情况下干出什么事，自己惹得一身*

分享链接的意义在于快速分发大量节点
至于主要使用环境
我猜你已经猜到了
):

现在处于腹泻式更新阶段，如果下一个小版本改动了一些东西，你的所有链接也全都要改，机场这种万年不动服务端的产业现在还没准备好接受这种天天改动的内核，等稳定了再说

对于分享链接 ，我觉得可以“做加法”，未指明的配置，使用默认

这样，拉稀式更新对分享链接的影响应该很小

from xray-core.

看到楼上这么整齐一致的声音，发表一下不同的看法。
我们开发、使用翻墙软墙的初心，从来不是为了过来听整齐一致的声音。
也希望Xray/V2Ray分家后，能看到Xray有更开放包容的氛围,而不是这等小事上试图增强控制权。

首先，分享链接的解析和变动成本是最小的，VLESS需要的常用参数本来就没几个。
你说的flow将来会去掉，flow去掉对分享链接根本没有任何影响，URL本来就可以兼容或忽略旧版参数。
你再怎么变动会不需要主机名、端口、UUID这些基本的东西？！而且在V2ray之前的文档里已经写了，VLESS的参数未来不会有大的变动，只会做加法，包括flow也只是保持可填空不要做成下拉 - 这种东西是不是本就应该按文档写的去做？！

至于“腹泻式更新”更加说明了分享链接的必要性。
例如将来会去掉 flow，那么界面上的flow就要改，界面上的改动是最麻烦的，给最终小白用户的体验是最不好的。
配置格式的不兼容改动，最痛苦的是界面上的兼容。考虑到这种问题，更应该使用分享链接。

其实 vless 压根不需要刻意指定分享标准，因为URL已经有一套成熟的标准，
还有用一下分享链接，就变成了被鄙视的“小白”？！你自己真的从来没有复制过分享链接？！
不让机场使用 - 就直接在许可里写一下不让他们用，即然让他们用了，机场给一个复杂的JSON还比给一个简单的分享链接有更好的向下兼容性？！

from xray-core.

@mrcas1

我认为第一段有几处不恰当

我们开发、使用翻墙软墙的初心，从来不是为了过来听整齐一致的声音。

与这里的场景无关。

也希望Xray/V2Ray分家后，能看到Xray有更开放包容的氛围,而不是这等小事上试图增强控制权。

分享链接不是小事。这与“开放包容”更不冲突，可以去看下 Project X 的群聊。
而且这件事好像与是否 Xray 没有关联吧，我的角度是 VLESS 的作者。

分享链接作为一个规范，最好的结果当然是遵循同一个标准，而不是每个软件的支持程度不同，VMess 已经是比较混乱的状态了，VLESS 不能再发生这种情况。为什么部分人急于让一个未最终定稿的协议推出分享链接？一旦广泛使用，这个协议就没有发展前途了，或者只有 breaking，对已有生态造成巨大破坏。使用者和开发者的出发点自然不一样，使用者希望当下方便，可能并不关心协议的长久发展与规范，而开发者希望更长久、规范，若只顾一时方便，最终只会毁了协议，从头再来。

另外，v2 关于 VLESS 的文档被他们擅自改动过，有些地方已经脱离本意，我还没去修。
比如很多加粗没有了，又有人开始回落到 https；删掉了关于分享链接的说明，一些客户端开始自造分享链接。

from xray-core.

这里倒不是“开放包容”的问题，对于一个规范，基本共识是一致，否则也不需要有那么多标准化组织了，不需要 IETF 了。

所以我一直认为脱离这里的实际大谈“开放包容”是很不合适的，也经不起推敲，因为会推导出很奇怪的结果。

from xray-core.

标准化 - 不等于没空标准化，你们也不许用，谢谢。
正因为 “分享链接=图形化界面” , 所以如果说分享链接会毁了协议，界面也更加会毁了协议，因为改动更大。

from xray-core.

@mrcas1

VLESS 正式版会有很大改动，指令会变为五个，XTLS 很可能会融合成一个指令，这种情况下真的不适合现在就推出分享链接。

对于 UUID，目前的想法是增加支持自定义密码 hash。

分享链接本应和正式版一起推出，请不要强行打乱开发者的节奏，谢谢。

from xray-core.

您上面列举的这些变更，分享链接应当不需要改动，
例如支持自定义密码hash，只是增加一个可选URL参数，动不到分享链接标准。

倒是没有分享链接，只能跟着改界面，这会很痛苦，目前看到各客户端似乎就在兼容的阵痛中。
至于你说的兼容问题，这是客户端和核心的问题，分享链接背这锅太冤了。

当然怎么做是您的自由。
但是要限制客户端不搞出各种格式的链接感觉还是有些难 - 毕竟别人制定一套http协议出来那也很难阻止他。

from xray-core.

这种如果限制的话，建议写在新版的许可条款里，不然文档是空的 - 也没有约束力。
例如你不使用Xray官方制定的分享链接标准，那就不允许使用新版Xray Core。
要么你支持官方的分享链接标准，要么就保持你的Xray Core不再升级。
那么这个问题就可以解决了。

from xray-core.

嗯，我不是年轻人，我也没有什么好急的。

说来说去还是要保留所有的控制权，你说的这些机场兼容 - 不用分享链接只会更严重，不用分享链接 - 他一样会发布不兼容的JSON，除了操作比分享链接麻烦一些，没看到任何区别。

好吧我不急，再等几年再过来用吧，如果那时候VLESS还能挺住的话。

from xray-core.

我很好奇，我何时何地说过不讨论就制定规则？！
还有什么东西需要改来改去，就算VMESS不兼容的链接出来很多年了 - 影响到V2Ray前进了？！

而且你前面说了很多担心机扬不兼容会毁掉VLESS，
后面又说你已经预见到了机场其实根本不会碰VLESS分享链接。
感觉您讨论问题的方式很魔幻。

总之您都对，即然容不下不同声音，那就再见吧。

from xray-core.

标准化 和 “开放包容”没有直接关系。

“走出一道墙进入另一道墙”，这都是一些什么奇怪的帽子？
先带帽子，再行辩论？

要开放包容不等于不需要标准化。
这是心态和技术两个不同视角的东西。

不要混淆两个不同视角概念，从而似乎站在道德高地，然后企图进行道德压制的辩论。
把两个相近概念混淆,让围观吃瓜群众不易看清,然后制造自己的有利点进行辩论是一种常用手法,然而这种辩论模式在这个环境行不通。

from xray-core.

标准不标准化,何时标准化,就是一个技术角度,以及软件开发节奏(计划)的考量.
作者认为从现在的开发阶段和后续的开发计划的角度,甚至包括生态环境,市场用量等等技术层面的考量来看,还不是最适合定稿标准的时候,那就不是.

请收起您给别人带的帽子.(主要指最开始的几处回复,开篇什么具体内容都还没有谈,就先基于自己猜测或讲一些看似大义其实无关的话进行导向,通过扣帽子企图占领辩论高地)

from xray-core.

@mrcas1
1.如果特别希望一个东西快点出现并且变好，又觉得好实现，为什么不自己也加入进来呢？
2.我要用，我说，你做，你没马上做，那就是你就有问题，呵呵....... 作者和工具本身没有从你身上搜刮利益，没人欠你的，那么请少哔哔。

3.说个题外话，愿意在网络上发这么多字，是不是现实中挺寂寞的？那就关注一下自己的性格问题吧

from xray-core.

@shenlijun
讨论技术问题只是出于对项目的关心，我并没有对作者提任何要求，请不要一再进行人身攻击。
另外你哪只眼睛看到我没有参与贡献？！还有我哪句话说了作者欠我的？！

@SekiBetu
我只是提出了一种方案和设想 - 并没有要求你接受，
你这就给扣个帽子“不经讨论就制定规则”？！你在哪里看到我制定了什么规则？！

这么强硬的风格，说实话，就是想贡献也害怕了，簌簌发抖中。
我都说了你说的都对，不制定就不制定，不让用就不用，怎么还想搞批斗大会？！笑话！！！

from xray-core.

性格这么冲动，谁还敢跟你讨论。

from xray-core.

我认为这个 issue 的本意没有问题，但后面的回复有偏离主题的倾向，这部分争论的确没有太大意义。

对于标准化分享链接，推出后会加速协议的传播，此时再改动标准的成本是极高的，所以决定正式版再推出，希望能够理解。

from xray-core.

性格这么冲动，谁还敢跟你讨论。

从你的第一个回复里我看不到你的主观意愿，你的文字表达的情感色彩就是批评，连用那么多问号叹号，起手扣帽子阴阳怪气的人我不认为是来好好谈问题的，多用用谦虚的语言、直白阐述你的想法、提出建设性意见、接受他人观点，这样会让你少受攻击甚至是0攻击，你的观点也是没有任何意义，大家都在最前线马不停蹄地推进分享链接，不存在你说的拖延问题，更多的是技术问题，你如果解决了XTLS现有的大多数问题和目前规划好的新功能的开发，那么分享链接今天就能出来

我在上面提出了一个例子

比如说现在服务端只有direct，但是是自适应的splice，只有客户端开启splice服务端才会使用，这种情况你的分享链接该如何修改，而且windows上没有splice，如果默认分发direct，那么linux和安卓端明显失去了一个特性，机场必须做两套分发系统，如果未来windows的零拷贝技术也被开发加入Xray，那么还要再提供一套windows的transmit流选项的分发系统，最后如果做完后发现这个选项被删除了，变为内核自适应流规则，那么他们的分发系统又要修改

如果你是真想推进分享链接标准的制定的话，你应该很轻易地想到这个问题，因为假设现在已经有了分享链接的标准，那么这是作为一个机场主第一件要干的事，他要决定如何分发分享链接，这三个流只有服务端配置是一样的，而客户端有三套规则，从机场主来说需要提供额外的技术来分别发放链接，但是作为XTLS的开发者，我们可以将其全部作为内核级别的自适应，这样规则里就不用加这种内容了，但是开发者又不能完全确定还没开发的windows的零拷贝技术是否可以融入现有的框架，甚至不能确定能不能用，一切都需要时间(origin和direct是可以合并的，也在开发中，所以这里不谈了)

原本不想提的，因为我觉得对于翻墙的人来说这是一件很正常的事，但是对于你的发言，我觉得很有必要提出来：
你的账号几小时前刚注册的，能换个大号来嘛，结合你的发言，我在此提出合理的怀疑你是专门为黑来黑的

from xray-core.

@shenlijun
讨论技术问题只是出于对项目的关心，我并没有对作者提任何要求，请不要一再进行人身攻击。
另外你哪只眼睛看到我没有参与贡献？！还有我哪句话说了作者欠我的？！

@SekiBetu
我只是提出了一种方案和设想 - 并没有要求你接受，
你这就给扣个帽子“不经讨论就制定规则”？！你在哪里看到我制定了什么规则？！

这么强硬的风格，说实话，就是想贡献也害怕了，簌簌发抖中。
我都说了你说的都对，不制定就不制定，不让用就不用，怎么还想搞批斗大会？！笑话！！！

讨论对于标准化分享链接本来是一件好事,是从你开始主观臆测,以及混淆态度和技术两个角度的概念,并且说了一些看似大义其实无关主题的话(扣帽子)的.
并且,那么多的"？！","!!!",也代表了你说话语气的强烈感情色彩.

另外,说你给别人扣帽子的是我,请不要迁怒别人.

鉴于rprx已经关闭此贴,这个回复是我最后一个回复.

from xray-core.

@shenlijun
讨论技术问题只是出于对项目的关心，我并没有对作者提任何要求，请不要一再进行人身攻击。
另外你哪只眼睛看到我没有参与贡献？！还有我哪句话说了作者欠我的？！

@SekiBetu
我只是提出了一种方案和设想 - 并没有要求你接受，
你这就给扣个帽子“不经讨论就制定规则”？！你在哪里看到我制定了什么规则？！

这么强硬的风格，说实话，就是想贡献也害怕了，簌簌发抖中。
我都说了你说的都对，不制定就不制定，不让用就不用，怎么还想搞批斗大会？！笑话！！！

仅仅这么个小天地里，几乎所有人都和你的意见不一样，难道不应该先反思下原因？然而到头来却是装可怜以退为进。

这就是性格问题，连你自己都回避现实中寂寞的问题了

from xray-core.