Lens Protocol allows users to log in with their external Ethereum wallet.
- One account = one minted NFT. One Ethereum address may control several Lens accounts.
- Every interaction is recorded on-chain via a series of smart contracts: create/modify/delete profile, following, un-following, like, un-like, create/modify/delete/retweet posts, etc.
- Each of these actions requires the user to sign the transaction using their Ethereum address controlled by their wallet.
- Note that only metadata is on-chain, not the actual content of the posts.
- Developers can create a variety of products that use the Lens Protocol. The most famous, created by the creators of Lens, is called Hey (formerly Lenster) and it is a Twitter clone.
Advantages
- Decentralised, inherits the same censorship-resistance as the underlying blockchain (Ethereum).
- The underlying social graph data inherits the high-availability of the Ethereum blockchain. It’s also open and permissionless - anybody can build on it, though the content payload may not always be open-data.
- Portable identity and social graph.
- Some Ethereum maximalists simply like the idea to record everything on-chain and appreciate the “purity” of Lens as a 100% on-chain social protocol.
Limitations
- Inherits the same issues that the underlying Ethereum blockchain faces: poor scalability, expensive, slow, and complex wallet interactions.
- Lens Protocol stores all the metadata on chain, including those from bot accounts, and including from the majority of the unimportant messages and replies which nobody would care to censor anyway. This is extremely expensive for no valid reason. As a result, it is not scalable, and it is not environmentally friendly.
- One person can own an infinite amount of Ethereum addresses and can mint an infinite amount of Lens NFT accounts. Even though minting a Profile costs money, X experiment with its Blue tick has shown that paywall does not prevent scams/spams. As a result, the protocol is not sybil-resistant, and does not protect against identity theft. (Note that the Ethereum community is working towards integrating various real-life credentials and reputation to face this challenge, like with the use of Proof of Passport.)
- Not user-friendly: users need to download a mobile wallet in the form of a browser extension or mobile app to integrate with the platforms that integrate the Lens protocol. Integrating with wallets currently means interacting directly with keys, which is challenging for the vast majority of users. Besides, users have to sign every action they make in the apps that use Lens, including casual likes and follows, which drastically hinders the quality of the user experience, as signing must open the external wallet, users must plug in their Ledger, etc. The process takes a couple of seconds each time. This has been attempted to be solved by the Lens team by allowing users to utilise the “Profile Manager” functionality to delegate non-security-critical capabilities either to a less secure wallet such as a browser/mobile wallet - which still requires manual interaction but without needing the hardware component, or to a third-party application (referred to as “Signless experience”) - essentially entrusting the app to sign on behalf of the user, compromising on data verifiability. Signing every transaction on the client side with a key stored in mobile storage secured by biometrics without user interaction at every action could be secure and user-friendly from the perspective of a social media, but this solution is not viable for Lens because the keys that control the Lens account, either the main ones or the ones delegated via Profile Manager, are Ethereum key pairs. But Ethereum key pairs, besides requiring higher security assurance because of its responsibility towards financial assets, rely on cryptographic primitives that are not supported by the Secure Element of modern mobile phones. Note that this is the consequence of an intentional stance from the Lens Protocol: the focus on pure Ethereum interactions.
- Security and account recovery issues: to secure a wallet, one needs to buy a costly hardware wallet such as Ledger or Trezor, one needs to learn how to configure it correctly, and one needs to set up a Safe smart wallet to make sure they can recover their account in case they lose their private key. (Note that this is also a field of work-in-progress in the Ethereum world, notably with zkEmail that attempts to allow account recovery based on email ownership.)
- Privacy concerns: as every data is recorded in a public, distributed, and immutable ledger, there is no room for mistakes. Cryptographic algorithms must be flawless or users will be doxxed now or in the future. The hash of data payload is not cryptographically secure for simple texts - so it can be trivially guessed by brute-force attacks. Even though only metadata is recorded on-chain, this is not GDPR compliant because likes and follows for example are considered personal data. Formal data deletion requests (un-like, un-follow) cannot be processed because this data on Lens has been stored on a blockchain. “Unlike” and “unfollow” on Lens are simply adding this new information in the next block, it does not remove the data from the previous block that shows that person “Y” have liked/followed content/person “Z”. This problem is made particularly prevalent because of the push towards public-facing ENS names on Lens - ENS are pseudonymous identifiers that are easily correlatable with the person’s identity, especially during KYC on centralised exchanges and conversion from crypto to fiat or the other way around, or when individuals purposely or accidentally associate their ENS with their real identity.
- The protocol focuses on the traditional profile/follow/like/post/reply/repost mechanism, and does not innovate from a product perspective aside from the objectives and advantages exposed above, which are not enough to persuade most social media users to migrate their account from traditional centralised social media.
Could it be useful for our requirements?
- Besides other aspects explained in the “Limitations” section, Lens does not match the “Scalable, Cheap and Performant” requirements.
