Would be best to go back to the base screen of the selection of the payment network

https://www.loom.com/share/5559195a23504700a9301e57e47370c3

We want to give access to the first 10th subscribers (per referral count) that opted-in, on our website.

We have a DB of emails on viral-loops and through their API we could check if present in the whitelist and his rank

We can use nextjs middleware function to perform

1. API call to viral-loops to check email and the rank of the user
2. send magic.link to confirm
3. inject a cookie to allow to redirect to the actual app
4. call viral-loop to flag the participant out of the waitlist, as successfully onboarded

At the moment we assume that all the operations will be done from the same frontends, so we can infer if the contract is liquidate simply not having it in getCoins in Marina.

But this is short-sighted since external frontends may be used or simply user if restores, we need to be able to reconstruct the actual history only looking at the chain.

The best approach is:

• query the chain to see if the outpoint has been spent. (via explorer https://github.com/Blockstream/esplora/blob/master/API.md#get-txtxidoutspendvout)
• retrieve the new txid and vin
• query the speding tx, look for the right vin and check the element BEFORE the last in the witness
• decode this script hex and try to matches to the the asm of the actual branch (either liquidate, topup or redeem)

The Borrow button should be solid purple, not with gradient

Originally posted by @miyo-fuji in #2 (comment)

The app must use the custom script account of Marina.
The Fuji contract template to be imported to the account can be harcoded (contract), like the issuer and oracle public keys (02a3d89442c53fa319737bce93e0408d00f817f992a276fea1a2aa0ffbdc4a8a76 and 0256e332a5134f31dbea899e0cb7c75d3e2cff969d3958d066f8198caaee3a6159 respectively).

The flow for contract creation is a bit different from spec: since the app already knows oracle and issuer pubkeys, it doesn't need to contact the server to know those params, but rather it directly sends a complete proposal. The server then accepts or rejects it depending on the proposed terms.
The same stands for the topup flow.

To "push" wallet integration, we can show a modal on the top-right button that allows you to choose the wallet to connect

For now we only make clickable Marina option, with the others grayed out

    Provably not introduced in this PR but this input should have empty status at the initial mount, not `0`. It's easier user to start typing instead to delete the zero

Originally posted by @miyo-fuji in #102 (comment)

What methods are needed for a Nostr Signer to support Fuji app? (Marina mobile, Nostrum etc..)

• getting a pub key to be used in the covenant: would this be ok if we use the nostr pubkey? In the end the address will be different all the time as the constructor parameters will make it change, even if reuse from the same pubkey.

• Get addresses: Do need a dedicated nostr-connect method to get a fresh receiving address (for fuji) and change the address for collateral change?

• sign inputs: we should have a sign_pset method or a more low-level sign_schnorr? The advantage of the sign_pset is the possibility to show more information about what the user is signing in to the app.

• fetch blinders: as we need the factory to blind the change outputs and we may use confidential inputs for the collateral, we need to fetch this?

http://twitter.com/intent/tweet?text=<message>

The message must be encoded like encodeURIComponent

we should show a page with the follwing banner

"Fuji.Money is not supported on mobile devices - please use a browser on a desktop device"

As we gearing up for opening up the testnet beta, let's remove the login form at the beginning

If the explorer is unresponsive, cross-check for the same contract in marina.getCoins

Based on: https://blog.lopp.net/the-challenges-of-optimizing-unspent-output-selection/

Also, in case of swap error, allow user to download keys used.

The app must keep track of the price of every contracts' collateral asset so that the user can eventually add funds before the price goes underwater (to prevent liquidation).
Therefore, the app must periodically fetch the price (/oracle/:ticker alpha-server endpoint) of such assets and update the safe/usafe status of the contracts accordingly.

https://www.loom.com/share/9e08d2e927f5447092f4fe852fa02240

We should find a way to let non-tech user to dump the contracts and activities stored. Eventually we should introduce a setting wheel top right, with a a overlay menu?

When borrowing and paying with lightning, submarine is successful, but then when broadcasting tx I get this error:

Marina being enabled should be a requirement for enabling the button

https://www.loom.com/share/510e7123cd0d46cbbc87e49a1d9d316f

https://www.loom.com/share/cc468b60ff0b49e289fa19fc5cdd5238

The problem:

The app needs to know about liquidated contracts, in order to show them on the UI as liquidated.

Different approaches:

1. The app could detect which contracts are below the minimum ratio level and mark them as Liquidated. But if the contract was liquidated in the past, but now has a ratio above that limit, the app will show it as Critical or even Safe, and will have the Redeem and Topup buttons enabled, which is wrong.

2. When the app gets each contract from local storage, cross reference its txid with available coins, and if the contract was not redeemed, it will mark it as liquidated if no coin is found. Theoretically I think this solution works, what do you think?

cc @miyo-fuji @FlyingMonkey0

The current index.tsx should be hosted on ie. fuji.money main domain, meanwhile the app should start from the /dashabord page as landing and will be hosted on other domains tryfuji.com, app.fuji.money etc..

Also, pay on borrow, not on redeem.

The app must consume alpha-server's endpoints for contract creation (BORROW) or for adding funds to an existing one (TOPUP).

The flow for these 2 operations is a bit different from spec: for sake of simplicity, we'll hardcode issuer (02a3d89442c53fa319737bce93e0408d00f817f992a276fea1a2aa0ffbdc4a8a76) and oracle (0256e332a5134f31dbea899e0cb7c75d3e2cff969d3958d066f8198caaee3a6159) pubkeys so that the app is capable of creating contracts without contacting the server first.

Example https://github.com/ionio-lang/ionio/blob/master/packages/ionio/test/e2e/syntheticAsset.test.ts#L123-L152

the signer should be replaced by the Marina one

const marinaSigner = {
  signTransaction: async (base64) => await window.marina.signTransaction(base64)
}

Instead of lorem ipsum

In the video you can see alby already connected, but app show the webLN modal at every page refreh

https://www.loom.com/share/4983c2d05c7547b381ac46e65d46c0ae

Remove the Oracle price and replace with payout amount