[GUI] Export the descriptor into a file

[nondiremanuel]

It should now be possible to export an element into a file. We should use such feature for things like the descriptor, PSBTs, labels ...

We may start by letting the user export the descriptor into a file.

After that we should implement the possibility to import such file in the "Add an existing wallet" flow (we can deal this in a separate issue).

[pythcoiner]

do you want this featur to replace the actual "copy descriptor" one or you prefer keep both?

[edouardparis]

I think it is better to have both.

[kloaec]

I think it is better to have both.

Is there any use of copying a descriptor that would impact the majority of our users?
If yes, we can keep both. If not, i don't think we should keep it.

[nondiremanuel]

We don't have much information on the current way of storing the descriptor of our users, so we can try to guess. My guess is that they currently copy it to paste it in a file, so probably it would be redundant to have both. I would be keen on substituting the "copy" button for this reason, unless I'm missing some use case.

[edouardparis]

The descriptor is displayed, user should be able to copy it and for its usage I was thinking copy paste it to a terminal etc.

[nondiremanuel]

The descriptor is displayed, user should be able to copy it and for its usage I was thinking copy paste it to a terminal etc.

By downloading the file you can still open it and copy the descriptor, so this would not be disallowed (especially since people that want to use a terminal surely know how to do it). The disadvantage of course is that you need more steps.
On the other hand, having both the "Copy" and the "Download" button could be messy for non-technical users, so both solutions have their own trade-offs.

I personally lean towards avoiding confusion for average users over facilitating terminal edge-cases, but it's not a huge deal either way.

[thibistaken]

I can see value in both approaches, personally:

Copy/Paste: it's quick and easy, works well for password managers & avoids unnecessary file downloads (PDFs).

File export: it enables storage on private drives/servers, saves time vs. manual file generation, and can include helpful metadata (timestamp, wallet name, Liana branding & additional context unavailable in plain text).

Both options serve different use cases, so supporting both would provide the best user experience IMO.

[nondiremanuel]

I can see value in both approaches, personally:

Copy/Paste: it's quick and easy, works well for password managers & avoids unnecessary file downloads (PDFs).

File export: it enables storage on private drives/servers, saves time vs. manual file generation, and can include helpful metadata (timestamp, wallet name, Liana branding & additional context unavailable in plain text).

Both options serve different use cases, so supporting both would provide the best user experience IMO.

Thanks for your feedback.
Interesting consideration regarding the password managers use case. Shall we consider saving the descriptor in a password manager a good practice (and so facilitate it)? I'm not sure given the type of data we are talking about.

By the way, we are currently working on building the structure of an entire wallet backup file which would include the descriptor but also additional data of the wallet which should improve the backup & restore process and make the descriptor backup not necessary anymore (even if we will still guarantee backward compatibility).

[thibistaken]

What do you think would be the risk storing this data in a password manager? Descriptor is public data about the wallet in this context, right?

…

On Wed, Feb 19, 2025 at 18:12, Manuel Gatti ***@***.***(mailto:On Wed, Feb 19, 2025 at 18:12, Manuel Gatti <<a href=)> wrote: > I can see value in both approaches, personally: > > Copy/Paste: it's quick and easy, works well for password managers & avoids unnecessary file downloads (PDFs). > > File export: it enables storage on private drives/servers, saves time vs. manual file generation, and can include helpful metadata (timestamp, wallet name, Liana branding & additional context unavailable in plain text). > > Both options serve different use cases, so supporting both would provide the best user experience IMO. Thanks for your feedback. Interesting consideration regarding the password managers use case. Shall we consider saving the descriptor in a password manager a good practice (and so facilitate it)? I'm not sure given the type of data we are talking about. By the way, we are currently working on building the structure of an entire wallet backup file which would include the descriptor but also additional data of the wallet which should improve the backup & restore process and make the descriptor backup not necessary anymore (even if we will still guarantee backward compatibility). — Reply to this email directly, [view it on GitHub](#1547 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABCS7WUZWW77GDRB7WV4M3T2QS3RDAVCNFSM6AAAAABVHJM7LCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRZGI3DKMRVGE). You are receiving this because you commented.Message ID: ***@***.***> [nondiremanuel] nondiremanuel left a comment [(wizardsardine/liana#1547)](#1547 (comment)) > I can see value in both approaches, personally: > > Copy/Paste: it's quick and easy, works well for password managers & avoids unnecessary file downloads (PDFs). > > File export: it enables storage on private drives/servers, saves time vs. manual file generation, and can include helpful metadata (timestamp, wallet name, Liana branding & additional context unavailable in plain text). > > Both options serve different use cases, so supporting both would provide the best user experience IMO. Thanks for your feedback. Interesting consideration regarding the password managers use case. Shall we consider saving the descriptor in a password manager a good practice (and so facilitate it)? I'm not sure given the type of data we are talking about. By the way, we are currently working on building the structure of an entire wallet backup file which would include the descriptor but also additional data of the wallet which should improve the backup & restore process and make the descriptor backup not necessary anymore (even if we will still guarantee backward compatibility). — Reply to this email directly, [view it on GitHub](#1547 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABCS7WUZWW77GDRB7WV4M3T2QS3RDAVCNFSM6AAAAABVHJM7LCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRZGI3DKMRVGE). You are receiving this because you commented.Message ID: ***@***.***>

[nondiremanuel]

What do you think would be the risk storing this data in a password manager? Descriptor is public data about the wallet in this context, right?

I was not specifically talking about security (which afaict could be more or less equivalent to have an encrypted backup on one's cloud or so), but on later availability, for the user himself and/or possible heirs. I didn't think about it much, but it's an interesting discussion to have.

Instinctively I feel that having a file is more effective in conveying that this is your wallet data which you need to store than a long string to copy/paste.