Add ecash section to guide #1093
Conversation
Introducing an ecash folder into the guide. This branch will be the working draft.
✅ Deploy Preview for bitcoin-design-site ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Removed old illustration. Added notes for future illustrations.
Added overview, cashu, and introduction page.
updated images for design best practices section.
Updated many images, copy, and added sections to design best practices and fedimint.
Added a bunch of new ilustrations to the design best practices section. Updated Fedimint and Cashu mint illustrations.
All pages have been updated, reviewed, and the ecash guide is now ready for a preliminary review!
| After successfully restoring your wallet using a recovery seed phrase, it is highly recommended that you generate a new recovery seed phrase immediately. This step is crucial because the original recovery phrase has now been used and could be more susceptible to synchronization risks. | ||
|
|
There was a problem hiding this comment.
Sync issues would happen only if the seed is being used in two or more places. If its not being used in the old place anymore it would be okay. Though if the seed is potentially compromised it should not be used anymore.
There was a problem hiding this comment.
So, if I understand correctly, reusing the seed phrase more than once is fine as long as there isn’t another active instance of the wallet elsewhere. For example:
A sync issue won’t occur when:
- The user factory resets their wallet and restores it using the seed phrase.
- Two weeks later, the user factory resets their wallet again.
- The user restores their wallet using the same seed phrase.
There was a problem hiding this comment.
It would be great if this means users don't have to generate new seed phrases again and again, which can be a hassle in many ways. People find it hard to not lose one seedphrase for their bitcoin...
| ### Backup process | ||
| {% include image-gallery.html pages = page.images_backup %} | ||
|
|
||
| 1. **Deterministic Wallet with Seed Phrase**: Cashu uses a deterministic wallet model, where all cryptographic keys and bitcoin backed ecashtokens can be derived from a single seed phrase. This seed phrase can be generated when the wallet is first created, or a at any point in time when the user wants to backup their wallet. |
There was a problem hiding this comment.
The seed can't be generated after the fact as previously generated could not be derived from it. In this case the wallet would have to swap proofs with secrets generated in some other way from proofs with secrets derived from the seed.
There was a problem hiding this comment.
When you say “after the fact,” do you mean after a user has used the wallet to get ecash? Does this mean the user must generate and back up their seed phrase when the Cashu wallet is created, unlike Bitcoin wallets where you can back up your wallet at any time?
There was a problem hiding this comment.
Only ecash derived from the seed can be restored later from that seed. So it depends what you mean by back up. A wallet could create a seed when the wallet is created but not show the user until they decide to go back it up later but be using the seed in the background to derive the secrets for the ecash. In this case the user can back the seed up later the still restore as the seed was being used from the start they just didn't know.
But if a wallet is created without a seed and secrets are derived randomly and then later the user creates a seed and backs it up the randomly derived secrets could not be restored from the seed. This is also true for bitcoin wallets.
I think the best ux is for the wallet to generate a seed and prompt the user back it up when the wallet it created but not enforce them to back it by reentering the words. And then maybe at a set period or if the wallet balance reaches a certain amount prompt again to backup until the users confirm they did.
|
|
||
| {% include image-gallery.html pages = page.images_p2pk %} | ||
|
|
||
| [NUT11](https://github.com/cashubtc/nuts/blob/main/11.md) is a powerful feature that allows bitcoin backed ecash tokens to be securely locked to another user's public key, which is generated by the recipient's wallet. This ensures that only the intended recipient can redeem the ecash. NUT11 enables secure offline payments, preventing double-spending. Beyond these basics, NUT11 supports advanced use cases like timelocks and multisignature (multisig) setups, where ecash can be conditionally spent or jointly owned by multiple parties. When designing make sure these functionalities are clearly communicated to users, highlighting their practical benefits and flexibility. |
There was a problem hiding this comment.
It might be worth noting that P2PK ecash is not derived from a seed phrase and thus cant be backed up via the seed phrase.
There was a problem hiding this comment.
Do you mean the actual ecash tokens that are locked with P2PK or the public key that a user generates?
There was a problem hiding this comment.
The actual proofs of P2PK or any nut10 secret are not derived from the secret so they are not backed up by the secret.
Co-authored-by: thesimplekid <[email protected]>
Thanks to thesimplekid for giving the recovery section a review. He found a point technical points that were incorrect and/or could be better worded. Saving his changes and committing them to this PR. Co-authored-by: thesimplekid <[email protected]>
| layout = "full-width" | ||
| %} | ||
|
|
||
| * **Enhanced Privacy** - Ecash uses blinded signatures, ensuring that transaction details, including user identities and amounts, remain hidden. The mint does not have access to user transaction data or balances. |
There was a problem hiding this comment.
I would maybe clarify the use of amount here. A a mint can tell the amounts involved in a individual transaction i.e. pay an invoice of x amount or swap y proofs for y proofs. What it cannot tell is the total amount of ecash anyone user has as there is no concept of accounts.
There was a problem hiding this comment.
I moved this section to the top. This now under the "Key Benefits of Bitcoin-Backed Ecash" section. Updated the copy to:
"Blinded signatures safeguard user identities and total balances. While the mint can see amounts for individual transactions (like paying an invoice or swapping proofs), it cannot associate these with specific users or determine anyone's total ecash holdings, as there are no user accounts."
There was a problem hiding this comment.
I think it would be fair to separate Fedimint and Cashu here: the whole point of federating the mint is to move further into the lower risk/less centralized direction.
There was a problem hiding this comment.
I understand your point, and I agree re federated mints. But when it comes to unfederated mints, I think the risk remains similar to that of Cashu. If we want to differentiate them we should indicate this somehow. What do you think about putting "Fedimint (Federated Mints)" at 6 and "Cashu" at 5?
There was a problem hiding this comment.
I don't see solo Fedimints as a significant use case. It's nice to get started and maybe bootstrap a user base in a cheaper/easier way, but ultimately it's not a safe way custody a lot of BTC imo (it's a hot wallet after all). The federated use case is what makes Fedimint great.
So I agree with your suggestion, maybe the fact that it assumes a federation can be a foot note, so it can be explained a bit better, (Federated Mints) might be confusing if the reader hasn't looked into it in more detail yet.
There was a problem hiding this comment.
Some of there arrows don't seem to make a whole lot of sense, especially the ones with no real origin inside the big blue circle.
There was a problem hiding this comment.
This was a mistake on my part; there should be some keys inside the circle, just like in the other examples. I tried to base this design on this illustration in the Fedimint documentation.
I'm wondering if the illustrations would be clearer if we remove the keys inside the circle that point towards ecash and Bitcoin, and instead just keep the arrows from the guardians outside the circle, leading to the ring of the circle?
There was a problem hiding this comment.
It's unclear if guardians identities should be shown. Impersonation is trivial and there might be risks associated with putting a whole profile in there.
There was a problem hiding this comment.
This is one of my biggest open questions. I had concerns about the privacy implications of showing the names and last online time of each guardian. I hadn’t considered the ease of impersonation but now that you mention it I think that’s a valid point. I still think there could be value in displaying the guardians and their status.
What do you think about showing the status of each guardian while anonymizing them? For example: Guardian 1 - Online, Guardian 2 - Online, etc..? Or do you think it would be better practice to avoid showing any guardian information and instead only display federation details?
There was a problem hiding this comment.
and last online time of each guardian
That's useful imo, guardian uptime should be close to 100% anyway. You aren't supposed to run a fedimint server on your laptop.
What do you think about showing the status of each guardian while anonymizing them?
Currently, we generate a random name for guardians on setup. They can change it, but it's not recommended. I think a guardian health page using code names and maybe random character pictures (robots? geometric profile pics like on GH?) would work great, just don't assume you have pictures and real names of guardians.
I will add guardian health info to Fedimint Observer soon, would be interesting to coordinate on how to display health status. Currently I imagine these cases:
- Ok: show latency
- High latency: show latency (>2s RTT)
- Stuck Bitcoind: if they are lagging behind the chain tip by more than x blocks
- Offline
There was a problem hiding this comment.
I’d love to collaborate on the health information. It would be helpful to understand what type of data we can display and what users would find most valuable. Latency, online status, and stuck Bitcoind (we should consider a clearer term for this) seem like a good starting point. I’ll brainstorm some designs to incorporate these.
There was a problem hiding this comment.
It's unclear if the pending state is good for users, to know it the sender has to query the spent-ness of the sent e-cash, which may correlated multiple pending transactions.
There was a problem hiding this comment.
When you say "correlate," are you referring to a privacy concern? Do you mean that the user might inadvertently leak information when they request the mint to check the status of a token?
I think it's worth considering the trade-offs between allowing the user to verify the "spent-ness" of ecash and potentially compromising privacy. Removing the ability for users to check this status might give the false impression that payments are final when, in reality, a (non-p2pl) payment is only truly final once it’s redeemed by the mint. I’m wrestling with this and would be interested to hear how others feel about it. Most Cashu wallets currently display pending tokens and give the user the ability to see them. Some even let you perform a feature where you auto-claim all pending tokens.
There was a problem hiding this comment.
Do you mean that the user might inadvertently leak information when they request the mint to check the status of a token?
Exactly! If I come back online and start checking for two sets of previously uncorrelated (from different offline txns) e-cash notes then the mint could reasonably infer that they were sent by the same user. This can be mitigated by adding delays, but that will lead to worse UX (is it ok for confirmations to be a few minutes late?).
Some even let you perform a feature where you auto-claim all pending tokens.
I think adding a "try cancel" button is reasonable. At that point you'll know if the recipient actually got them. In Fedimint we auto-cancel after a user-defined time (in Fedi currently 7d), so after that time you'll know for sure if the recipient got it or you got the BTC back.
There was a problem hiding this comment.
Out of scope for this PR i would say but on the cashu privacy correlation side there is a draft nut to address this issue where the mint publishes its spent blinded messages in rounds in this case to nostr so a user can check what is spent without revealing what its interested in. cashubtc/nuts#155
There was a problem hiding this comment.
Only one key is used in this case, the 1-of-4 and the 4 key symbols are confusing
There was a problem hiding this comment.
Good catch. I think this is clearer. What do you think?
|
|
||
| #### Cons: | ||
|
|
||
| * **High Risk** - With all control in the hands of one guardian, the risks of loss or theft are much higher. Additionally, if the server goes offline, users lose access to the federation until it’s restored. |
There was a problem hiding this comment.
It's high risk in a Fedimint context, but the same trust model as Cashu.
There was a problem hiding this comment.
I realize that in the Cashu section under the mint I don't have a pros and cons list like there is for each Fedimint setup. I will go back and include a pros and cons list under the Cashu mint illustration and make sure to include this as well.
guide/how-it-works/ecash/fedimint.md
Outdated
|
|
||
| #### Pros: | ||
|
|
||
| * **Enhanced Resilience** - Even if some servers fail, the mint remains operational, offering a good balance of security and simplicity. |
There was a problem hiding this comment.
Especially useful against scheduled downtime and censorship by hosters: by using servers from different hosters both downtime due to maintenance as well as attempts of shutting down the federation by the hoster can be mitigated.
There was a problem hiding this comment.
What do you think about this:
By using servers from multiple providers, the mint remains operational even during scheduled downtime or attempts of censorship, ensuring both reliability and security.
| #### Minting ecash | ||
|
|
||
| **1. User Deposits Funds** - The user deposits bitcoin into a mint. Typically this is done by generating a Lightning invoice through the mint and paying it. | ||
|
|
||
| **2. Blinded Token Creation** - Upon successful payment, the mint generates blinded tokens, which are IOUs of the deposited funds. The blinding process ensures that the mint cannot link the tokens to the user, preserving privacy. | ||
|
|
||
| **3. Mint provides Tokens to User** - The user receives a set of secrets (a cryptographic value that represents ownership of a specific amount of bitcoin) that correspond to specific amounts of sats. These secrets can be combined to create an ecash token of any amount denominated in bitcoin. | ||
|
|
||
| #### Melting ecash |
There was a problem hiding this comment.
Minting and melting are very Cashu-centric terms. On the Fedimint side it would be issuing (x -> e-cash), redeeming (e-cash -> x) and reissuing (e-cash -> e-cash), not sure if there's good neutral terminology.
Maybe worth having a translation table at least?
There was a problem hiding this comment.
Love translation tables. My attempt-the only neutral terms i can think of are create/pay/send
| Action | Cashu | Fedi |
|---|---|---|
| Create Ecash | Mint | Issue |
| Pay an Invoice | Melt | Redeem |
| Send Ecash | Swap | Re-issue |
There was a problem hiding this comment.
ACK. Thanks for bringing this up @elsirion and thanks for the table example @findingsov. I think this it's a great suggestion and definitely needed. I'll include this in my next update.
There was a problem hiding this comment.
Hey @findingsov and @elsirion I’ve been trying to make this section clearer. Here are the updates I’ve made–what do you think of the translate table below and the more neutral terms used in the description above the table?
There was a problem hiding this comment.
The cashu term for Reissue would be Swap. This is when one set of proofs is exchanged for another of equal value less fees with the mint.
Send more refers to creating a token from a set of proofs without having to go to the mint first if the wallet has the correct amount in its db already.
There was a problem hiding this comment.
i would clarify point 2 the process for creating is the wallet generates secrets and blinds them, then sends the blinded message (not the secret) to the mint who returns a blind signature on the blinded message. The mint does not generate the secrets and only learns the secret when they are spent.
There was a problem hiding this comment.
Thanks! I tried to summarize this in this explanation. How does this sound:
- Token Creation: Upon successful payment, the wallet generates secrets and blinds them. The wallet then sends the blinded messages to the mint or federation, which returns a blind signature on the blinded messages. The blinding process ensures that the mint cannot link the tokens to the user, preserving privacy.
There was a problem hiding this comment.
Good, i would add that it ensure the ecash creation cannot be linked to the ecash redemption.
| #### QR codes: | ||
| Unlike base chain and Lightning Network QR codes, which only provide directions for where to send Bitcoin, ecash tokens can be embedded within a QR code itself. This means that a user can claim the ecash token by simply scanning the QR code. This method is particularly useful for in person transactions or quick transfers. QR redemption also enables physical bearer assets like paper notes. |
There was a problem hiding this comment.
Would be interesting to discuss multi-QR standards (there are many, Fedi currently uses qrloop afaik)
There was a problem hiding this comment.
This would actually be very helpful. I've noticed some differences in the Cashu apps that impact scanning interoperability. For example, a QR code generated in Cashu.me can't be scanned by Minibits because Minibits doesn't support animated QRs. I'm assuming the reason has to do with the size of the QR codes. I've seen eNuts be unable to display some tokens in QR form due to their size. Do you know if Fedi has adopted QR Loop for the same reason?
If this seems to be a common need among ecash wallets due to token size, then maybe we should make a note of this in the design best practices section. I don't think we should go as far as recommending the use of animated QRs, but perhaps just include a note explaining that some wallets are using different QR standards like QR Loop to display ecash tokens due to their string size. We could add something like: "If you encounter issues with displaying ecash in QR forms, consider implementing different QR standards such as QR Loop.
| <td>Secure Against Theft (Rug Pulls)</td> | ||
| <td>❌</td> | ||
| <td>❌</td> |
There was a problem hiding this comment.
I wonder if the nuance of sufficiently large federations can be captured here. One key point of doing everything as a multisig (on-chain wallet, e-cash issuance) in Fedimint is that many guardians have to be malicious or compromised to make theft possible. So imo it's more of a yellow warning sign.
There was a problem hiding this comment.
I thought about this a for a while. I think agree with you in terms of Federated Mints. I updated it to warning triangle and pushed the following copy changes.
"Solo mints run by a single entity are more susceptible to rug pull scenarios. Multiple-guardian federations are more secure against theft, as funds are stored in a multi-sig wallet and require multiple guardians to be malicious or compromised for theft to occur."
| mobile = "/assets/images/guide/how-it-works/ecash/[email protected]" | ||
| mobileRetina = "assets/images/guide/how-it-works/ecash/[email protected]" | ||
| alt-text = "An illustration of the process of sending and receiving ecash tokens to various users" | ||
| caption = "Sending and receiving ecash tokens." |
There was a problem hiding this comment.
In the Nuts, Bob is the mint. Alice is the ecash sender. Carol is who she sends the ecash to. Should the pics here be consistent with Nuts?
Examples of Nuts with Bobmint, Alice, Carol: https://github.com/cashubtc/nuts/blob/2276462075573e26f223e8c8d575bc68d9188b39/01.md and here: https://github.com/cashubtc/nuts/blob/2276462075573e26f223e8c8d575bc68d9188b39/03.md
There was a problem hiding this comment.
Nice. I've update the illustration to show Alice and Carol. I skipped bob and just let it labeled as "ecash mint" though.
| %} | ||
|
|
||
| - `name`: The name of the mint. Display this prominently in mint listings and details pages to help users quickly identify different mints. | ||
| - `pubkey`: The hex public key of the mint. While this may not be directly displayed to users, it's crucial for security verification. Consider showing a shortened version or QR code for advanced users. |
There was a problem hiding this comment.
The pubkey actually isn't used for anything in production at the moment
There was a problem hiding this comment.
Noted! Removed from the guide for now.
|
Overall, this is a great overview and addition. Minor issue/inconsistency:
Convention for other how-it-works sections with multiple pages is that there is a back and next page button at the bottom, and on the last page the next page links to the following concept in the sidebar. |
Thanks for the catch. I've updated this on my local environment and will update in the next commit. |
…R review session on September 5th, and feedback left on draft PR. Ecash Introduction Page: * Added a privacy bullet point explainer section to key benefits. * Updated copy beneath the protocol image to clarify the distinction between Fedimint and Cashu. * Included a brief explainer in the Ecash protocols section to further detail the differences between Fedimint and Cashu. * Updated the “Creating and Redeeming” ecash image. * Changed terminology in the “Creating and Redeeming” section to reflect more neutral terms (no longer Cashu protocol-specific). Included a terminology translation table detailing terms used for Cashu and Fedimint. * Updated the “Sending and Receiving” ecash image to include users "Alice, Carol, and David." Using Alice and Carol more closely matches the users named in the Cashu documentation. * Updated the “Bitcoin Custody Spectrum” graphic to show a distinction between Solo mints and Federated Mints. * Revised the “Ecash vs Custodial Lightning” comparison table. Replaced Ecash's red x under "Secure Against Theft (Rug Pulls)" with a yellow triangle, reflecting that multi-guardian federations storing user funds in multi-sig offer improved protection against rug pulls compared to custodial lightning. This is explained in the text below the table. * Updated navigation buttons with correct links per Daniel's recommendation. Cashu: * Updated Cashu Solo mint illustration. * Added Pros and Cons section beneath the Cashu mint explainer. * Included a sentence explaining that Cashu has a much smaller codebase compared to Fedimint under the "When to use Cashu" section. * Separated Cashu wallets and services into two lists. Fedimint: * Added a "Role of Guardians" section to explain what guardians are and what they do. * Added a "Role of Gateways" section to better explain how Gateways work and what Vetted Gateways are. * Updated federation illustrations for clarity. * Changed the name of "Unfederated Mints" to "Solo Mints" to match the terminology used in Cashu. * Separated Fedimint wallets and services into lists. * Added additional Fedimint resources and a link to the Awesome Fedimint GitHub repository.
|
Feedback provided on these these sections as per your request Erik: Second half of introduction page:
Design Best Practices:This page is packed with useful design info however there is a feeling as if the overall heading structure can be made a bit similar. If this is done the mind understands the topics under them a bit more. There are some commonalities in the headings: Design Best Practices1. General ecash best practices (remains as is)
Then there's 4 common headings for both Cashu and Fedimint
Cashu1. User Interface and Experience
2. Security and Privacy
3. Metadata and Information Management
4. Advanced Features
Fedimint Design Best Practices1. User Interface and Experience
2. Security and Privacy
3. Metadata and Information Management
4. Advanced Features
|
Thanks @mouxdesign, this is really helpful. In my local environment I've pushed these changes. I will push a commit this weekend once I update the images. With that, I think we'll be in a good place for the call next week! |
Updated layout and structure of design best practices along with Fedimint images.
Updated images with custom midjourney images for all sections.
There was a problem hiding this comment.
Review for design best practices page:
Another big page with important guidance, so great you're doing this. The header image is pretty cool!
Leaving comments & suggestions in-line as well but here are some big areas of feedback (do let me know if I'm wrong coz I don't know a lot about ecash mechanics):
- I'd like to see onboarding/setup, sending, receiving, minting and redeeming sections/screens/flows? (sorry if this already exists and I missed it)
- change Title Case to sentence case in section headings
- Suggestion: evaluate whether best practices may be better placed on the respective Cashu/Fedimint page since common best practices seem to be few and users are likely to be looking for guidance on one specific solution
- After reading the entire page, my guess there's a lot of scope for trimming content; I have added suggestions where I see opportunities
|
|
||
| --- | ||
|
|
||
| Next, let's learn [private key management]({{ '/guide/how-it-works/ecash/private-key-management' | relative_url }}). |
There was a problem hiding this comment.
This sentence is not required IMO, plus it links to a non-existent page.
| Next, let's learn [private key management]({{ '/guide/how-it-works/ecash/private-key-management' | relative_url }}). |
| nextUrl = "/guide/how-it-works/ecash/private-key-management/" | ||
| nextName = "Private key management" |
There was a problem hiding this comment.
Point to the correct page with the correct link
| nextUrl = "/guide/how-it-works/ecash/private-key-management/" | |
| nextName = "Private key management" | |
| nextUrl = "/guide/how-it-works/transactions/" | |
| nextName = "Transaction |
| - file: federation-list | ||
| modalImage: federation-list@2x | ||
| alt: List of federations with QR codes for easy scanning and joining. | ||
| caption: Federations with QR codes. Each QR code contains the federation's URL, allowing users to display, and invite another person to scan and join. |
There was a problem hiding this comment.
Should be shorter & crisper. As an example:
| caption: Federations with QR codes. Each QR code contains the federation's URL, allowing users to display, and invite another person to scan and join. | |
| caption: Allow users to easily invite others to a mint/federation, by using well-placed QR codes containing the federation's URL. |
| - file: pending-transaction-details | ||
| modalImage: pending-transaction-details@2x | ||
| alt: Expanded view of a pending transaction, showing the memo, amount, and the mint that created the token. | ||
| caption: Expanded view of a pending transaction. While token is pending, anyone with the token string can claim it. |
There was a problem hiding this comment.
While token is pending, anyone with the token string can claim it.
I was looking for this – it's important enough to be included in the main body text instead of an image caption.
| - file: pending-transaction-qr | ||
| modalImage: pending-transaction-qr@2x | ||
| alt: A QR code for a pending transaction with the token string available to copy to clipboard. | ||
| caption: QR code for a pending transaction. |
There was a problem hiding this comment.
Is this the QR for a transaction or a token?
| caption: QR code for a pending transaction. | |
| caption: QR code for a pending token. |
|
|
||
| ### Metadata and Information Management | ||
|
|
||
| #### Cashu Metadata Fields: Explanation and Usage |
There was a problem hiding this comment.
Suggestions: This entire section could be condensed to include just one or two images and a few guidelines. Currently it reads like a spec without much design advice.
|
|
||
| {% include image-gallery.html pages = page.images_p2pk %} | ||
|
|
||
| [NUT11](https://github.com/cashubtc/nuts/blob/main/11.md) is a powerful feature that allows bitcoin-backed ecash tokens to be securely locked to another user's public key, which is generated by the recipient's wallet. This ensures that only the intended recipient can redeem the ecash. NUT11 enables secure offline payments, preventing double-spending. Beyond these basics, NUT11 supports advanced use cases like timelocks and multisignature (multisig) setups, where ecash can be conditionally spent or jointly owned by multiple parties. When designing make sure these functionalities are clearly communicated to users, highlighting their practical benefits and flexibility. |
There was a problem hiding this comment.
Nice feature....would be nice to see if this NUT can be packaged into a send to contact feature and then we can use existing SOPs mentioned in the Guide ...and allow importing people's Nostr or gpg keys into contacts... correct me if this is wrong, just thinking out loud.
|
|
||
| #### Auto-Swapping to a Default Cashu Mint | ||
| {% include image-gallery.html pages = page.images_auto-swap %} | ||
| Wallets can provide the option to automatically swap ecash from an unknown mint to their a default mint. This optional feature can simplify transactions by routing all ecash transactions through the assigned default mint. An auto-swap requires a lightning payment. |
There was a problem hiding this comment.
Might be nice to make this an app-level setting situated where the user marks a mint as default.
Fixing a minor typo below.
| Wallets can provide the option to automatically swap ecash from an unknown mint to their a default mint. This optional feature can simplify transactions by routing all ecash transactions through the assigned default mint. An auto-swap requires a lightning payment. | |
| Wallets can provide the option to automatically swap ecash from an unknown mint to their default mint. This optional feature can simplify transactions by routing all ecash transactions through the assigned default mint. An auto-swap requires a lightning payment. |
| #### Federation Status Display | ||
|
|
||
| <div class="center" markdown="1"> | ||
|
|
||
| {% include picture.html | ||
| image = "/assets/images/guide/how-it-works/ecash/federation-guardian-info" | ||
| retina = "/assets/images/guide/how-it-works/ecash/[email protected]" | ||
| modalImage = "/assets/images/guide/how-it-works/ecash/[email protected]" | ||
| alt-text = "" | ||
| width = 250 | ||
| height = 541 | ||
| layout = "float-right-desktop -background -shadow" | ||
| caption = "Example of a guardian status display in a wallet interface." | ||
| %} | ||
|
|
||
| Consider using a prominent, color-coded indicator to show the overall status of the federation. This should reflect whether the federation is fully operational, partially degraded, or offline. This helps users quickly assess the health of a federation. |
There was a problem hiding this comment.
Nice feature... can't this be also used in cashu mints? If yes, perhaps it can be moved to common practices section.
| #### Why Showing Gateway Information Might Not Be Necessary: | ||
|
|
||
| 1. **Cognitive Overload**: Most users are not interested in the technical details of how their transactions are processed. Presenting information about gateways, especially vetted versus non-vetted ones, could lead to confusion, as users may not understand what this information means or how to act on it. | ||
| 2. **Trust in the System**: In well designed systems, users trust that the service has selected the best pathways for their transactions. By not overwhelming users with technical details, the system can reinforce trust that the backend will manage their transaction securely and efficiently without their intervention. | ||
| 3. **Streamlined Experience**: The goal of good UX is to make the user experience as seamless and intuitive as possible. Introducing gateway information may disrupt this flow by adding unnecessary steps or considerations that the average user doesn't need to think about. |
There was a problem hiding this comment.
Consider if this section could be summarised and replaced by a simple tip as it explains why not to show gateway info.
Hey @GBKS @mouxdesign @danielnordh.
I am working on the ecash section for the design guide. I have some foundations laid down and would like to submit a Draft PR so I can preview it in a test environment.
I would like to keep pushing changes to the draft PR regularly as I will be adding illustrations, updating copy, moving things around etc...
I'm still rather new to this process so please let me know what are the best practices here.
Preview