domain-list-community
domain-list-community copied to clipboard
v2fly
关于 @attr 的语法扩展
我在 issues #28 中提出了基于多种 attr 共存的想法。 现在过了一段时间，我认为从讨论结果上看，社区整体对多种 attr 共存的方案接受程度比较高，我们基本上可以达成共识。
同时为了更好的实践多重属性的方案，include语法势必要进行扩展。
如同 issues #256 中提到的语法扩展方案。
只不过我个人认为 include:filename@attribute 这样的语法还是略有不足。
我个人认为改为 include:filename @attribute1 @attribute2 这样的形式会更加灵活，也更简单。
那么为了实践多重属性的方案，我在这里想重新归纳整理一下对于 @attr 语法的改变，同时我会提出 PR 来实践。
- 支持为一个域名设置多种属性 （目前 master 分支已经支持） 例如：
domain:google.com @attr1 @attr2
- include的语法扩展。 语法：
# 包含 filename 中的所有条目（与目前的语法一致）
include:filename
# 代表包含 filename 中含有 @attribute1 和 @attribute2 这两种属性的条目。
include:filename @attribute1 @attribute2
# 代表包含 filename 中不含 attribute1 属性的条目和包含 attribute2 属性的条目
include:filename @!attribute1 @attribute2
这样做的好处是我们可以针对为不同国家同时提供服务的企业实现最合适的访问路径，并且更易于后续的管理。 举个例子：
# filename hsbc
hsbc.com
hsbc.com.hk @hk
hsbc.com.cn @cn
hsbc.co.uk @uk
# geolocation-cn file
include:hsbc @cn
# geolocation-!cn file
include:hsbc @!cn
我个人觉得这样的写法更符合人类认知，也更好操作。
- 规范化属性标签
关于属性标签的问题，我这里参考 Loyalsoldier 的建议，同时也是作为一个规范。 我们可以把属性规范为2类。
3.1. 传统的地域属性 按照企业或网站所在地区来进行分类。
比如：
中国企业为中国用户提供服务的使用@cn。
中国企业的美国分支机构，只为美国提供服务的可使用@us。
美国企业为美国用户提供服务的使用@us。
美国企业专为中国用户提供服务的使用@cn。
接受所有国家代码（2字母小写）作为属性，同时为了方便以及兼容性也接受不写该属性。 这样无论任何域名都可以按照此方法来分类，并且现有的数据无需更改可以继续使用。
如果按照规范实施的话，最后的成果可能会变成这样。
amazon.com
163.com @cn
github.com @us
samsung.com @kr
rakuten.co.jp @jp
注1：此外对于域名条目中@!cn这样的语法为了兼容性予以保留，等待后续修改。
注2：除国家代码以外的所有2字母组合均定义为保留字。
3.2. 增加如下使用属性
# anycast 代表具有多国接入点
@anycast
# gfw 代表被 GFW 污染
@gfw
# ads 代表该域名被用于展示广告
@ads
按照这几条来实施的话，我个人认为对于目前的版本来说是易于实施的，并且不会导致不兼容的情况。
以上是我对 @attr 语法的一些想法，欢迎大家来讨论。
个人认为本提议在以下几种情况下还欠考虑：
- 如何处理「需要 include 同时具备某几个属性的规则」的情况？
- 似乎「每新建一个文件，都需要同时往
geolocation-cn和geolocation-!cn里写入include」比较啰嗦，是否有更方便的方式？（如果要改，就往简单的方向改）
- 如何处理「需要 include 同时具备某几个属性的规则」的情况？
没看懂你这句话，你是指在某种场景下这种语法补充可能导致问题吗？如果说是具体实现，我觉得不难。
- 似乎「每新建一个文件，都需要同时往
geolocation-cn和geolocation-!cn里写入include」比较啰嗦，是否有更方便的方式？（如果要改，就往简单的方向改）
这个问题应该超出了这个 issue 提议的范围，是不是可以另开一个 issue 讨论？
没看懂你这句话，你是指在某种场景下这种语法补充可能导致问题吗？如果说是具体实现，我觉得不难。
我的意思是，对于下面这种情况：
a.tld @gfw
b.tld @anycast
c.tld @gfw @anycast
d.tld @us
如果我只想 include c.tld 和 d.tld，上面的提议并没有覆盖这种情况。
个人认为可以这样：
include:filename @gfw@anycast(空格)@us
或者
include:filename @gfw@anycast(空格)@!cn
@Loyalsoldier
如何处理「需要 include 同时具备某几个属性的规则」的情况？ 这个应该是涉及到实现的问题，目前我给出的 PR 里是每一种属性单独展开处理的。
# 比如主贴里面举的 HSBC 的例子
include:hsbc @cn @hk
# 这样一个include指令会展开成类似于
include:hsbc@cn
include:hsbc@hk
# 通过这样两个指令来同时引入具备 cn 和 hk 的条目。
# 如果重复引用同一个文件的同一个属性，代码会跳过防止重复引用。
# 如果同时引用多种属性展开后产生的重复条目，我的PR本身是没有处理的，这个可能需要另外再优化。
更直白的说：其实是以下这种语法的语法糖。
include:filename@attribute
似乎「每新建一个文件，都需要同时往 geolocation-cn 和 geolocation-!cn 里写入 include」比较啰嗦，是否有更方便的方式？（如果要改，就往简单的方向改）
以我个人的观点来看，我觉得是不用每次添加都必须同时添加到 geolocation-cn 和 geolocation-!cn。
因为普通的网站或者企业不会同时为很多个国家提供服务，只有跨国企业才有这样的情况，所以我们不需要给所有的域名都加上@cn或者其他国家代码的属性。
尽管强制添加地域属性会更加有利于在全世界范围来生成路由，但是考虑目前的人力情况，我们还是以cn地区为主要目标。
我的建议是：对于中小型的cn网站，和以前一样写明然后普通的 include 即可。
没看懂你这句话，你是指在某种场景下这种语法补充可能导致问题吗？如果说是具体实现，我觉得不难。
我的意思是，对于下面这种情况：
a.tld @gfw b.tld @anycast c.tld @gfw @anycast d.tld @us如果我只想 include
c.tld和d.tld，上面的提议并没有覆盖这种情况。个人认为可以这样：
include:filename@gfw@anycast(空格)@us 或者 include:filename@gfw@anycast(空格)@!cn
这种情况我觉得最好是从源头上来避免发生，不然可能就得考虑是不是得为include语法加上运算符支持了。
如果不想通过运算符来处理，我可能会选择改成这样
a.tld @gfw
b.tld @anycast
c.tld @gfw @anycast @temp
d.tld @us @temp
引用的时候直接include:filename @temp
因为对属性的数量和名称其实是没有硬性要求，事实上我们可以任意给我们想要的组合取任何名字。
只不过为了维护性的考虑，我加上了规范性的标签列表来参考。
如果有需要的话，或许我们也可以给规范列表里面增加一些临时组合的标准？ 比如：以下划线开头的属性作为为临时组合标签。
以我个人的观点来看，我觉得是不用每次添加都必须同时添加到 geolocation-cn 和 geolocation-!cn。 因为普通的网站或者企业不会同时为很多个国家提供服务，只有跨国企业才有这样的情况，所以我们不需要给所有的域名都加上@cn 或者其他国家代码的属性。
对于列表维护，其实最方便的处理方式就是类似 PR #256 直接在 geolocation-cn 中 include:geolocation-!cn @cn 和在 geolocation-!cn 中 include: geolocation-cn @!cn。当然，目前的代码结构无法做到这个功能，需要完全重构。
由于 PR #391 和本提议中对于 @!cn 看作是 attribute 取反，而不是完整的 attribute 名称，如果要实现上面这种“方便”的列表维护方式，需要处理「没有任何 attribute 的域名到底要不要 include 」的问题。
以我个人的观点来看，我觉得是不用每次添加都必须同时添加到 geolocation-cn 和 geolocation-!cn。 因为普通的网站或者企业不会同时为很多个国家提供服务，只有跨国企业才有这样的情况，所以我们不需要给所有的域名都加上@cn 或者其他国家代码的属性。
对于列表维护，其实最方便的处理方式就是类似 PR #256 直接在
geolocation-cn中include:geolocation-!cn @cn和在geolocation-!cn中include: geolocation-cn @!cn。当然，目前的代码结构无法做到这个功能，需要完全重构。由于 PR #391 和本提议中对于
@!cn看作是 attribute 取反，而不是完整的 attribute 名称，如果要实现上面这种“方便”的列表维护方式，需要处理「没有任何 attribute 的域名到底要不要 include 」的问题。
列表维护的问题我个人是倾向于暂时不要做太大的改变，不然牵涉到的问题可能就太多了。
目前在 PR #391 中的处理方式是：
除非明确包含@cn属性，否则就属于@!cn。
也就是说如果没有任何 attribute 也会包含在比如@!cn这样的属性中。
这种处理方法应该是符合取反这种语义的。
如果说想针对性的处理没有任何 attribute 的条目，我觉得可以考虑增加默认属性。 比如没有填写任何属性的条目默认具有一个 default 属性这样来处理，这样做可能对数据的变动是最小的。
个人觉得目前的文件分布较为分散，应做相应改进
Directory: .\domain-list-community-enhanced
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2021/1/8 8:35 domain-list
-a--- 2021/1/7 14:43 66 .gitattributes
-a--- 2021/1/7 14:48 293 .gitignore
-a--- 2021/1/7 0:43 231 go.mod
-a--- 2021/1/7 0:43 32845 go.sum
-a--- 2021/1/7 14:51 1067 LICENSE
-a--- 2021/1/8 10:30 19834 main.go
-a--- 2021/1/7 16:31 2498 README.md
Directory: .\domain-list-community-enhanced\domain-list
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2021/1/8 8:35 data
-a--- 2021/1/8 10:27 540 list-cn
...
-a--- 2021/1/8 10:27 56 list-github
Directory: .\domain-list-community-enhanced\domain-list\data
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2021/1/7 10:54 105 0
...
-a--- 2021/1/7 10:54 2338 z
cat .\domain-list\list-cn
# all 读取data目录下的所有文件
include:all @cn
cat .\domain-list\list-github
include:g @github
把源数据放到data目录下，data下的数据不生成到dat文件，仅生成domain-list下文件引用的数据到dat文件中。
几点建议，与大家讨论： 1. 首先，我觉得应该承认，这个列表大部分使用者是大陆用户，还有部分伊朗等国家，主要是为了突破本地的网络封锁使用。可能会有些海外华人用于回国节点看视频，但是他们大部分都是看的时候开代理，看完了关代理。 做列表，应该从用户实际使用的角度出发。当然也需要考虑利于维护的问题。 2. 因此，目前的category结构，其实主要有利于开发者进行维护，对于用户的实际使用，作用并不大。绝大多数用户是直接geosite:cn, geolocation-!cn这样用的。很多用户都是小白，连设置都不会，都是使用app/模板/脚本预设的规则。 我能想到对于用户category的有用情景，大概就是类似于大陆用户需要访问在大陆和境外都有接入点的境外接入点的公司，比如玩外服游戏。这个需求其实比较小众，但是总归是category结构在面对用户时有用的一个案例。用户实际使用中可以开两个本地代理端口，各使用不同规则，玩游戏的和不玩游戏的。 3. 3.(1) 从这个角度看，我认为@attr应该按照特定地域用户能否连接这个域名、能否快速稳定的连接访问为基础分类。以大陆用户访问A域名举例：能够在大陆地区快速稳定访问A域名的，设一个@attr，如@cn-L1；能稳定访问，但因接入点在境外，并且CDN较差，导致实际访问速度慢的，设@cn-L2；不能稳定访问，时灵时不灵，根据用户需求，不设@attr或设@cn-L3。其他的国家，比如伊朗，也是一样，比如@ir-L1, @ir-L2。对于在全世界都有接入点的，可以用前面提到的anycast的思路，设@all-L1, @all-L2. 3.(2) 在给终端用户的编译/打包的文件（.dat）里面，应该是选择L2自动包含L1，选择L3自动包含L2、L1，选择all自动包含cn、ir这样的。如果把某个category标记某@attr，那么该category下的所有域名都应该自动具有该@attr。 3.(3) 我举例几个使用场景，是需要/适合这种方式的。比如OneDrive，网页版国内不能访问，但是手机app和电脑端的windows自带同步软件则可以访问，而且有时候可能会有大流量的上传下载。那么多数用户，会希望访问网页OneDrive走代理，访问应用/软件的域名走直连。对于少部分需求特殊的用户，也可以自己加一个geosite:onedrive@cn-L3走代理的规则。还有像大陆用户玩暴雪的外服游戏，访问网页下载客户端都希望走境外接入，但是下载游戏的数据流量则希望走暴雪大陆境内的接入点，既快速又节省代理流量。还有下载windows update，ios里面itunes music/movie等。 3.(4) 那么，对于绝大多数大陆小白而言，设置规则也更简单了：无非是geosite:all@cn-L1或geosite:all@cn-L2。 4. 利用多@attr的体系，让各个国家需要此列表的网友自发为列表提交更新。不要想着几个开发者就把所有的事情搞定。“@cn能不能服务这群人，是不是不能服务那群人”的问题，也就差不多解决了。 5. 这样的话，目前的编辑/架构方式，是不是需要改一改？我提一个思路：数据采用数据库的方式存放，外部接一个webhost，用于提交、审核修改。相当于，category是一个分类的（树状）维度，@attr是一个维度体系，内涵可交叉的多（树状）维度。多维度并存，可能还是数据库的方式更好一些？实际上，一个特定的用户选择，就是geosite: category:aaa + attr:bbb。
其实主要有利于开发者进行维护，对于用户的实际使用，作用并不大。绝大多数用户是直接geosite:cn, geolocation-!cn这样用的。很多用户都是小白，连设置都不会，都是使用app/模板/脚本预设的规则。
关于前半句话我并不同意。直接 geosite:cn, geolocation-!cn 这样用就是预期内的用法，并没有错误
我认为@attr应该按照特定地域用户能否连接这个域名、能否快速稳定的连接访问为基础分类。以大陆用户访问A域名举例：能够在大陆地区快速稳定访问A域名的，设一个@attr，如@cn-L1；能稳定访问，但因接入点在境外，并且CDN较差，导致实际访问速度慢的，设@cn-L2；不能稳定访问，时灵时不灵，根据用户需求，不设@attr或设@cn-L3。其他的国家，比如伊朗，也是一样，比如@ir-L1, @ir-L2。对于在全世界都有接入点的，可以用前面提到的anycast的思路，设@all-L1, @all-L2.
attr 本身算是用户根据个人需要对项目的衍生。怎么设计 attr 是没有绝对的规范的。你的设想没有问题。 但是从本项目维护的角度出发，这么多的 attr，没有量化的标准能够确定一个域名应该给什么 attr，而且给出的属性只能反映维护者个人的网络环境，并不适合做到这个项目里。前半部分导致维护成本高得离谱，难以落实；后半部分直接违背了这个项目的内容应该适合所有人使用的原则。所以我十分不建议在这个项目里这样做，你可以在自己 fork 的项目里这么做。
让各个国家需要此列表的网友自发为列表提交更新。不要想着几个开发者就把所有的事情搞定
本身这个项目也是接受任何人为列表提交更新的。开发者的工作不体现在列表维护上，在于生成各类型数据库的代码维护上。你的理解有误。 假设你后半句话指的是维护者，那么维护者的工作在于把关，确保每个共享者的提交都符合这个项目的维护原则，不能每个人都按照自己的理解和对自己方便的样子来改。
目前的编辑/架构方式，是不是需要改一改？我提一个思路：数据采用数据库的方式存放，外部接一个webhost，用于提交、审核修改。相当于，category是一个分类的（树状）维度，@attr是一个维度体系，内涵可交叉的多（树状）维度。多维度并存，可能还是数据库的方式更好一些？
考虑你这个想法落实起来的工作量，可能在这个项目上做修改还不如直接开新的项目。 我不评价你这个思路的好坏，因为只有做了才知道。但是我建议你先多从更新列表的贡献做起，加深对这个项目的了解。等积累一定的经验以后再重新构思这个项目应该如何改进。
这么多的 attr，没有量化的标准能够确定一个域名应该给什么 attr，而且给出的属性只能反映维护者个人的网络环境，并不适合做到这个项目里。前半部分导致维护成本高得离谱，难以落实；后半部分直接违背了这个项目的内容应该适合所有人使用的原则。
本身这个项目也是接受任何人为列表提交更新的。开发者的工作不体现在列表维护上，在于生成各类型数据库的代码维护上。你的理解有误。 假设你后半句话指的是维护者，那么维护者的工作在于把关，确保每个共享者的提交都符合这个项目的维护原则，不能每个人都按照自己的理解和对自己方便的样子来改。
考虑你这个想法落实起来的工作量，可能在这个项目上做修改还不如直接开新的项目。 我不评价你这个思路的好坏，因为只有做了才知道。但是我建议你先多从更新列表的贡献做起，加深对这个项目的了解。等积累一定的经验以后再重新构思这个项目应该如何改进。
是的，开发者和维护者应该被分为两个群体；开发者做架构，维护者做内容维护，这样思路就清晰了。 我提出的其实主要就是关于“应该适合所有人使用的原则”这个问题。这方面，我认为应该从用户需求、群体、需求群体出发，去考虑和设计。要看现实中哪些用户在用。做一个项目，一个功能，一种架构思路，没有真正的用户在用，那就没意义。从用户的角度出发，事情就简单了：有一批大陆需要翻墙的用户；有一批伊朗要翻墙的用户；有一批要使用境外企业服务、玩外服游戏的用户；有一批境外想要看大陆视频的用户。可能还有一些需求群体。那么除了这个列表的需求群体，可以说就没有人再去使用这个列表了，也因此没必要为更宽广的使用场景设计列表结构。 关于attr的标准，以及“只能反映维护者个人的网络环境”，我不同意你的看法。我的想法是，按照用户群体，由用户自发进行维护。把维护分成审核和提交（其实现在就是）。维护群组可以采取树状结构，上层级对应更广的地域/领域，具备更多的审核权限，下级的群组更具体，比如专门维护海外用户访问大陆视频。那么大陆用户的维护审核群组很容易去判断，哪个域名在大陆有接入点，应该作为cn-L1，哪个外部有接入点、并且大陆用户愿意去直连，作为cn-L2，哪个能直连，但代理更快，作为cn-L3。上层级的审核维护也许难以为全部人做出好规则，但是可以有下层级的审核维护群组代表更具体的用户群，做出的维护就能更好。 从这个思路延展，甚至可以发展出“适合河南移动直连的域名”之类的细分类别----是否发展出，就可以全凭用户是否有需求，进而是否有人愿意主动去维护来决定了。开发者更省心，上层级的审核维护也更省心。从这个角度讲，其实也“适合所有人了”：有需求的用户按需求群组自发贡献规则；没有需求、不需要使用这个列表的，自然也不用去管。 从这个角度讲，可能确实新开一个项目更合适；但是这里我想是与大家讨论。是否去做、是否开新项目这些，想好了考虑周全了再行动。
是的，开发者和维护者应该被分为两个群体；开发者做架构，维护者做内容维护，这样思路就清晰了。 我提出的其实主要就是关于“应该适合所有人使用的原则”这个问题。这方面，我认为应该从用户需求、群体、需求群体出发，去考虑和设计。要看现实中哪些用户在用。做一个项目，一个功能，一种架构思路，没有真正的用户在用，那就没意义。从用户的角度出发，事情就简单了：有一批大陆需要翻墙的用户；有一批伊朗要翻墙的用户；有一批要使用境外企业服务、玩外服游戏的用户；有一批境外想要看大陆视频的用户。可能还有一些需求群体。那么除了这个列表的需求群体，可以说就没有人再去使用这个列表了，也因此没必要为更宽广的使用场景设计列表结构。 关于attr的标准，以及“只能反映维护者个人的网络环境”，我不同意你的看法。我的想法是，按照用户群体，由用户自发进行维护。把维护分成审核和提交（其实现在就是）。维护群组可以采取树状结构，上层级对应更广的地域/领域，具备更多的审核权限，下级的群组更具体，比如专门维护海外用户访问大陆视频。那么大陆用户的维护审核群组很容易去判断，哪个域名在大陆有接入点，应该作为cn-L1，哪个外部有接入点、并且大陆用户愿意去直连，作为cn-L2，哪个能直连，但代理更快，作为cn-L3。上层级的审核维护也许难以为全部人做出好规则，但是可以有下层级的审核维护群组代表更具体的用户群，做出的维护就能更好。 从这个思路延展，甚至可以发展出“适合河南移动直连的域名”之类的细分类别----是否发展出，就可以全凭用户是否有需求，进而是否有人愿意主动去维护来决定了。开发者更省心，上层级的审核维护也更省心。从这个角度讲，其实也“适合所有人了”：有需求的用户按需求群组自发贡献规则；没有需求、不需要使用这个列表的，自然也不用去管。 从这个角度讲，可能确实新开一个项目更合适；但是这里我想是与大家讨论。是否去做、是否开新项目这些，想好了考虑周全了再行动。
我们还是没聊到一个频道上。而且我很久没在看母语写的文章时看得这么辛苦了。 我觉得我之前的说明已经很明确了，所以我不会再补充别的废话。我只写一下我觉得你接下来可以采取的行动，你可以作为参考。觉得没道理的话，也可以不用照着做。 但是我把我会采取的行动讲在前面，免得你浪费时间。
- 解决你提议的 xx-Ln 属性没有量化标准的问题，确保任何人遵照这个规则都能给出一致的属性标注
- 落实你的想法。如果你现在就在这个项目上做类似的事情，我会直接关闭相关的 issue 或者 pr。你可以先自己 fork 一个项目实践你的想法，如果我觉得新的项目完善得足够好了，我会来求你把你的成果 backport 回来。
谢谢你为这个项目付出的时间和思考。
谢谢回复。这种改动肯定不适合在这个项目上直接PR，那就变成瞎搞了。
- 解决你提议的 xx-Ln 属性没有量化标准的问题，确保任何人遵照这个规则都能给出一致的属性标注
唉我觉得用户的问题用户自己解决，群组内部自己定标准也好投票决定也好。想办法把这个问题推给用户。一个群组/层级内部需求不统一，就让群组管理主持再细分。
- 落实你的想法。如果你现在就在这个项目上做类似的事情，我会直接关闭相关的 issue 或者 pr。你可以先自己 fork 一个项目实践你的想法，如果我觉得新的项目完善得足够好了，我会来求你把你的成果 backport 回来。
嗯，还再考虑考虑。思路是否靠谱，能否行得通，需要付出多少时间精力，能出多少成果等等。反正太阳每天升起，现在这样大家也都挺好，不急。