【提案】关于增加 RelMeAuth 特性

[Linklinkguan]

建议matataki生成的相关网站链接加上rel=“me” 这个属性。是一种叫做RelMeAuth的通行做法，用于证明不同平台上的同一身份。用之前示例的blog测试了一下，在mastodon上可以变成绿勾认证。 在个人信息里可以维护相关站点的链接，而这些链接会在个人信息页作为可点击的超链接显示 related websites 。这些链接在前端就是a标签，希望能够给这些链接加上RelMe

https://whyouare111.github.io/hexo-plugin-matataki-showcase/ 这个是我之前做的示例Blog，我在这里加上了隐藏的示例链接 指向了我在github上的个人主页。而我在github上也有维护website指向了这个Blog 。
github上这个链接的标签是 https://whyouare111.github.io/hexo-plugin-matataki-showcase/</ a> 两边的标签都有rel="me" 这部分

关于 RelMeAuth http://microformats.org/wiki/RelMeAuth

link要是双向的，另一边也要维护上。比如我在Mastodon上和Blog上都维护了指向对面的链接，两边也都有https的情况下，两边账号的皮下是同一个人的可信度应该相当高了。Mastodon这个打勾机制应该是解析这个链接里的html/DOM，发现里面有指向该用户个人页的链接，且rel属性包括me，就认证通过

比如一个恶意用户维护一个指向某大V的页面冒充自己是TA的话，那个大V的页面上理应是不会有一个回链指向这个恶意用户的首页的。markdown生成超链接不会有rel="me"的属性，就不会把其他超链接误认成声明“这个链接里的信息也是我的”的链接，比如用超链接挂人，不用担心被反过来当成双向链接

内容来自于：@whyyouare

[Linklinkguan]

社区的志愿者 或 仙女座科技的开发者 有对该提案感兴趣的请在下方留言参与讨论。
对提案表示赞成可以在上方的描述框中增加一个“小火箭”图标，表示投票。

[nekomeowww]

这里想提出一个问题，无论是 Mastodon 还是 RelMeAuth wiki 中提到的 Twitter，抛开 HTML/DOM 容易被篡改的特性，Twitter/Mastodon 都只支持一个个人页面的定义。
也就是说，只有一个网站首先支持了多个网页指向，并且会愿意为你添加 rel="me" 的时候才会有效，这个问题在 Matataki 上不存在，但是对于很多人而言，在 Twitter，Mastodon，Matataki 更愿意对接一个基于 WordPress（因为很热门）或者是 About Me 一样的链接，这个时候栏位就不够用了。

1. 这里依然不能避免 HTML/DOM 在 HTTP 层面更容易被篡改的可能性。
2. 还要考虑部分 npm 包引发的 CVE 安全漏洞问题。

那么为什么不参考一下 KeyBase 在这方面的验证机制呢？
（该机制的一部分也被用于 Matataki Auth + Mastodon 验证）
或者说，对于用户而言，是不是公私钥更有可信度呢？

[whyouare111]

是的，这个页面我想是更适合配合带独立域名的个人Blog使用。比如Github就只能配置一个连接，如果用这个方式，最优选一个能有多个网页指向的地方，比如自建博客。而对于没有个人博客的，指向Matataki这样能维护多个页面的不失为一个选择。
如果构造以个人博客为中心的双向链接
Mastodon<=>WordPress<=>Matataki, 理论上从任一个点出发逐层找下去是能把所有双向链接的都找到吧 ，俯视看来支持多个网页指向的站点（如个人博客，Matataki）因为更容易有多条边和其相连，某种意义上是在这种模式下成为中心了。
提议Matataki加上rel=“me”也是觉得连到Matataki后就能用Fan票做些什么，在好些场景这个路径足够短，作为一些平台的直接链接还挺方便的，比如Mastodon直接连过来，可能有助于引导对时间线上看到的优质资源打赏，这种情况下证明Mastodon上维护的Matataki链接是可信的就变得有需要了

而按Mastodon的说明

我想Matataki这边如果带上了 rel="me" 应该就能变绿了，这就是初衷了，而这个机制不需要定制Mastodon都支持

安全性方面的疑虑无法否定，这个肯定比不上公私钥。用了这个就觉得绝对可信，平台方面确实不适合给出这个保障。
能用上公私钥是很好的，剩下的就是门槛问题。
如果说会关心这件事的也不差生成公私钥这一步，那给出RelMeAuth作为妥协方案确实没什么优点了，能引导人用更安全的机制也确实是更负责的做法

[nekomeowww]

那更为简便的 KeyBase 呢？

[whyouare111]

作为一个选项是很好。要说有什么令人担心的事就是对其服务端的依赖程度吧。如果缺少事实上的其他备选项会不会产生另一种CA呢？同样是基于公私钥，其他手段分发OpenPGP publicKey也是个办法了，然后就是要求站点用privateKey对指定文字签名，验签就可以证明站点管理者/账号拥有者是私钥所有者吧？

[Linklinkguan]

#997 (comment)