DID:Domain是否可以用来做did解析？
DIDMail未来期望给用户开放注册传统邮箱地址功能，比如 alice@didmail.org 对应一个did地址，可以在发送邮件的时候解析到did和公钥。这样didmail在体验上和传统邮箱会更像。
或许可以将@换成 $,比如：alice$didmail.org作为与传统邮箱的区别。
应用可以调用接口开通，并为用户发放NFT证书。
简单的实现方式可以是TXT解析，我不确定是否可以，但也需要DID: domain制定规范提供开放的接口。
7 replies
Did resolver 应该可以解析到DID的 public key，这应该是did document里的部分。
可能不需要用dns，但也可以考虑兼容用dns的txt来返回。目前还没有支持，但我们可以一起思考如何实现满足你的需要
在didmail中的应用场景就是发送邮件时，通过邮箱地址检查是否对应一个didmail生成的did账户。因为did规范，如用户随意输入一个did是无法收到邮件。didmail虽然可以通过导入私钥生成账户，但是did钱包似乎还不能查看单个did账户私钥。
让dns解析did，在社交场合让用户之间易于识别，可以进一步是普及推广did。比如创建应用账户可以通过邮箱地址注册。可以共享账号。这在于用户的选择
我们是打算这样支持来作为 did resolver的一种更简单的用法，现在其实已经部分支持了。
这种我们放在首页的高层架构图，其实表达了我们的思路，我们把DID Resolver 和 DNS Resolver 并行考虑，两者可以平行工作。 这也是我们的 DID Naming Service 的关键部分。 DID Document 提供了比 DNS entry 要丰富、可扩展、可验证很多的能力，因此通过 DID Document 可以获得完备的信息。 我们推荐应用尽可能使用 DID Resolver获得 DID Document后来实现具体应用，而DNS Resolver 作为向前兼容的一些便利性提供。
<did>.did.abtnet.io这种格式的 DNS 就是DNS 能直接用来返回任何（可resolve的）DID的 DNS entry。 这个实际上很多人可能没有意识到已经用了一段时间了， 在 Blocklet、Blocklet Server 给你的自动 DNS 里就有这样看起来很长的 DNS， 其CNAME指向的就是这个blocklet所在的服务的地址， 这里的<did>就是这个blocklet 的 DID。 类似地，如果提供TXT可以返回一些 DID Document 里的关键信息。例如: 我的个人站点 robertmao.com 还有一个内部访问的名字是： bbqasu6bcows7q7qbflqafseeveu4imx4gjmfsgt3dy.did.abtnet.io （不过这是不推荐对外的使用的，但自己可以用，这里展示是为了让大家理解我们的设计）。 robertmao.com 其实是一个 DID Domain，它看起来和普通互联网域名没有区别！ 我同样还给他绑定了 robertmao.did.life.
需要注意一点， domain name 因为不支持大小写的区分， 因此这里我们使用的
did是 Base32 编码的， 而你一般看到的钱包里的DID 是 Base58 编码的。 因此你在使用 DNS 查询的时候需要把 Base58 重新编码为 Base32 才能正确地使用。上面的例子里，我的站点的 DID 是
bbqasu6bcows7q7qbflqafseeveu4imx4gjmfsgt3dy, 这和我钱包里显示的zNKgzFjmxu9CrwFBd2VTNWuxWy2zKne6KjaT其实是同一个DID，前者Base32编码，后者Base58.这种方法提供你需要的 Public Key 还有一些工作需要做，但基础全部在了，和我们工厂团队讨论下细节即可。
考虑底层解决方案就是给邮件服务器协议写插件，使得邮箱服务器支持did解析。使得传统邮箱支持加密邮件，可以考虑找网易邮箱来做。
我觉得没必要重新发明邮件地址，直接完全兼容过去的就行了。
例如 RobertMao.com 其实也是 bbqasu6bcows7q7qbflqafseeveu4imx4gjmfsgt3dy.did.abtnet.io 那么 xxxx@robertmao.com 应该能正常收到 DID Mail 和 任何普通邮件。
不同的是，你的 DID Mail 服务器应该能正确处理来自另一个 DID Mail的邮件（这样我能接到可验证、加密的邮件）， 也能处理其他人给我的邮件（但会标记这是一个普通的邮件）； 反之亦然。 这样才能提供最大的便利。
DIDMail接收邮件的原理和传统邮件不同：
DIDMail 未来可以支持传统邮件服务协议，接收任何普通邮件。客户端可以识别是否为加密邮件做相应处理。
目前要解决发件人更方便的输入收件人地址：
1、用普通邮件地址发送加密邮件，在发送邮件前，要通过邮件地址获取绑定的did，进而获取公钥，对邮件内容进行加密。有两种情况：
2、不用传统邮件地址，用户之间发送加密NFT名片，形成通讯录，只需要选择收件人。
DIDMail在重构完后接下来优先要做的就是集成去中心化的加密名片。使得应用能够有趣。
Very interesting conversation you guys are having here. 👀