Jayme's Paragraph

 users are frustrated with in today’s market. Here’s what they said.

What's your biggest frustration today as an onchain user?

I surveyed both Farcaster and Twitter to get a pulse of what onchain users are frustrated with in today’s market. Here’s what they said.

What are onchain users frustrated with?

emma's newsletter

Writing about web3, community building, and culture

Stereocaster went through a lot of changes this week, which you can view at 

The main change is a redesigned player and queue feature, so it’s easier to discover and play shared audio while scrolling through the casts feed.

It was really motivating to see how people responded to my initial post last week, even with my fairly rough prototype. I received some really helpful feedback and even a mention in 

1. Making Stereocaster more user friendly

I implemented pagination, the queue, and part of the auto-playing feature this week based on feedback from v1 and my own notes. I’ve realized it makes more sense to focus on making Spotify links work well first before branching out to other audio links, especially since I’m still figuring out the Spotify API’s capabilities.

For next week, implementing a fully-functional auto-play experience and fixing bugs are some of my top priorities. Right now, audio auto-plays after clicking “Play” on a cast, but the queue doesn’t automatically play through, which would be a big UX improvement.

Stereocaster v1 relied on a NodeJS script that generated an HTML file, which made it very difficult to make changes to my code. I ended up migrating the codebase to React, which drastically improved the readability of my code but also introduced some new challenges. I also tried out Tailwind and Vite for the first time, and I like both. 

3. Progress on the backend: still a work in progress

I didn’t get a chance to work more with Hubs this week, but I did try using the Searchcaster API to pull in casts in real time. While it worked smoothly, it felt a little slow, so I ended up writing a script that would fetch casts using the Searchcaster API and create JSON files for me to manually upload instead. This isn’t an ideal solution, but it’s working out while I continue to work on the backend.

Stereocaster Digest #1 is in the works, along with some minor bug fixes and hopefully a better auto-playing experience.

I am always open to feedback, so if there’s anything you’d like to see with Stereocaster, please let me know! You can find me on 

buildspace n&w week 2: Stereocaster v2

On Top of Ruins

My thoughts on engineering, cryptography, protocols and AI

When I first use the internet in 2000, people believed in a free and open internet: a place where anyone can say anything, and anyone who wants to hear it can listen. We were optimistic about an internet that would allow anyone to express their beliefs “without fear of being coerced into silence or conformity”. The free flow of information and hyper-connectedness of internet were supposed to promote mutual understanding of mankind and positive change.

However, two decades later, the egalitarian vision of free speech heaven has failed to materialized. Instead, we have widespread online harassment, misinformation that causes real harm, and violent and hateful content that no one should have to witness. Rather than enhancing mutual understanding, free speech has led to increasing political polarization.

Content moderation has often been an afterthought in today’s internet. Every major internet platforms today started with very few rules. As these platforms grow bigger and people began to do crazy, unpredictable and hateful things, rules and moderation are gradually implemented. There are still online spaces that adhere to the anything-goes mentality, such as 4chan, but they often turned ugly where majority of people choose not to participate. In some sense, content moderation helped make the internet more attractive and functional for most people. It’s already part of the internet.

Moderators are human, and as such, they bring their own perspectives, biases, and beliefs to the job. Without question, content that is blatantly illegal, such as child pornography, should be removed. However, in cases where the line between free speech and harm is less clear, content moderation becomes intricate. For some, certain political viewpoints are harmful and therefore should be censored. For others, all opinions, even controversial ones, should be allowed to circulate freely.

The real question, then, is not whether content moderation is censorship, but rather how it can be done in a way that serves us and the society. What speech should be restricted as harmful? By whom? In what way?

The difficulties in content moderation is captured by the 

The past decade of content moderation controversies suggests that these three goals can’t all be met.

Large walled gardens like Facebook, Twitter, and others are certainly unwilling to shrink their user growth and give up control over content moderation. The thesis is that dissatisfaction with moderation decisions on these centralized platforms is inevitable.

, is presented as a solution to the Moderator’s Trilemma. Here is the idea: de-siloing social media, giving up on centralized moderation, devolves content moderation decisions to the individual instances that make up the overall network. Under this model, if users are dissatisfied with a instance’s policy, they can freely switch instances and migrate their account data, including their followers and post history. Unlike the traditional platforms that rely on high switching costs to keep users locked within their walled garden, Fediverse gives it users the freedom of exit. And this freedom in turn enhances users’ power to influencing instances’ policy. This concept is also referred to as content-moderation subsidiarity.

The growing pains of content moderation in Mastodon

The idea of devolving content moderation is seemingly compelling, but its implementation in Fediverse, especially Mastodon, is far from ideal.

Fediverse instances are typically run by volunteers, leading to a lack of dedicated resources for determining and enforcing uniform content moderation standards. As a result, moderation decisions within the Fediverse can be arbitrary and ad-hoc, a problem that is amplified as instances grow in size.

. Journa.host is a Mastodon instance founded by Adam Davidson, a journalist who worked at The New York Times and The New Yorker. Users are required to prove that they are professional journalists to join the instance. Mike Pesca was a member of the instance, who hosts the popular news podcast “The Gist.” He posted a link to a New York Times story about health concerns associated with the puberty-blocking drugs sometimes prescribed to transgender youths, wrote, “This seemed like careful, thorough reporting.” Parker Molloy, another journa.host user and herself a transgender woman, responded strongly and calling Pesca anti-trans bigotry. Pesca defended his original post and criticized Molloy's actions, wrote, "you as a member of the activist community attack the article of bad bedfellows, insult me and mischaracterize the story as Republicans Versus Doctors.” 

Journa.host suspended Pesca for referring to Molloy as an “activist,” which was dismissive. The site also suspended Molloy for "attacking the integrity of another, who is a moderator on the server.” Despite that, journa.host’s decisions has been criticized from all sides. Some believe that journa.host should not have suspended Pesca for his comparatively restrained response to Molloy's attack. Others criticized journa.host for suspending Molloy and for not doing more to fight transphobia.

We have temporarily suspended two users. One published several posts attacking the integrity of another, who is a moderator on the server. The second user published a post demeaning the professionalism of a journalist, based on their identity. We want this to be a place where journalists can have productive conversations.

Journa.Host Admin Team (@info@journa.host)

 to the extent that several large instances have either 

 access for their users to journa.host, a practice in Fediverse called defederation.

The controversy exhibits a dominant culture of Mastodon is supportive of heavy moderation, especially of users and content that is viewed as conservative.

If users were given the freedom to exit, overzealously censorious instances should not be a problem. Empowering user choice of moderation policy is the premise of content-moderation subsidiarity after all. In reality, however, moving an account in Mastodon is not as easy as some proponents suggested. User handles in Fediverse are like email addresses (such as @kcchu@mastodon.social). The hostname of the server is part of the handle, which means that migrating to another Mastodon instance requires changing the user handle and renders links to old profile and posts obsolete. While Mastodon allows users to setup redirection from their old profile to new profile, relocating data of old posts is not currently possible. Also, redirection may not be an option if the old instance no longer exists (such as 

) or the old account is suspended. This can result in users having to start over, losing their previous content and followers.

The practice of defederation in the Fediverse is also problematic. Any Mastodon server admins can decide to cut ties with another instance entirely, rendering posts from the blocked instance unavailable for its users and preventing users of the blocked instance from commenting, replying or direct messaging their users.

Defederation is common among Mastodon instances. While the idea of content-moderation subsidiarity advocates for individual instances to make their own content moderation decisions, in practice, it is not feasible for volunteering moderators of an instance to oversee content on all federated instances. It follows that when another connected instance has lenient content moderation standards, many admins choose to defederate the entire instance. It treats all users of the defederated instances as violators, even if only a few users are causing controversy, like what occurred with journa.host. Even largest Mastodon instances are not immune to this. mastodon.social, run by Mastodon’s creator Eugen Rochko, is also facing 

Defederation as a last-ditch nuclear option to block instances because of spam or abuse is fine. But when the blocklist becomes a protest to other instances’ moderation policy or capacity, endless infighting is warranted. Instances are tempted to change the blocklist into an 

 because it is easier to manage. This situation turned Mastodon into balkanized networks of polarizing echo chambers, forcing instance admins to either adopt the strictest content moderation policy or risk being isolated from most of the Mastodon users. The outcome is a spiral of censorship, silencing even slight deviations from the dominating opinion. It makes it impossible to honestly discuss controversial topics from different perspectives without causing a controversy.

While some may prefer to interact only with like-minded people, others are discouraged by this culture. Due to the significant power that instance admins hold over their users, selecting which instance to join can be a major hurdle for first-time users. These problems diminish the platform's potential as a social internet that replaces Twitter.

Some may say that silencing misinformation, racist, sexist, homophobic, and transphobic speech in the network is a feature, not a bug. They argue that these bad speech has no social value and seriously harmful to the people who are its targets as well as to society at large, and thus should be removed from the entire network (or even society as a whole).

While this essay is not intended to be a philosophical discussion on freedom of speech, I invite readers to read the classic argument from 

. Mill argued that when we engage others in defending our opinions it deepens our understanding of our beliefs and prevents them from slipping into dogmas. (Further reading: 

We are dealing here with bad speech, not incitement of immediate violence, which is already prohibited under law. The limitation of freedom of speech to prevent direct and immediate harm to others, such as the spread of false claims about COVID-19 vaccines during a global emergency of pandemic, can well be justified under Mill's principle of harm. However, such restrictions should be exceptional and must be necessary and proportionate to achieve legitimate objectives.

free speech is not the same as free reach

,” as Reneé DiResta suggested. (No, it is not originated from Elon Musk.) Exercising the freedom of speech does not mean that everyone has to listen. 

Today’s internet is mediated by algorithms. The job of the algorithm is to surface relevant content and predict what we want to see next. Algorithms are an important tool to help us make sense of the overwhelming amount of information online. It also shapes our attention by controlling our news feeds and recommendations. Unlike free speech, there is no right to algorithmic amplification.

Perhaps we cannot prevent jerks from using the social internet, but we surely can build a system where we don’t have to hear them.

But then the question is who can and should have the power to select what a user hears. There are rightly concerns about bias in these algorithms and their lack of transparency. And I argue that the key to this problem is user choice, or the “freedom to filter.”

The social internet should empower users to choose which method or algorithms for filtering. Users could delegate control of their feed to one or a mix of recommendation services run by communities, commercial providers, or other institutions. We should establish a marketplace of algorithm that offers diversity, transparency and accountability.

The foundation of a true open social internet rely on several key technological capabilities:

Two projects are currently in the race of this category: 

One notable feature of AT Protocol is its integration the idea of “Freedom of speech, but not freedom of reach” within its protocol architecture. The network is separated into the “speech" and "reach" layers. The "speech" layer is intended to remain neutral, distributing authority and ensuring everyone has a voice, while the "reach" layer is built for flexibility and scalability. The base layer of AT Protocol, consisting of Personal Data Repositories and Federated Networking, creates a common space for speech where everyone is free to participate, similar to the Web where anyone can put up a website. Indexing services then aggregate content from the network, allowing for reach and searchability, similar to a search engine.

On top of the separation of layers, AT Protocol, particularly the Bluesky client, plans to support an ecosystem of third-party providers for 

. They are developing a composable labeling system, enabling anyone to define and apply "labels" to content or accounts (such as "spam" or "nsfw"). Any service or person in the network can then choose how these labels are used to determine the final user experience.

The issue of free speech versus safety is a false dichotomy. Both are essential components of a healthy and inclusive social internet. While it is crucial to ensure a safe online environment, it must not come at the expense of limiting free expression. By devolving content moderation decisions to individual instances and providing users with the freedom to choose, we can achieve a balance between free speech and safety. At its core, respecting the right of user choice is an essential step toward building a social internet that works for everyone in this world. 

And why Mastodon is a dead end?

Content Moderation Trilemma of the Social Internet

mishadv

We want to have our cake and eat it too. We want Web2 applications without the ever-increasing privacy issues, monopolies, and extractive-nature of them. To achieve this, we had to rebuild the underlying infrastructure and foundations of the Web. Now that we have new foundations, we can rebuild the application layer in a way that takes advantage of the functionality this infrastructure provides. Only then will we see the next critical wave of web3 applications developed and overall user adoption increase.

We’re here for the promise of Web3. The promise is a fairer, distributed web, made possible by blockchain technology 

. It is a Web that supports all of the applications we need today but rebuilt with foundations that can protect user privacy, distribute appropriate value to contributors and enable digital ownership.

In less than 4 years we have seen rapid development of the foundational blockchain layers and developer tools. We have formalised new standards to increase the composability

of the Web. We have built and battle-tested new primitives for governance and decentralised contribution to networks. The potential for the promise to come true is growing.

But now we have hit an adoption roadblock. The discourse has turned to ‘onboard’, and onboard in the billions.

It feels like a case of chicken and egg. End-users are attracted to the applications with the best user experience, and application-developers build where their business can access the greatest number of users. Both of these groups are absent in Web3. Why?

We found solutions to the data privacy problem, but applications can’t access data across different blockchain networks. We found solutions for users to have multiple digital identities, but the identities aren’t portable across protocols. Data silos. User silos. Network silos.

This is, in part, an interoperability problem: An inability for different blockchain systems to interact and communicate with each other. It’s a natural side effect of rapid innovation and experimentation. But it needs to be solved.

Imagine if an application developer who built on AWS was restricted to users with an Amazon account, or to Google accounts if they built on Google Cloud. Would we expect them to sacrifice one audience for another? To settle for the technical limitations of a single provider? Or build two versions? Would one cloud provider end up being the adopted technology for everyone?

Developers in Web3 should not be restricted to a subset of users or features of a single blockchain network.

1/ The number of active users in Web3 is already much lower than in Web2 and we make the pools even smaller when applications on different blockchains can’t communicate. As Marieke Flament, CEO of Near, stated, “

Competing with other Web3 projects for a small pool of users is short-sighted: we need to grow the total Web3 user base

2/ The majority of Internet users do not care where their applications are hosted. We cannot expect them to adopt a more fragmented experience on the basis of a promise.

Until we fix the interoperability problem, everyone will remain separate, silo-ed, tribal, picking a blockchain, or a side. Does the future of the Web not deserve better? 

Those crazy enough to build on a promise are already here. And now we need to build together. 

My hypothesis is that the application developers will come to Web3 when they can access the market without navigating the depths of the network layers. To get there, we need an accessible common layer that any developer can easily plug into.

For those familiar with the TCP/IP model, we could say we have reached the transport layer (or in OSI terms, the session layer). The common layer we need to build would span the blockchain layer and application layer. The critical difference to TCP/IP or OSI models is the power of the blockchain layer in the Web3 stack and what it can enable at the application layer. To get there, the common layer needs to abstract away from the foundations and enable cross-chain interoperability.

NEAR’s newly announced Blockchain Operating System (BOS)

 is a great example. The BOS acts as an abstraction layer on top of all blockchains. It introduces composable frontends that are compatible with Ethereum and any other blockchain. Application developers can develop significantly faster by forking components and building from there, somewhat like an on-chain GitHub.

2/ Data layer: Applications need to be able to communicate with each other because end-users want to share data between their apps frictionlessly. The difference in Web3 is users maintain ownership of their data within the applications, they can protect their privacy and decide what is shared. The 

 enables this. It provides a scalable, secure, and composable platform for storing and sharing data, and is designed to be easily integrated with different applications and services.

3/ Private, portable identities: Unifying the network layers does not mean returning to a singular digital identity. A key strength of Web3 is the ability to enable identity dispersion, “

where individuals control the creation, separation and unification of their multiple online selves

. At the common layer, we need to build with DID technologies from the likes of 

, and take advantage of Web3-native identity providers like 

4/ Communication: ‘Reaching all users’ is more than making applications accessible to everyone. It also means being able to communicate with everyone. 

  is built to work alongside all blockchain protocols and support all Web3 identities. Its account model handles the verification of identities from different blockchains and enables those identities to safely encrypt their messages. This means that all applications can communicate with all of their users, directly and securely, regardless of the blockchain network they’re using.

In conclusion, Web3 has the potential to revolutionise the internet. The early days saw a race to build network foundations, tailored to different preferences but each with the same goal of a secure, decentralised Web powered by blockchain technology. Today, the adoption of Web3 faces roadblocks due to the lack of interoperability between its various components. To break these barriers, it is essential to develop a powerful, common layer that unifies the underlying infrastructure while still preserving the privacy and autonomy offered by Web3. This common layer will foster cross-chain communication, portable identities, and seamless data sharing, ultimately leading to a more inclusive, efficient, and transparent Web that serves and benefits everyone. By working together to build this common layer, we can pave the way for the next billion users.

A Theory of Justice for Web3, Li Jin and Katie Parrot (May, 2022).

NEAR Foundation Town Hall, Marieke Flament (April, 2023)

When We Design our Identities from Scratch, Sarah Guo (January, 2022)

The case for an interoperable Open Web 

How we’re going to communicate with the next billion users 

I'm spending my nights and weekends for the next six weeks building Stereocaster, a way for you to see what your social network is listening to.

 is a huge, asynchronous build-a-thon that ends in a competition for $100,000 and a final IRL event. This season has over 4,000 people developing apps, making music, writing novels, and more.

One of the main aspects of n&w is to ship and iterate quickly, which means that I posted my idea to Twitter and got off localhost within the span of one week.

In the spirit of building in public, I’m sharing progress updates and things I’ve learned while building Stereocaster.

The idea behind Stereocaster originated from an interest in the 

 ecosystem and surfacing music and podcasts. I’ve been using apps on the protocol for a while and was really interested in developing my own.

Music and podcast discovery is something I've always been super interested in, and I felt like there was a lot of opportunity to combine social networks with audio sharing.

Funnily enough, my experience so far with building Stereocaster has given me a new appreciation for the goals of the Farcaster protocol and a better understanding of how permissionless and decentralized protocols actually benefit developers. I was able to pull casts (Farcaster’s equivalent of a tweet) easily and do whatever I wanted with them. On the other hand, I also used the Spotify API for my version 1 and saw that functionality was more limited. 

I got Stereocaster off localhost! You can check out v1 here: 

My v1 is still fairly rough, but I wanted to experiment with bringing the experience of actually listening to audio into a social feed of audio links. Right now, that’s translated to being able to scroll through casts with Spotify links and open a Spotify player within Stereocaster to listen to a preview of the audio.

The backend isn’t automated yet (more on that below), so I created the current feed using the Searchcaster API to pull 200 casts with Spotify links and displayed them manually.

Progress on the backend: I connected to a mainnet Hub.

Farcaster is in the early stages of transitioning the protocol so all cast data is stored on different “

” that anyone can run. The end goal of Stereocaster is to pull real-time data from the Hubs to display on the website, so as an intermediate step, I managed to connect to a Hub and see real-time casts.

I connected with some other n&w builders, gave and received feedback, and thought about next steps for Stereocaster.

I have a list of feature ideas, some outstanding issues to address, and a lot of excitement to keep building Stereocaster!

Thanks for reading emma's newsletter! Subscribe to receive new posts and support my work.

If you liked this post, share it with a friend!

Ideating, building, and getting off localhost

buildspace n&w week 1: the beginnings of Stereocaster

The Write3 Newsletter

I sit at the intersection of writing & web3.  A space I call Write3.  Each week, I deliver 1 tip for writers, 1 Write3 opportunity & 1 literary NFT worth collecting. 

A quick bit of news.  I've done some reflecting, and I feel a few tweaks are needed to make the newsletter even better for you, my reader. The changes are as follows:

1 Tip for Writers" will become "1 Write3 Tip"

 - Starting today, my tips will revolve around how to become a better Write3 creator.  While I feel I'm a strong writer, there's plenty of better resources to learn the art of writing.  My specialty is showing you how to navigate Write3 (NFT books, decentralized media, etc), and I plan to give you actionable advice so you can become a more successful Write3 author.

"Write3 Opportunity" will become "Write3 News" 

- When I started the Write3 Newsletter, I thought I could source opportunities (contests, jobs, write-a-thons, etc) for creators.  Unfortunately, those chances are few and far between.  Meanwhile, I come across dozens of new projects and interesting movements in the web3 space.  This newsletter is a great place to share interesting news from around Write3.  

My goal is to to provide you with as much value as possible.  Let me know what you think.  Respond to this email and give me your feedback, which is 

 appreciated! Finally, a quick thank you to my good friend 

, who helped me find clarity around this issue.  Check out his newsletter and give him a follow!

1. Write3 Tip - How To Find A Lens Profile

One of the most exciting platforms for creators and writers is the 

.  Lens is an open-source & composable social graph based on web3 and built on the Polygon blockchain.  I've been using the platform for a few months and I'm seeing lots of creatives find success on the platform.

👉🏻 The easiest way to gain access is to pick up a Lens profile off the 

👉🏻 If that's too expensive, follow the 

 and look for ways to make connections.  Lens profiles are given to creators that are deemed to be a positive addition to the platform.

CoinTelegraph recently began offering blog posts as NFTs.  This is an exciting development in the Write3 space!  I spoke with

, he shared that CoinTelegraph wanted to give their audience a chance to collect important stories from the day.  They also wanted to highlight quality journalism.  Take a look 

, founder of UFO Club.  They are doing really cool things with podcasts, NFTs and Mirror.  I highly recommend checking out their work and paying attention to how Nick is using web3 content creation to capture value for his company. There are plenty of UFO Club NFTs worth collecting, but I really enjoyed the 

 takes place tonight, 6pm (cst).  The class is only available to collectors of my latest Mirror essay: 

7 Twitter Algorithm Hacks to Build Your Web3 Following and Sell More of Your Work

At the time of this writing, there was one edition available on the secondary market, pick up your copy 

For more Write3 content, be sure to check out the 

Interested in sponsoring the Write3 Newsletter?  Email me at 

Plus, Cointelegraph jumps into the Literary NFT game

3 For Write3: Time For A Change

teleyinex.eth

I've been a user of both decentralized solutions for a few months now, and I wanted to compare them to understand how each solution has been built and what are the main differences and similarities between the two.

 client), and obviously the web2 Twitter solution. So far, I found the most insightful content in Farcaster, while Lens has a unique experience focused on creators. Finally, I have to keep an eye on my Twitter account as most of the projects keep their information there (basically because to join Lens or Farcaster, you need an invite).

Before jumping into the comparison, I wanted to create a "short" guide about each protocol. Then at the end, I will compare them and see if there's a winner, which I think is not because each of them has its cool features.

Farcaster is built on top of the L1 blockchain Ethereum. The L1 manages the user identities, while the protocol uses an L2 network to propagate updates between its users (Farcaster Hubs). The protocol then offers the following features:

1.  Secure, memorable, and human-readable user identifiers like 

2.  Real-time settlement and propagation of changes between users.

3.  Decentralized access to all data on the network at reasonable costs.

: as pointed out by some members of the CrisisDAO the delta-graph nodes are not an L2, as it does not use a blockchain to settle on its state. Thus, the protocol uses an off-chain peer-to-peer network to sync the data.

To join the Farcaster protocol, you must register a public-private key pair and an ID with an Ethereum  contract. This public-private key-pair (a new Ethereum address) will be used for signing messages plus the ID (a canonical reference for a user on the Ethereum network), so they are made tamper-proof and self-authenticating. Moreover, recipients can check the key pair associated with the ID in the contract and verify the message's authenticity.

Signed messages are uploaded to the Farcaster Hub, which works like a blockchain network. The Hubs use a peer-to-peer protocol to share messages between them and store them, using delta 

 to reach a consensus about their state. The most interesting aspect of using delta graphs is that Hubs can reach a consensus without coordination.

With Hubs storing and managing the network status, the client apps will connect to them so companies and people can build different clients for the protocol, customizing the experience for their users. This is fantastic because each app could be completely different based on the protocol, allowing the creation of an ecosystem of apps within the Farcaster protocol.

Farcaster IDs and the Ethereum address (the public-private key pair) are managed within the Farcaster Ethereum contracts, so we can be sure that the ownership of the identities is decentralized and secure.

From the official documentation of Farcaster:

 is the canonical identifier for a user or organization. Fids are numerical values like !8098, distinguished from other numbers by prefixing them with an exclamation mark. Users register fids to an Ethereum address, also known as the 

. Users can transfer fids to a new custody address, though each address can own exactly one fid at a time."

.  As this is a smart contract on Ethereum, anyone can read the contract to find out which Ethereum address owns a given 

At this point, we have all the necessary parts to send messages to the protocol:

With those two pieces, we can sign a message and send it to the hub, and the recipient can also verify everything. Moreover, the protocol does not allow anyone to reclaim or revoke a 

 once an address claims it, we have "sufficient decentralization" by allowing tamper-proof communications over the Hubs.

While we have the required items to send messages, we need a human-readable way of referencing the 

. For this reason, Farcaster has an optional 

 are alpha-numeric strings like @john or @alice, distinguished from other text by prefixing it with an at-symbol (

 is that all of them must adhere to the following regular expression:  

 have to be renewed once a year, paying a fee to the 

 can be renewed 90 days before it expires. If it expires, 

 enter a dutch auction where the price is set to a yearly fee plus a premium, which decays until it reaches zero.

The protocol's core team sets the price for these NFTs. This fee controls who can join, getting bots out of the protocol while keeping a reasonable price to get the community valuable.

As we already know, we can forget the passphrase to our wallet, so having a nice way to recover your digital identity is critical for a protocol. For this reason, the Farcaster protocol allows users to set a recovery address to protect their 

. It is important to note that this recovery only works for loss of access, not address compromise.

The recovery address can request a transfer to a new custody address after a three-day escrow.

As mentioned before, the Hubs use delta graphs to save the messages and synchronize the social network state between the nodes.

In this graph, each vertex is an entity like a user or message, and an edge is a relationship between the entities. When @alice creates a message, and @bob likes it, the protocol will create a series of deltas that will be easy to synchronize between the nodes.

Farcaster distinguishes between six types of deltas:

, which are reactions to a user's messages from another user (e.g., a like)

, which are amplifications or endorsements of a user

, which are proofs of ownership (e.g., an Ethereum address signature)

, which are key pairs authorized by a user to sign their deltas

, which are metadata about the user (e.g., their profile picture)

While Farcaster lives in Ethereum and has an off-chain solution (Farcaster Hubs) for storing the information, Lens uses the L2 Polygon blockchain.

Like Farcaster, you will need a "Profile" to participate in the protocol. A Profile is a sequential ID that an NFT will represent. The NFT will belong to a wallet address, and the owner is the person who will control the profile. Profile owners can:

 upgradable contract if your wallet address is included in the list (as with Farcaster, right now, you can only join by invitation or by buying a profile on a marketplace like OpenSea).

Once you have a Lens Profile NFT, you can post publications to it. Moreover, the NFT will have the history of all the publications, comments, etc., that the owner generates.

One interesting feature of LEns is that Profiles, and almost every protocol item, can have different modules that expand their functionality. For example, Profile NFTs contain a 

. This module has rules allowing other Profiles to follow it back and save it on-chain.

Right now, as with Farcaster, Profiles can only be minted by addresses that its government has approved. As before, this is done to avoid bots and fake accounts.

Once you have a Profile NFT, you can start posting Publications. A Publication can be a message, a comment, etc. 

Lens has 3 types of Publications: posts, comments, and mirrors. 

Publications are posted directly to a user's Profile. This means that all the created content by the user will remain in the person's wallet. It is important to note that Publications are 

Each Publication has a ContentURI that has a link to the content that the publication contains. This link could point to a text, an image, a video... stored on a decentralized solution like 

, or a web2 storage facility like AWS S3.

When you post a Publication, two modules are attached to them: the Collect Module and the Reference Module.

The Collect Module has all the logic that allows other users to mint the publication as an NFT. The minted NFT will reference the original Publication's URI.

The Reference Module has all the logic related to comments on the publication's Publication and the mirrors (retweets).

What are onchain users frustrated with?

buildspace n&w week 2: Stereocaster v2

Content Moderation Trilemma of the Social Internet

How we’re going to communicate with the next billion users

buildspace n&w week 1: the beginnings of Stereocaster

3 For Write3: Time For A Change

Farcaster vs Lens Protocol

AT Protocol vs Farcaster

yes3 白皮书 v0.1 CN

“Next Generation” Blogging Platforms (Revisited)