This involves the use of a QR code containing server address and necessary information, rather than H(R)+routing. The QR code would include one or more routes from rendezvous points, with the payer using an alternative method to locate them without communicating with the payee. The recipient would signal acceptance of multipath transfers, allowing the client to decide whether to perform a multipath payment. In case of payment failure, the client can try again with a different path. However, the retry logic is still being developed. In situations where there are multiple paths to the payee, the client can attempt to reach the endpoints in a specific order before failing. However, if payment failures are common, this approach may not be sufficient.The concept of a special payment request protocol that enables negotiation of multiple routes and details between payer and payee is being discussed. This involves the payee's QR code containing a server address and necessary information for the payer to establish a connection. The payer can then request H(R)+routing and continue to ask for more routes or retry failed payments as needed. Maintenance servers could facilitate this process, with each coffee shop potentially having its own. While a complete retry logic for multipath transfers is not yet in place, clients may soon have the option to decide whether to perform such payments based on the recipient's acceptance.The email conversation explores the advantages and challenges of maintaining multiple channels in the Lightning Network. Having a single channel has drawbacks, such as relying on a single peer, which can be a point of failure. On the other hand, opening multiple channels offers benefits in terms of fault tolerance and privacy. However, there are several questions that need to be addressed, including the number of channels to open, the fee per channel, and the maximum funds that can be relayed. Insufficient capacity along the payment path is also an issue that needs to be addressed. Abstracting the underlying mechanics can confuse users, and it is suggested to adopt the Bitcoin model of having an available balance and an unconfirmed balance across all channels. While a single channel doesn't solve all the issues, it makes them clear to the user. Starting with a simple system and adding features gradually is proposed as a strategy for wallets.Having multiple channels on a phone that can relay third-party payments presents various challenges. If the app is not running at all times, there is a risk of a channel being unilaterally closed due to HTLC expiration. Users need to decide the number of channels to open, the fee per channel, and the maximum funds that can be relayed without interfering with their own payments. However, most users prefer not to be burdened with these decisions and simply want the app to function seamlessly. While combining multiple channels is straightforward, there seems to be an asymmetry where payees can generate multiple routes while payers cannot pay if no channel has sufficient capacity. One solution is to ensure users understand that the balance is multidimensional. Another option is to bilaterally close existing channels before creating new ones and recombine their balances. While a single channel may not solve all the issues, it makes them apparent to the user, and developers can choose between single or multiple channels based on user needs.Anton Kumaigorodskiy shares reasons why a mobile Lightning Network wallet should only support a single payment channel. It is suggested that mobile nodes will be offline most of the time, making them ineffective for relaying payments. Additionally, locking funds in HTLC for extended periods may not be beneficial for users. On the other hand, Christian argues that two channels with 50% each are better because they prevent reliance on a single peer for payments. They also suggest that combining multiple channels is straightforward and can be achieved by the endpoints. While users may not care about relaying other people's transactions, they may want to offset their own fees or earn rewards. Christian emphasizes that the number of channels does not directly affect the user experience, and the underlying connections do not have to be visible in the interface. Anton plans to design their Android LN wallet to support a single payment channel, but is open to feedback.In conclusion, supporting only a single payment channel in mobile Lightning Network wallets has several advantages. The majority of mobile nodes are likely to be offline most of the time, making them ineffective for relaying payments. Locking funds for extended periods may not be in the user's best interest. A single channel with a larger capacity allows for larger amounts to be sent and received. Additionally, having a single channel simplifies the user interface and improves user experience. Anton plans to incorporate support for a single payment channel in their Android LN wallet, but welcomes feedback on any important factors that may have been overlooked.