daimo-eth / daimo Goto Github PK

Ulas: "I didn't realize I was creating a burner wallet"

If a user clicks on a Request or Note link,

• it opens in the app if installed
• opens in browser otherwise

The website shows the status of the request or note, explains Daimo, and links to the app store.

With "smart app banners", we can have iOS show an install link directly above the page:

https://developer.apple.com/documentation/webkit/promoting_apps_with_smart_app_banners

• Make the USDC "learn more here" link go somewhere
• Link to an explainer about Base

From Byron: consider writing & linking to own explanations. Builds trust w the user. Also can work as content marketing.

• Call bundler simulation in useSendAsync
• Display expected fee
• Set max fee to a reasonable multiple of displayed fee, no more than 2x
• Warn (and show exact maximum) above a threshold

Currently, DaimoAccount.init takes a a Viem publicClient.

This is used for exactly one purpose: pulling the latest nonce from the entryPoint contract.

Removing this dependency means that daimo-userop only talks to a bundler RPC, instead of both a bundler RPC and an ethereum JSON RPC.

Means that Daimo overall has two server dependencies--bundler and API--instead of 3. In future, we can reduce this to one by routing everything thru the API and trust-minimizing via light client.

• Byron: "what's a faucet"
• After send, return to home screen

Deliverables

• Replace daimo.super.site
• Clean, up-to-date screenshot
• Articulate Daimo concisely

Communication goals

...as delivered to Achal for potential design project.

https://daimo.notion.site/Website-de5e12c0982e4be7b5fecf32aeeea4d8

• Each screen should have one
• On the home screen, RecentHistory and the header should have one

Goal

Show whether a request for payment has been paid.

Current situation

Alice sends Bob a request link for $20.

Bob pays. Alice gets a notification saying Bob paid her $20.

However, payment is not tied to the request onchain. If either of them clicks the link again, it still says "Alice is requesting $20". Bob could accidentally pay the same request twice.

Proposed solution

Add a random bytes32 requestID.

• Add a RequestLinkScreen. When Bob clicks the link, instead of the generic send screen with amount and recipient prefilled, he sees a Alice is requesting $20 in-app, with a button to pay her.
• Payment is not a bare USDC transfer. Instead, goes thru Daimo router contract, which emits the requestID as filled.
  • Alternately, attach the requestID as extra data to the userop somehow
• Either way, indexer now knows which requests have been filled. (Note indexer does NOT have a list of pending, unfilled requests--those are offchain.)

From Rafi:

I think changing this line to .biometryAny would result in making onboarding with biometric authentication.

https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_multipath

since its not only enclaves and more like "maximum security p256" your device supports

• Locally track where note was sent.
  • If share sheet is not dismissed but completes successfully, we learn roughly where it went. Save that on the local note. Provides context later from the history screen.
• Show detailed note status from the history screen.
  • Not only DaimoNoteStatus, but also the locally-saved destination info. If none, show that note was sent from another device. Explain clearly and concisely that a note is like cash, anyone with the link can redeem. Send it to your recipient only, via a secure messenger.

eip1167 clone factory would significantly reduce the cost of wallet creation, checkout vectorized/solady/utils/LibClone.sol.

This includes the case where the faucet is empty.

You should be able to gracefully recover here.

Small UX improvement to verify newly deployed accounts on Etherscan. I think the best way to do this is to write a cron/listen for AccountDeployed events from the factory and use that to call the verify APIs (either via forge or hardhat etc.)

Was 40s, now 2min

• Add .npm caching
• Speed up or parallelize the nextjs build

Issue

account.ts, sync.ts, and chain.ts are a mess. We need a unified strategy for getting our account balance and history.

Proposal

• Remove chain.ts entirely. App will not use Ethereum RPC APIs, and instead sync through our own Daimo API.
  • (The goal for the Daimo API is to become untrusted thru the addition of a light client. All important answers will eventually come with proof.)
• Make a single object (not a network of React hooks) the source of truth for 1. which account we're using 2. balance, 3 history
• Provide React hooks that only read from this object

Local sync can look something like this

class AccountSyncer {
  // Store account info and history in MMKV
  // Update (sync) via Daimo TRPC API
}

// Replaces ChainContext
// & unlike ChainContext, the provided object is a singleton, never changes 
const SyncContext = createContext<AccountSyncer>();

// Returns account object including address, name, balance, and status 
// (is the balance fresh? are we offline?)
function useSyncAccount() {
}

// Returns a history object including recent ops and contacts.
// Ops include all userops sent from this account (claim name, change key, transfer)
// as well as inbound transfers.
function useSyncHistory() {
}

Hi there,

Just wanted to say hi from Brussels.
We stumbled upon your project and we are also working on a crypto wallet for non crypto people: https://citizenwallet.xyz

So wondering if there could be ways to team up (our plan is to develop this as an open source project like Metamask), or if it makes sense to keep two separate teams to focus on different use cases.

Let's do a call to chat more?
This is our github and our deck

I'm reachable @xdamman on all platforms.

Ping times on mobile are terrible

Download speeds are bad too = minimize API response sizes.

But ping times are especially bad = critical to do every user action in as close as possible to 1 roundtrip.

Google Fi in Paris, hotspot using a recent iPhone:

On older androids / outside first-world cities, probably worse.

Goal

This is a stub issue to illustrate a problem. No concrete solution yet.

Someone sends 1000 USDC to a Daimo address on a different L2, or on Mainnet.

• At minimum, user should be notified.
• We should have some story for how that asset can be recovered.

On testnet, we should know when someone signs up

Goal

• amount is always in token units, eg 1500000 for USDC
• dollars is always in dollars, eg 1.50

Proposed details

• In code, amount should always be bigint. dollars should be string or number.

• When persisted, both should be string.

• dollarsToAmount/amountToDollars should round trip accurately, even for amounts greater than MAX_SAFE_INTEGER

• amountToDollars returns a string with at least 2 decimal points, and as many as needed. (For USDC, up to 6.)

• amountToDollars(n, 2) returns a string with exactly 2 decimal points

• Add formatAmountToDollars. This replaces `amount

Customize the generic x sent you $y notification.

Diagnosis

History sync has an edge case where it can miss logs.

Looking up an account by its signing key allows recovery when a user uninstalls the app and reinstalls.

The Secure Enclave persists signing keys (at least for now, and at least for some period of time after uninstall).

• Add signing pubkey to account indexer. See router.ts in daimo-api--currently we are just hardcoding a few lookups for testing.
• Doing this cleanly might require adding a AddSigningKey/RemoveSigningKey event.
• Add a page in OnboardingScreen.tsx that displays iff there is already a key present in the enclave. In that case, show spinner while the account lookup is occurring, error if API is down, warning if no account found for that key (was this device removed from a Daimo account?), or success if an account was found.

(The lookup is already implemented, just not a UI with error handling. See useLoadAccountFromKey in enclave.ts )

Issue

Currently, after sending a transaction, you see a new pending transaction in history but the same, unmodified balance.

Proposed fix

• Consistent pending state. If the transaction history shows pending transactions, balance should as well.
• Potential pending indicator. Balance could show 🔘 orange circle when pending, 🟢 when confirmed, etc, similar to history entries.

• Better link
• Remove hardcoded "dcposch is requesting..."

Observed in simulator

Observed on Ansgar's phone

iPhone 13 Pro, iOS 16.5.1

Goal

Fast, scalable access to Daimo account history.

Stopgap

Currently, daimo-api implements an in-memory indexer. Every time the server starts, it loads history using getLogs() with retry and pagination. This should work fine while we have relatively few users and a short activity history.

Index Supply hosted E2PG (chain events to Postgres)

Ryan proposed following 3 options:

1. Daimo provisions a database and gives Index Supply tightly scoped user access to the database so that we can insert into a predetermined set of tables.
2. Daimo provisions a database and we configure logical replication so that Index Supply logically replicates data to Daimo’s database. Logical replication is really neat and would allow you to create your own pg indexes on the replicated tables and additionally you can also add columns to the replicated tables so that your app can do app specific things with the data.
3. Index Supply provisions a (potentially shared) database in your app’s region and provides a read only connection URL. The indexed data will be available < 100ms after the block is added to the chain. I’ve also seen really great performance from our EL/CL stack such that it receives blocks quicker than most public websites on the web.

Option 2 seems clean, so we're trying that first.

For evaluation, we'll just index testUSDC transfers via the standard erc20 integration.

Next steps

• Draft schema for custom events
  • Account creation/name claimed
  • Add/remove device
  • Create Note/Redeem Note
• Review schema with Ryan
• Draft integration PR

Currently getting logs from render.com, only shows last couple hundred lines

Need logtail or similar

• Show current note status
• If you dismiss the screen, show the home screen. Currently, app is stuck on the loading screen in that situation.

https://eprint.iacr.org/2023/939.pdf

No code published yet as far as I can tell

low hanging fruit: pass the index of the key as call data (maybe just append a byte to the signature?) directly instead of looping the whole list (and eating the computation cost of wrong verifies)

Goals

• Send to nalin.eth
• Send to bare address. Use reverse resolution, show address.+ nalin.eth on confirmation screen if applicable
• Update screenshots in GH to illustrate Daimo integrates with rest of Ethereum

If daimo accounts are ever used with dapps/contracts besides the current set written by us, they may depend on ERC1271 for Signature Validation, Implement a simple isValidSignature to prevent them from breaking.

Example: https://github.com/eth-infinitism/account-abstraction/blob/5e78f8635552e3c55fbced072056a77c8f1e8b75/contracts/samples/gnosis/EIP4337Fallback.sol#L73

Idea

Get a list of people we want to onboard. All we need for each is some kind of messenger--Signal, TG, Whatsapp, or phone number.

Send each a Note. Amounts should be tasteful--$3, $5. We don't want people to feel like they're being bribed. We send just enough that experience receiving USDC and maybe buy a coffee with it.

Super easy onboarding motion.

Track conversion. For 100 sends,

• How many claim the note?
  • How many claim in Daimo vs other wallet?
    • Of Daimo claims, how many in newly-created account?
      • Onchain D1R: of those, how many take an action the next day?
      • ...

This can double as a dogfooding and benchmarking exercise.

• However long the list, divide into chunks of 20.
• Everyone at the company takes a chunk, sends to that list as quickly as possible, timing how long it takes.
• We record in a google sheet

This is a nice end-to-end test of the app UI transitions + Enclave signing time + send latency. We can scatterplot over time, across phone OS, etc.

CreateNoteTab UX improvements

• Show that the note was created
  • Rn, just shows a disabled "Success" button. No good.
• Send button.
  • Share sheet can still shows automatically when note is created. Currently, if share sheet is dismissed, you currently end in an unfixable state where your note is lost in the ether. Send button lets you bring it up again.
• Go to home screen on successful send.
  • Once the share sheet completes successfully, go home. The sent note (potentially pending) should be the top history entry.