# Email and Backend Services Strategy.

### Preamble:

As part of my current residency proposal, we're currently building out an email service for nouns.build. We see a lot of benefits to adding email to the product as well as some potential risks -- chiefly around holding user data.

It is important to note that while I am writing this for email, we can also extend this reasoning to any backend service that has a centralized store of user data. The strategy that we choose for this service can be extended to other services like it.

## Problems

Implementing an email service seems like it should be relatively straightforward, however, handling user data has some pretty serious implications. Why?

- User data like an email address is stored on a centralized database. With DBs, we need to decide how we store that information, who gets to handle it, and who gets to see it.
- Centralized databases come with security concerns.
- Centralized databases cannot be governed with onchain tools (e.g. a roles engine like Hats protocol)
- Connecting a wallet to an email could unintentionally 'dox' a user if they are unaware of the risks, in the case of a breach.

## The Solutions

The product team has identified two main paths:

**1. Subscribe With wallet.**

This is a process where a user will make entries into our database using their wallet.

**2. Email Only.**

The user inputs their email, our DB gets a list of emails and nothing else.

**3. ENS**

The user updates their email information on their ENS. They sign with their wallet just like solution 1, however, they do not input their email information. Instead, they update their ENS with their email. Therefore we do not have custody of their email.

## Considerations

Here are the main things we need to address.

- Custody, Liability, Roles, and Privacy
- Security.
- Work involved (cost).
- User Experience.
- Opportunity

For each potential solution, I will cross-examine it against these considerations.

## Custody

#### Sign With Wallet: 🙁

We would custody more information with this solution.

In this situation, we would be holding the user's email, and it would be connected to their public address.

**IF** the user is unaware of how this email is being custodied
**And IF** the centralized DB is breached

They could be doxxed and that information could be leaked.

Also, that data is available to the product team as well as the Zora team who have access to the Github Repo, and therefore the key to the DB.

#### Email Only: 😐

We are only holding the emails. This means that in the case of a breach, the attacker would only get a list of emails.

This does still have its downsides, but it does add a layer of privacy.

#### ENS: 🙂

Interesting solution here.

This solution has all the risks that Sign With Wallet has with two major distinctions.

1. We are not holding email data at all
2. If the user has already added their email information to ENS, then it is already public data.

We gain no additional liability from using this solution.

The only downside here is that to use the email service the user must expose their email to the public. However, any user in this space should already be operating under this assumption when using email services. This solution makes this crystal clear.

## Liability

All cases: 😐

In every case, we should make it abundantly clear to the user that they are **opting in** to this service, and that we cannot be held responsible for what happens.

## Privacy

All cases: 😐

We cannot reliably promise privacy to the user in any case. With all the security teams and billion-dollar infrastructure Web2 behemoths provide, they still cannot promise pure privacy as a breach is always possible, somewhat likely, and nearly impossible to detect. We, with an extremely small development budget, could not promise this either.

The new wave of privacy and ZK tech is not ready for adoption at the application or it would require us to encrypt data and hold the key for decryption.

We cannot afford either solution and therefore should not promise privacy in any case. Terms and services should apply with each solution, perhaps except ENS where the user already updated their email onchain.

### Security

We plan to implement an 'off the shelf' DB service like Neon, that already takes care of some aspects of security. And we would grant written access to

We could add additional security by granting 'roles' to various resident engineers as needed. While the keys to the DB could result in someone querying the DB for all the data, the roles would gate access to the dashboard.

## Work Involved

#### Sign With Wallet 🙁:

- Would require signing entries into the DB.
- Would require more complex stores of info, when compared to email only.

#### Email Only 😐:

- Very minimal, however, it may require more work to link a bidder to an email. May require some work with caching.

#### ENS 🙁:
- Would require signing entries into the DB.
- Would require more complex stores of info, when compared to email only.
- Would also require UI to get the user to add their email to ENS. For V0, this could be a link.
- More complex and requires working across protocols. Depending on the scope, I may need to drop other commitments to make this work well.

## User Experience.

#### Sign With Wallet 🙂🙂:

- By far the most intuitive and easy process.
- State persists (don't need to re-enter email for every event you subscribe to)
- Add email once, then subscribe at will.
- Can greatly improve UX in many other facets of the application (more on that in the opportunity section)
- Easy to unsubscribe

#### Email Only 🙁:
- Easy to get started. Only need to input your email.
- Cannot get exact events (e.g. if you are outbid)
- Need to subscribe to every event separately
- Can be used to spam users (no check on if email belongs to the user)

#### ENS 🙂 for ENS users, 🙁 for those who don't use ENS:
- State persists (don't need to re-enter email for every event you subscribe to)
- Add email once, then subscribe at will.
- Many users already have email added to their ENS. Most crypto natives already have ENS.
- Worth noting that many users who have ENS may not want to expose a public email. They could make a new email, but would they check it?
- Requires an onchain TX to add an email.
- This service would not be available to accounts w/out ENS.

## Opportunity

#### Sign With Wallet 🙂🙂:

A centralized store of user-specific data is what makes Web2 UX great. Not having a centralized store of user data is what makes Web3 UX bad.

As users, we'd like to be able to interact with events and customize our experience. Doing this with onchain tools is very burdensome.

With a store of user Data, we could tell the app what types of DAOs we're interested in, what we want to see and don't want to see, and we can do it all without necessarily broadcasting that data onchain.

#### Email Only 🙁:

Our hands are pretty tied with this solution. We only get to alert the user of a few select onchain events. We don't know which address that user has, so we can't extend this service to any other user data.

Imo, there's a pretty large opportunity cost here.

#### ENS 🙂:

This solution is more constrained than signing data directly into a DB. We would essentially be using the DB to record which events the user wants to listen to, but leaning on ENS for any user-specific data.

In cases where the data held isn't sensitive (e.g. some simple preferences), we can still rely on our DB.

It's worth mentioning that integrating ENS would likely be seen as an exciting collaboration with the protocol. It could help us get some users, press, and potentially even some retroactive funding. By creating a viable ENS email system, we would be demonstrating a clear ENS use case and would attract users to their protocol.

While the UX would certainly not be as good as the Web2.5 solution of Signing to a DB, it would help create better Web3 solutions.

## Recommendations:

We should assume that everything that gets loaded onto a DB can be breached. We are not a security firm or a billion-dollar tech company, so guaranteeing security and privacy is a moral hazard. From what I can tell, tech companies use terms and conditions to shield themselves from liability. We should do likewise (ENS may be a special case where we don't need to, but I'm not sure.)

On the product side, I believe that the hype around collaborating with ENS is worth the UX detractors. We should experiment with using ENS, and if it works well, use that as our solution. If not, we fall back to Sign With Wallet.

After writing out this doc, I feel that Email Only is too limited and brittle to be a good long-term solution.