Nostr 协议目前的缺憾(1):账户和私钥绑定

Robert’s MetaMask
Dec 26, 2023
cover

一年前的时候 Nostr 大火,但火了一阵子后,很快又沉寂了。 但好在这里我们说的“火” 是在消费者社群, 而 Nostr 的开发者社区依然健壮。因此过了一年后,我又花了了些时间来看看 Nostr 有哪些进展和存在哪些问题。

Image

Nostr 社区一直在进步,但本文主要谈我觉得问题有哪些。


账户和私钥绑定带来的问题#

我觉得最大的问题是Nostr 的架构里依然是私钥直接绑定用户。 Nostr 的设计使得私钥必须在 Client 上, 因为其发送消息必须由这个私钥签名。 如果这是一个移动设备上的客户端,那么还好。 如果这是一个网页端的,那么这个私钥就可能必须放在浏览器里。 而如果有人提供托管的服务,那么私钥必然需要给托管者。

带来的问题很明显:

  • 难以安全地支持多个设备
  • 由于登录就相当于把私钥复制过去,而且私钥也是“热”的私钥,安全性更难保证
  • 可能正是这个原因,接受zap的lightening地址是额外绑定的,而不能用自己的账户接受,这也增加了复杂性降低了安全性

虽然有一些Nostr signing device 这样的硬件,但这些硬件不同于硬件钱包(虽然原理上和实现上几乎完全一样),这些signing device 可能是派生一个nostr key后,把这个私钥给应用(私钥离开了设备),而不像硬件钱包是对交易进行签名,私钥没有离开硬件钱包。

Nostr 要解决这个问题,就必须在协议上允许一个client 有自己的私钥,而这个私钥需要能为一个公开的用户签名。 也就是一个用户,需要能对应着多个可签名的私钥, 这样万一某个私钥丢失,只需要废掉它即可。 但这时候带来的一个问题是: 必须有一个登记的地方,来建立这种关系。 目前看来 Nostr 还没有解决这个问题,不知道是Nostr 社区觉得这个不重要,还是有其他原因。


Mirror #

Mirror 一度是我觉得最有潜力的 Web3 应用,他不但采用Ehereum来登入,还把数据发布在 Arweave上(但应该是Mirror 自己托管的,因此 Arweave的 私钥应该是 Mirror自己的)。

尽管如此,Mirror 采用签名的方式来验证文章的确是这个用户发送的,但这个签名并不需要采用钱包签名来确认,而是浏览器侧来实现的。 Mirror 采用 Signing Key 的方法解决,这个方案不完美,但至少解决了问题, 这应该是看到业内最早采用这样的方式来解决需要不断签名的问题:

Signing Keys, Multi-Device, and the Fundamental UI Problem in Cr…
I was away from my computer this the weekend, hiking in Berkeley (photos below). Because posting entries on Mirror require a device signature, and the private keys are on my computer browser, I was unable to post an entry. This relates to the fundament crypto UI problem:
favicon
https://g.mirror.xyz/FNo46PS21mjaAVLu-Nt1HeJT_yH-8lnm0W-HsjG6px8

但Mirror 里发表文章属于“低频”操作,即便需要钱包签名体验也还不为太差。 而在Nostr 等应用,用户发表要频繁很多。


Farcaster #

Farcaster 采用 Signer key 的方法。Farcaster 的账户由一个唯一数字 fid表征。每一个 Ethereum 地址可以拥有一个fid,并且有一个恢复的地址(用于恢复)。每一个Farcaster client 上需要用来签名的是signer key,每一个 fid 可以登记多个 singer key,这样可以支持多个设备。

Farcaster 协议里采用 Registry来实现这些登记,Registry 采用了区块链的智能合约。目前其使用三个registery 合约来分别建立以下三种关系:


Image

Farcaster 的相关文档:

Farcaster
A protocol for building sufficiently decentralized social networks.
favicon
https://docs.farcaster.xyz/learn/architecture/contracts


Lens Protocol#

Lens Protocol 的设计是把用户profile 作为 NFT 放在链上, 这样不同的应用都可以共同操作和访问这个 Profile NFT。 每一个 Profile NFT 都被一个EVM 的地址拥有,这个地址相当于是这个profile 的主人。

在Lens V2 协议里有了一个handle 的概念,相当于是用户名这样容易记忆的名字。 这些名字可以被解析到对应的 Profile NFT。

Handle
Handle is a new concept which was introduced in Lens v2.Think about Handle as a name on a social network: like @alice, @bob or @vitalik.Handles can exist and can be minted separately from profiles, and then can be linked and unlinked from one profile to another.Handles exist in their own namespaces,...
favicon
https://docs.lens.xyz/docs/handle


过去玩Lens Protocol V1 版本的时候感觉一个不胜其烦的毛病就是不断地需要钱包签名(无论是follow一个用户,还是发表一个帖子),这让使用体验非常糟糕, 现在好像专门为此改进了。

现在 Lens 里有一个 Profile Manager 的概念,可见这是他们专门考虑了这种需要不断签名,以及在多设备上的问题而提出的解决方案:

The Profile Manager enables gasless and signless transactions (transactions without signing any approval modals) in your Lens app.

Blockchain technology introduced many drawbacks like wallet popups, seed phrases, passwords, funds, and multi-network (blockchain) dynamics. These are fundamental for securing cryptographic transactions but present many UX challenges. So, are we doomed, or should we be optimistic?

In blockchain terms, Optimistic means that we assume the transaction will come through so we don't need to wait for validators to reach a consensus. This wouldn't be acceptable for financial transactions because of the double spending problem but can be helpful for social media interactions.

Social media is about great frontend experiences so having wallet prompts for every share or follow is not ideal. The challenge is that being optimistic in a front-end experience is possible but still, every action must be approved by the user wallet.

To solve this issue, we created the Profile Manager. Basically, it is an intermediate wallet with funds that act as the signer for every transaction. We only have to delegate signing privileges to this profile manager wallet which operates hidden in the backend. This combined with an optimistic UI creates a seamless experience identical to what we are used to today.
Lens Profile Manager
Previously known as "Dispatcher".
favicon
https://docs.lens.xyz/docs/lens-profile-manager

Lens Profile Manager 有些像一个 AA 钱包的智能合约。

image.png

感觉Lens Protocol 是在这个问题上考虑最周全的。


XMTP Protocol#

本来不想提及XMTP,因为XMTP 实际上到目前(2023年12月)为止还是一个传统中心化消息服务,它的本质是能把不同的区块链账户和XMTP 的消息账户绑定,并且允许把区块链账户作为消息的接受/发送地址,仅此而已。但XMTP 的 marketing 和 BD 成效不错,和不少钱包绑定,能直接给区块链地址发消息,很多用户认为这是一种去中心化的消息系统。

XMTP 应该也是采用类似的方式,产生一个signning key 用于对消息签名。 其第一个步骤是让用户用区块链钱包签名一个消息,这个消息里包含一个新建立的消息账户,这里相当于是建立区块链账户到XMTP账户的对应关系。

Sign to send and receive messages using apps built with XMTP
Learn about what it means to sign to create and enable your XMTP identity.
favicon
https://xmtp.org/docs/concepts/account-signatures


Bluesky Social#

Bluesky 里用户的数据保存在自己的 PDS(Personal Data Store) 里,按文档字面意思,似乎是可验证的,而这个验证是 PDS 来实现的,也就是 PDS 可能有用户的 private key:

Repositories are self-authenticating data structures, meaning each update is signed and can be verified by anyone.
Personal Data Repositories | AT Protocol
favicon
https://atproto.com/guides/data-repos


但在应用层面上,Bluesky 的设计里消息似乎没有加密或者签名的机制,因此客户端可能并不需要一个密钥, 由于用户的这个私钥在 PDS 上,相当于在服务端,因此其客户端不需要私钥似乎是可行的。 从Bluesky的注册、登陆机制可以看到就是常见的用户名、密码方式, 可以认为即使其PDS 有私钥机制,这也是一个custodial 的方案。

Applications model | AT Protocol
favicon
https://atproto.com/guides/applications


Bluesky 的这个设计,使得它可能不存在上述私钥的问题。 当然这也不说明其更先进,只是因为它采用了更传统的设计而已。 Bluesky 采用了 DID 和 PDS这样比较先进的设计,但在触及到最终用户的时候,选择了采用传统的用户名密码方式, 也许他们目标还是普通用户, 不像Les Protocol, Farcaster,Nostr 定位目标就是对crypto 更了解的人群。


W3C DID #

BlueSky用了 DID,这里提一下W3C DID里其实充分考虑了这个问题,但BlueSky 目前可能还没有使用。

在W3C 的 DID 里有一个 DID Controller 的概念:

Decentralized Identifiers (DIDs) v1.0
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.
favicon
https://www.w3.org/TR/did-core/


Image


而且DID Controller 是可以有多个的:

Image


关键这如何实现? 一个关键的要素是 VDR (Verifiable Data Registry), 也就是一个可以验证的登记服务。 有很多种方法可以实现 VDR,目前比较多人认为区块链是一个比较合适的实现 VDR 的技术,能兼具去中心化和标准化

Image


Nostr 可以实现一个 DID:Nostr method,我刚刚看到TBD 有一个 DID:nostr 的method:

GitHub - TBD54566975/did-nostr
Contribute to TBD54566975/did-nostr development by creating an account on GitHub.

TBD 和 Bluesky 都是 Jack 的公司,Nostr 又是Jack支持的协议,因此这一低昂不让人惊讶。 不过目前为止还是draft也好几个月没有更新了。