Now, a supermarket might not actively identify its customers, but the employees cannot help but recognize some customers every now and then - as people sometimes do. So in fact the store uses an identification system whether they want to or not: a pseudonymous, automatic, short-term identification system known as “recognizing that guy”, which sometimes happens to prevent the exploitation of free samples. The system is pseudonymous and automatic because the store employees do not collect any personal details about their customers. It is short-term because employees eventually forget most customers, particularly those who don’t show up every day for free cheese.

When there is nothing else, this is what non-digital society defaults to. But that changes as soon as things move to the internet. There it is easy to waltz back into the store under a new identity and grab anything of value for as long as possible at no cost. The hurdles built into the digital world are much more easily tampered with and the lack of any kind of identity is an important reason why. How is anyone supposed to run a store if those who misbehave return moments later under new identities after they have been kicked out? Complete anonymity causes issues not only for those who give free samples but for anyone who counts on genuine user behavior to make a product useful, which is much of the web.

Thus websites raise login walls, causing a headache for users who must go through yet another login flow and manage yet another set of login details - as if the store would give free samples but only to customers who fill out a form with personal information. A better system has only an unnoticeable exchange of pseudonymous information that doesn’t bother the user for personal details. Like in the non-digital world, customers are welcome to visit the store and have free samples - no questions asked - but those who misbehave can be kicked out, which the store can enforce if the customers try to return.

Social logins - login through one of the social networks - have some potential to get to the point of seamless, under-the-hood pseudonymous identity transfer. Since a site simply plugs in a third-party identification, the user and website both have fewer problems. Social login could be even smoother by exchanging just enough pseudonymous information to ensure sites that they are dealing with a genuine user without bothering the user. But this convenience comes with a dependency since the store relies on someone else’s identity data.

A similar identity system can instead be built openly, without having to rely on a third party. It can be done with public-key cryptography: users who claim they control a private key prove it by signing a message that anyone can verify to be correct with the corresponding public key. Identity rotation, however, becomes trivial since it costs nothing to generate a new identity, which makes the system practically useless for mandatory pseudonymity. When the system is open there must be some cost or work to generate a new identity - preferably unnoticed by the user but sufficient to prevent identity rotation.

A distributed ledger can be useful to solve this problem. Out of all the possible public/private keypairs, only a few have value according to the ledger. If the ledger is sufficiently distributed and decentralized it is different to a social login system because no third party controls it. While it is trivial to generate any identity - you just generate a new key pair - the addresses that own something according to the ledger are scarce. Getting one comes with a cost.

Someone who gives out free samples on the internet, such as free articles, can choose only to do so to those who control one of those addresses. You need to provide a new such address if you want a free sample. The test can be improved by analyzing the transaction data that led to the current holdings of an address. You could check, for instance, if the address has held a certain amount of value for a certain amount of time. In practice, as you visit websites, you identify yourself pseudonymously by signing a message, with some degree of automation to make the process convenient, that proves that you control a public key (known within the Ethereum ecosystem and similar blockchains as wallet login) that owns some currency. Thus you don’t have to log in, in the traditional sense, to like or upvote an article. But if a user misbehaves, the website blacklists the public key. The user can generate a new one, which is free, and get it to have value according to the ledger, but again, that has a cost.

A common objection to using open systems of this kind compared to centralized ones like social logins is that the centralization that it removes was actually a feature rather than a bug: users and companies entrust an intermediary with power, the argument goes, mostly because they want to, not because they must. Malevolent users might figure out a way to game the system, making human intervention necessary until a long-term fix is implemented. We might not need to or want to know the methods of those in control - some degree of opacity will likely make the system harder to exploit - we just trust them to do their job. Although there is truth to this argument, it is a mistake to insist that the one who makes these judgment decisions must also alone control the entire system.

Consider how conflict is resolved via a legal system. There is a judge, but judges are not free to make up laws as they go. Incorrect verdicts can be overruled. It is common in business contracts for the parties to agree on the legal jurisdiction in which conflicts should be resolved, so the parties have some say-so in how third-party judgment should be applied if necessary. A judge provides judgment, yes, but that does not mean that the judge can force any outcome even if it clearly is wrong. Moreover, the involved parties have some control over the process of applying judgment to resolve future conflicts.

Digital transactions or interactions are commonly thought of as being between two parties through a system owned by a third party - the third party also being in control and resolving conflicts. But transactions might just as well be between three parties on a system that nobody solely owns. The third party is chosen by the transacting parties to provide judgment when necessary. Two out of three parties can trigger certain actions to settle conflicts. There is room to provide judgment, but it is done by a party in the system who needs not fully control it.

In the case of identity, like pseudonymously logging in with an address to get a free sample, the process must be highly automated. A third party provides judgment-as-a-service - it (algorithmically) gives verdicts on whether the user behind an address is genuine. They could keep their methods open or secret depending on what they believe the market wants. Their customers are free to switch to another judge without abandoning their current identity database. A third party provides judgment, but there is no third party who can revoke anyone’s access to the system. Importantly, the website decides which judgment provider they wish to use. The result is a system similar to social logins but with healthier power dynamics.

Now, it may seem soul-sucking to combine art with the coldness of money. But it is inevitable that for any list it has to be decided what goes at the top. It could be decided by a person, a company, an algorithm, or as is the case here, a market. And a market is not a market if you do not make it costly but potentially beneficial to participate, and markets produce information.

The second is that there is little user choice. There are limits and restrictions that are supposed to protect users but that the user has limited control over. Take as an example the expiration of credit cards, which becomes a cadence for renewing payment details for subscription services. While I am sure that this benefits many, some do not wish to rotate their payment details and cannot opt out. It is decided for me and I have no choice but to rotate all my payments details every few years.

The third is that card payments are expensive. These payments incur a fee of some percentage of the total amount. Although it is not visible to the consumer, it is still real and it is the consumer who pays in the long run.

The name of ERC-6551 doesn't say much about its usefulness, but I believe it's a useful invention. ERC-6551 is a standard that gives Ethereum NFTs wallet functionality. An NFT, a unique or scarce onchain object, can therefore own other NFTs. But ownership in itself is not as important as the consequence that it enables NFTs to represent particular concepts, such as objects consisting of other objects, more accurately.

For instance, you might have an in-game character that is an NFT. (Since that character is an NFT, game developers can use it in games with confidence that it will remain permanently available; no outside organization can cut access to the character if they believe it's a threat to their business.) Let's say the character has a backpack. You can fill your character's backpack with stuff. That should have several consequences: You can no longer give the backpack away without figuring out what to do with the stuff. And you cannot give the character away without figuring out what to do with the backpack. Anything inside the backpack, however, you can give away with no issue. So there is a difference in logic between the character, the backpack and its content. With ERC-6551, the stuff inside the backpack can be owned by the backpack and the backpack by the character, which would account for this difference.

Another consequence of filling the backpack is that it looks different since a full backpack should look different from an empty one. A static image of the backpack would not accurately show its current state. Instead, the image must be generated based on the current state of the backpack. This could happen onchain through a contract that uses the backpack and its content, or offchain, like in a game environment.

This might sound obscure. To many, the concept of NFTs is cloudy to begin with and this doesn't make it any more tangible. In fact, a consequence of ERC-6551 is that it pushes NFTs toward being more abstract. When many think of an NFT, what pops up is an image stored onchain (of a monkey, to be precise). But only some NFTs will be like this. A different use case is NFTs that are not simply stored images, but abstract information that represents information like structure, organization, logic, hierarchy and rights. What a particular NFT represents changes over time, not because the data inside the NFT has changed, but because there is some change of structure through change in ownership.

The NFT itself goes from being a static image to an abstract object, which changes via transaction to its wallet. Because of that, an up-to-date representation of it must be generated. We get NFTs that can change while still immutable, with representations that are generated rather than stored. There might be generators that output an image, a video representation or a playable character from that same NFT. Some NFTs, such as those that store a work of art, will remain similar to what they are today because the goal is to preserve a particular work of art. But for other NFTs, much will be stripped away, making NFTs only an abstraction.

It's convenient to integrate with feeds that are already used. So the few feeds with our attention expand, like inboxes have become a place for general news. It doesn't matter that there could be nicer products outside the feed. What matters is which feeds users direct their attention toward.

One such feed is Twitter, now X. Much of what constituted Twitter before it was acquired has been replaced. It raises the question - why acquire it in the first place? It wasn't for the brand because that has been replaced. It wasn't for the software because much of that has been open-sourced for anyone to use. It wasn't for the employees because most of them were fired. No, Twitter's most valuable resource, along with the network of user connections, is the attention users direct to their feed. It's one of the few feeds users are in, and you can do things with a feed like that.

TikTok is another such feed. It started as an app where users remixed each other's music and dance clips. Now it fills all kinds of purposes. It was a feed that users were in and it broadened from there. Just like email, TikTok has evolved into a feed that many get their view of what's going on in the world from. It matters little what these feeds do in the beginning. What matters is what they absorb as they grow.

I don't expect that the incumbent apps will wake up one crisp spring morning and decide to collaborate to provide this. Although it would be a product improvement, the user network is a key resource to any chat app. They would hardly risk a user outflow by allowing users to communicate within their network through other apps.

A better approach is to build the similarities that the apps share, sending messages within a user network, as an open-source protocol. The differences that users want, such as different UXs and encryption levels, exist in applications on top. Like email but for chat.

Enter XMTP, which I've been using for chat. It's an open-source protocol for text communication. Unlike email, it works in real-time. It's also easier to switch applications, so if you prefer a different application with maintained access to the same network, that's easy to do. Logging into a new application took me less than a minute. Different apps have different UXs but still work together.

The idea is to turn XMTP into a protocol that runs independently of any organization. This would mean that anyone who builds on the protocol can do so without being at the mercy of another team's permission. The organization behind XMTP is currently working on getting to full decentralization. Once that is achieved, the challenge is to maintain it. As apps try to carve out a competitive position for themselves by solving problems in the application layer, the ease of switching apps becomes harder to maintain.

I've mostly used converse.xyz, an intuitive chat application for iOS, similar to WhatsApp. If you're on XMTP (whichever application you prefer), drop me a message at hey.caz.eth to get in touch. This newsletter, by the way, was sent out to wallet subscribers via XMTP.

Since much new art is digital, it's a lot harder to drop bombs on it these days. The only war this art will lose is against time, ending up lost or forgotten. Either that or against an army of remixers who drown an original in fakes.

To prevent both of these things from happening, some new art is stored as NFTs on a blockchain. But it can still be lost - not only as in being forgotten but as in disappearing. The current architecture of most NFTs doesn't ensure permanence, largely because it's too expensive to store art directly on the blockchain. Instead, creators insert a URI in the NFT that usually points to IPFS or Arweave. But there are problems with both of these systems.

IPFS doesn't guarantee decentralized permanent storage, because storage happens outside of it. IPFS only facilitates file transfer, like with torrents. The link is persistent but there's no inherent guarantee of storage. The perishability will become evident over time, disappointing owners of NFTs not so well-versed in their technical intricacies who counted on their collection to be permanent and weren't storing it properly themselves.

Arweave, a blockchain built specifically for file storage, tries to fix this. The current issue with Arweave is that the URI, permanently stored in the NFT, that points from the NFT to the file containing the art, isn't decentralized - it nearly always points to arweave.net, a centralized domain that may shut down.

While most who know something about NFTs probably see these issues, there's still reason to believe that NFTs are viable for long-term art storage. Even though NFTs aren't currently perfect, they're better than any alternative. They're also improving and the existing problems are solvable.

The problem with IPFS, for instance, might be solved by pinning IPFS art to a decentralized service that ensures that it's hosted on a IPFS node. There are efforts on this, by using Arweave as a way to pin IPFS files, but there's still some way to go. And if arweave.net shuts down, developers will probably figure out ways to restore the URI's functionality, for instance through a smart contract that burns or stores the NFT in return for a new one that circumvents the current domain.

More generally, I don't think there will ever be a static system that guarantees permanent intactness. It's the goal but we will never arrive. Important objects and information survive only because people take care of them. That's why it's a mistake to believe that the system is useless until it's perfect, because it never will be. Even if it were economically possible to store art directly on Ethereum, eventually Ethereum itself will break unless someone works to prevent that.

The Last Supper is roughly 530 years old, a long time for something that started to fall apart only years after being created. It remains because art conservators make an effort to preserve a piece that would otherwise have crumbled centuries ago. Similarly, digital art on the blockchain might survive, but only because modern-day art conservators work to ensure that.

Seems useful - how to make the most of such a model in terms of product? The breadth itself is a nice property because of the all-in-one interface. But in some areas a general-purpose product isn't enough - users need something purpose-built and the ability to combine LLMs with other tools. In the next few years, we'll see what belongs in which category.

It's a reoccurring theme for software products. On one end there's the team building for a specific problem with the advantage of focus, making almost no trade-offs when it comes to solving that problem. On the other end, there's the inferior product with the advantage of being integrated into a larger user context. Sometimes there's a product advantage to that due to feature synergies. Often though, it's just a matter of convenience, since users avoid the very real mental cost of adopting an additional product and making a habit of using it. It's a constantly ongoing experiment to figure out how tools ought to be bundled to maximize user experience and synergies while minimizing that mental cost.

For some use cases, it will likely be general-purpose LLM direct to the user because people don't bother with anything tailored to a particular problem. There will also be existing products that incorporate LLMs to improve them, making it convenient for existing users. And finally, there will be new companies that overcome user inertia by using LLMs to build great products for particular use cases.

Out of the three, one might believe that general-purpose LLMs will be used for most tasks. Just like Google is the destination for most searching regardless of the topic, the inertia of using purpose-built products could turn out to be too large. But I believe it will be different this time. LLMs do more than retrieve information - they do tasks and solve problems. It's not merely asking "What information are you looking for?", it's asking "What are you ultimately trying to accomplish?". Helping with that might be a very different experience depending on the problem.

Midjourney, for instance, uses LLMs to generate images from natural language. It all happens through chat via a Discord bot, which means that users lack the control that comes with other tools. The user experience is cumbersome since it's separate from the existing workflow. Several companies are figuring this problem out and it seems clear that eventually the two will be integrated. It might even be a new product. By starting from scratch, some teams might create a much better user experience to create images through a natural language interface while preserving full control over the image-creation process.

A related problem is figuring out how general the model itself should be. If a model is purpose-built for a particular setting, it doesn't need to be able to do everything. Startups are working on this too, narrowing the breadth of LLMs slightly by defining the model's context or adding data to it. This tunes the model to a particular domain of problems, sacrificing generality but maintaining some general abilities, such as the ability to get to the essence of a prompt and see it in a larger context, while making the model better at a particular task.

Now that LLMs are available and clearly appear to be useful, the experiment carried out by startups and companies is figuring out how broad they should be and where they belong.

Even though the Vision Pro looks impressive and game-changing (we will see when we try it) as a product, it's just as impressive that Apple attempts a project like this, regardless of how good the product turns out to be.

As an investor in startups, I'm used to seeing the most disruptive innovation coming from outside of large corporations. Sure, corporations innovate, but it's mostly the kind of incremental, backward-compatible innovation that builds on top of the successes that a company already has. Either that, or as an attempt to move into new products that complement the existing portfolio. Most large corporations are cautious about doing anything that doesn't protect existing cash flow, which is one reason why a lot of innovation tends to come from the outside, large corporations only catching on once they realize that they must.

This resembles the innovation that Apple has been doing for some time. Their development efforts have been focused on incremental improvements to their existing products (mainly the iPhone), new products that complement the old ones, or expansion that increases their take-rate related to existing products, both downward and upward. Upward into hardware that they once procured, and downward into software and content that third-party app developers provide on their platforms.

But this time Apple really did think different, as the old slogan goes. If it's successful, the Vision Pro will very much compete with several of Apple's own high-end productivity tools, at least the Macbooks and some of the Macs. Apple is driving a change that will potentially disrupt its own products. It's an organizational and leadership achievement to carry out a project like that. It also takes a lot of guts, since short-term shareholders of Apple probably are uneasy about spending large sums on developing a product that risks upsetting some of the company's main cash flow generators. But in the long run, it's the right thing to do.

Apparently, these simple rules are all it takes to build a large financial machine. Nouns, the biggest of this kind of DAO, currently sells memberships for about 25 ETH each day and governs a treasury of 28,000 ETH (50 million dollars). Recently, they spent 42,000 dollars to fund a global pizza party.

They're also all it takes to create hot debate. In the last few days there has been a flood of discussion about what kind of proposals a particular DAO (Purple) should vote on, which resulted in a new DAO forming (Purpler). Purpler, as opposed to Purple, only funds projects retroactively, with the idea that this leads to more efficient use of the treasury's money.

Regardless of your view on DAOs, it's an interesting thought experiment. How do you create a simple set of rules that allows people who don't know or trust each other to collaborate around economic decisions without centralization?

Governance can be improved in three main ways: First, by ensuring that as many members as possible participate directly or indirectly in voting. Second, by ensuring that competitive proposals are presented to the DAO to vote on. Third, by ensuring that when the DAO decides to spend money, that money is used efficiently and in accordance with the proposal.

First and foremost, the number one goal of a DAO should be to increase direct and indirect voter participation. If members don't vote the whole idea fails. When a significant fraction of the members aren't exercising their votes, the decisions made don't necessarily reflect the will of the members. There can be non-protocol initiatives to nudge members toward delegating their votes, but it's more robust to make protocol-level changes to incentivize voting.

To emphasize on a protocol level the importance of voting, members should risk losing their membership if they don't participate. A reasonable mechanism would be that a super-majority, such as two-thirds or 80% can decide to renounce a membership. The downside of this is that by unfairly voting out members, malevolent actors can increase their relative control over the treasury. Such behavior can be prevented by hard-coding compensation for those who are ousted. The value of memberships is known since they are marked to market as new ones are auctioned off. In this way, the DAO can renounce memberships to maintain an active membership base, but they need to pay for it. To further prevent attacks, the rule can state that not only must a vote be taken with a decision to renounce a membership, but a predefined criteria must also be fulfilled. For instance, a member hasn't voted directly or via delegation in, say, 90% or more of the votes during a year.

The goal of these mechanisms is to increase direct voter participation as well as delegation. Delegation is desirable because it increases voter representation while fewer people have to invest their time (and gas) in voting on every proposal. The problem with delegation is that it introduces agency problems. But this issue can be mitigated with digital voting since a member has the choice to change the delegation or vote directly in every vote. You can delegate your vote as a default, but when there's a particularly important vote where you have a strong will you can always choose to vote yourself. It's no less complicated to run a voting process with all of the voters compared to via delegation. Some of the practical barriers in an analog voting procedure are minuscule in the digital world.

The second way to improve governance is to ensure that the DAO has competitive proposals to vote on. A current problem is that most votes are simple yes/no decisions. This type of choice makes it hard for a DAO to make good decisions. For an important spending decision, it's good governance to consider multiple offers. If a certain proposal is to do work for some amount of ETH, there is a good chance that someone else has a similar proposal for a lesser amount of ETH or can do more work for the same amount. Increasing competitiveness means creating better offers for the DAO to decide on. It's also easier for members to make a decision when there are multiple choices rather than just a yes/no decision. Thus, the protocol should allow for more types of votes than just simple yes/no decisions.

The third part is more operational and relates to how the money is utilized after the DAO has decided to spend it. Since there is less trust between actors in a DAO than in traditional business this part of governance is crucial. When the DAO decides to send significant amounts of money to unknown people, it should have safeguards in place to ensure that the money is spent as intended.

One way to do so is by retroactive funding, as suggested by Purpler. This probably works best for small projects where someone is willing to take the financial risk of potentially not getting funded. But it doesn't work for larger projects. That doesn't mean that the DAO should pay out everything upfront. Rather, a small payment upfront combined with installments upon deliveries is a good way to share the risk between the DAO and those working.

There must be trust somewhere in the system because small payment decisions need to be made to do work. It's not practically feasible for the DAO to be involved in every small decision. On a day-to-day basis, there should be a trusted representative from the DAO to OK payments. This representative is responsible for operations and should be compensated for their work. There should be many different representatives from the DAO - they'd work on a project basis. A representative is only necessary in the case where there is no trust between the DAO and the supplier. If the supplier is recurring, trust can be built between the supplier and DAO. In those cases, there wouldn't be a need for a representative.

So there you have it, some simple ideas on how to improve governance. Incentivize members to stay involved, ensure that they get competitive decisions to vote on and that the money is used as intended.

Contrast this with Product Hunt, which has an audience that extends outside of software developers. For instance, although many AI-related repos are trending on GitHub, none make their real-world use case as clear as Atua on Product Hunt. Atua gives "instant ChatGPT access on any Mac app with a simple hotkey". Atua has a business model around this, whereas repos on GitHub are mainly free.

There is a gap between GitHub and end users. That gap consists of finding a real market opportunity, applying a business model, writing additional code for a specific use case, branding, support, and more. These parts are done within companies. Companies package open-source code, make it easy to use, provide distribution and support, and charge for it. Companies have a business model while open-source projects don't.

Consider Linux as an example of how this typically looks today. Linux is open source. There is a plethora of distributions built on Linux, like Ubuntu and Manjaro. They package open-source code and make it easy for businesses and consumers to use. Ubuntu is as easy to get started with as Windows. That is because people at Ubuntu are doing work to take the Linux kernel and turn it into a product. Ubuntu comes with support if you pay for it. Other than that, revenues are primarily donation-driven. The company receives those donations. This is opaque because it's not obvious by default how the donations are used (although some companies can report this at their discretion). It is also limited because the company can't pay contributors broadly. The Linux kernel itself doesn't have a business model, but Ubuntu does. There is of course the Linux Foundation, but they don't own the code directly. The main problem with this is not so much with Linux as much as that a lot of code remains at the Linux-kernel stage rather than making it to the Ubuntu stage.

But cryptocurrencies can change some of this. An under-appreciated fact of digital money is that it integrates natively with code, enabling it to have an intrinsic business model. For instance, each time a particular event occurs that may trigger a payment. Incorporating payments directly into code is simpler because it can be done entirely within the realm of software development. It takes the business model fully into the home turf of developers.

Compare Linux to Uniswap. Uniswap is an open-source project, a decentralized crypto exchange. Not only is the Uniswap community building the algorithms required to run such an exchange and putting them out in the open. They are building the final pieces too - building the actual exchange, with branding and web. Uniswap is a product. In the code, there are ways to enable fees that flow to tokenholders with each transaction. When the owners decide to, they can activate that fee that flows to the owners. Uniswap is a natural place to start with something like this because it is crypto-native. But there is no reason why the same model cannot be applied more broadly. Linux could have been open source all the way to the end user, with revenue flowing also to those who contribute to the Linux kernel. This tightens the gap, making it worthwhile to build true open-source products rather than technical solutions to technical problems.