File Your Feature Requests!

[shannona]

If you'd like to request a feature for a Gordian app, please post a new topic here.

Please be sure to tell us what Gordian app you're talking about.

Please be as specific you can about the feature.

Finally, please also tell us why you'd like to see the feature: sometimes there's a great reason for something, but we might not realize it based on just a feature request. Or, alternatively, it might let us identify another feature we're considering that could accomplish the same thing.

[coldnsteel]

Is it possible to have Polygon or other side chains added?

[ChristopherA]

I've not tested it, but Matic is registered as SLIP-44 coin type 966 when using BIP-44 based paths:

m / purpose' / coin_type' / account' / change / address_index

Thus where the Ethereum BIP-44 path for the first account is:

m/44'/60'/0'/0/0

You should be able to enter your own path and substitute 996' for the 60' and get the first account for Polygon.

[ChristopherA]

In Gordian Seed Tool, click on Authenticate, then Derive Key, then Other Key Derivation. Change the 60 to 966, and click done.

Confirm this against a known account first. If it works for you, let us know here.

[ChristopherA]

Until we have funding for greater support of other blockchains by Github Sponsors & Sustaining Patrons, I've added this as a short-term answer for this as feature request. BlockchainCommons/GordianSeedTool-iOS#112

[jasonpearce]

Gordian Seed Tool > Encrypted Data > Backup as SSKR Multi-Share > Print All Shares: A Feature Request for additional options

I have multiple feature requests. I hope it's okay that I document then individually so you may comment on them individually.

Group M of N:
On the printed document of shares, it looks like Shares includes M of N but Group does not. It might be helpful to consistently state M of N for both the Group and the Share.

What I see...

Group: 1
Shares: 2 of 3
Share: 2

What I expect...

Groups: 2 of 3
Shares: 2 of 3
Group: 1
Share: 2

[jasonpearce]

Gordian Seed Tool > Encrypted Data > Backup as SSKR Multi-Share > Print All Shares: A Feature Request for additional options

Save as PDF/PNG/GIF

A user may want to have a PDF, PNG, or GIF output instead of printing all shares to a supported AirPrint printer. Provide them the option to have different outputs along with the ability to save locally on the device or remotely onto solutions they trust like Google Drive, Microsoft OneDrive, Dropbox, etc.

[ChristopherA]

Apparently this is possible with a long-press of the share sheet. Shannon, can you investigate and document?

[shannona]

@ChristopherA I updated the manual to talk about how you can tap-and-hold individual elements to share those in various ways, including saving to files. This works for keys, seeds, etc., but it isn't possible for the SSKR shares, as @jasonpearce requests, because the only time the QR code is shown is on that print screen, which is not touchable except to print. In fact, all of the share mechanisms seem to treat the SSKR shares as a composite, not as individual items.

I think as a feature you'd need a new page called "Share Individual Shards" or something like that, which has each individual shard shareable.

[shannona]

There's some discussion of what would need to be done to resolve that in Issue 123 on the Seed Tool repo:
BlockchainCommons/GordianSeedTool-iOS#123

[jasonpearce]

Gordian Seed Tool > Encrypted Data > Backup as SSKR Multi-Share > Print All Shares: A Feature Request for additional options

Print Individual Shares

In addition to including all shares onto a single printed document (or PDF/PNG/GIF), append additional pages of individual shares that are separated onto their own page of settings.

For example:
Page 1 would be all 2 of 3 settings (what you currently provide). Pages 2 to 4 would be an individual page of settings for the three recipients or locations you indent to represent your quorum for "2 of 3".

Benefits:
Since you provide the user the ability to preview before printing, the user could chose to print just page 1, just pages 2 to 4, or all pages based on the output they desire. If you decide the provide the option to output as a PDF or PNG, you may need to provide add an interface if the user wants to separate the output.

Provide Layman Instructions
On the individual pages that the user would provide to their quorum, please add content that explains a) the purpose of the words and QR code and b) how to reassemble.

Suggested content:

About this document:

This is a Sharded Secret Key Reconstruction (SSKR) document. SSKR is a method of taking a secret (like a cryptocurrency wallet seed phrase of 24-words) and breaking it up into pieces called shards.

The secret can then be backed up by providing you and other trustees with copies of the various shards. You are 1 of 5 trustees, and 3 of 5 must gather to reconstruct the original secret.

How to reconstruct the original secret:

• This SSKR requires 3 of 5 documents just like this one. The company or individual who provided you this document should have informed you who received the other four shards.
• Download and install the Gordian Seed Tool from the Apple App Store on a supported and fully patched iOS device (iPhone/iPad).
• Use the Gordian Seed Tool to scan the QR codes of at least 3 of the 5 shards.
• Select the imported Seed > Encrypted Data > Authenticate > Share > BIP39 Words to obtain the reconstructed original secret.
• Import the BIP39 Words into a supported hardware wallet (e.g. Ledger, Keystone, Coldcard) or software wallet (e.g. BlueWallet, Phoenix, Trust).

Additional documentation:

• link 1
• link 2

Additional instructional videos:

• link 1
• link 2

[ChristopherA]

Thanks Jason, all good thoughts.

We are focused on greater support of crypto-request/response and some bitcoin PSBT optimizations for 1.4, but will likely return to SSKR for 1.5. Also on our SSKR roadmap (likely post 1.5) is being able to encrypt additional information beyond the seed along with the shares, which is particularly relevant with multisig (you need to also save the xpubs for the other keys in descriptors) and for lightning.

[jasonpearce]

Yes. I would welcome the ability to encrypt additional information with a focus on multisig and the Lightning Network. Thank you.

[coldnsteel]

Thank you Jason! My pending payment in this area of blockchain real world data is being readied for filing and the concept is based on chain of custody evidence and since law and justice are crucial for civilization and fair dealing, i thank you again as a “no more fake anything” and my new “proof of truth” protocol is very exciting! “Coldnsteel” the name of an ilder guitar teacher Hieromonk Bartholomew Diplomat, Kingdom of Hawaii, Judiciary Question what you think you know and why On Jan 18, 2022, at 6:45 PM, Jason Pearce ***@***.***> wrote:  Yes. I would welcome the ability to encrypt additional information with a focus on multisig and the Lightning Network. Thank you. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[jasonpearce]

In Gordian Seed Tool > Scan, when I attempt to scan a QR code generated by https://github.com/SeedSigner/seedsigner, I get the "Unrecognized Format" error. Feature request is to support Seedsigner QR codes so that users could use your tool to add Sharded Secret Key Reconstruction (SSKR).

[ChristopherA]

@jasonpearce: We had just noticed earlier this week that another QR from SeedSigner posted as an example on Twitter was malformed based on the ISO QR standards and thus was unreadable. We believe this is a bug in SeedSigner code somewhere.

@wolfmcnally is working on a spec for UR-based seed that will also fit in a 25x25 QR grid, with the advantage of being self-identifying and having a checksum. Hopefully, we can get @SeedSigner and others to support it. We also are looking at an encrypted option with something called crypto-envelope, however, it requires an independent security review of the architecture so it is more a Q2 item. It also is unlikely to fit in the 25x25 QR grid, but has other advantages.

Another inspiration from SeedSigner efforts is that we hope to have an option in QR Tool for printing the QR big, which then you can tape on steel to make the QR using a punch. This requires some experimentation.

[wolfmcnally]

UPDATE: It occurs to me that if you're using the binary encoding mode, that the QR reader app may simply barf when trying to read it, if it always assumes a UTF-8 string, because that is the usual assumption with QR codes. Apple does return the contents of a QR code as a block of data, not a string, however.

So I need to do a couple experiments with Seed Tool to see whether the contents are being returned accurately. If so, then there is no reason in principle that Seed Tool could not read and parse your format into a seed.

Even if that works however, I still think that you have a major usability issue. Blockchain Commons strives for transparency in all the technologies we create and promote. One of the things that makes QR codes transparent, at least in how we use them, is that we do encode text strings, and this is the expectations of most people who scan QR codes: that there is a string of text embedded inside. Most contents of QR codes, even if undocumented, are indeed text strings. But if you are encoding pure binary this expectation is broken, and runs the risk of alienating users who cannot easily look at your format.

We strive to not only document the contents of our QR codes (the UR standard) but we also strive to uphold user expectations, in the present case, encoding text strings even if there is a marginal space advantage in encoding pure binary. When I designed the UR standard I was aware that QR codes had a pure binary encoding mode, and was also aware that most readers would not be able to interpret it in a way average users could look at. So we went with a technique for URs that use the limited subset of characters that can be used by the QR alphanumeric encoding mode, which is why a Bytewords encoded seed obtains the same 25x25 module size as your "standard" encoding using the numeric encoding mode.

[wolfmcnally]

SECOND UPDATE: The standard high-level API that Apple provides for reading QR codes is documented here. It only returns a string, if it can be decoded as one.

While it provides no direct affordance for accessing the raw binary data, there is a discussion on StackOverflow about a possible "side-door" to access it, but there are concerns that Apple would reject any app that uses it, as it is not an official API.

There is also a summary of this issue which goes on to describe an approved lower-level API that requires significantly more work in passing each frame of video to the Core Image CIQRCodeFeature detector that returns these fields. Additional work must be done on the raw data to strip the QR code ECI headers. There is example code to do this here.

All in all, there is significant extra work involved to read binary QR codes on Apple devices, and I would expect that this work will only be undertaken by highly motivated developers who want to support a particular binary QR code format.

[newtonick]

Thanks for doing this leg work around binary QR codes on Apple devices. I don't think any of the Apple api limitations will keep the Seedsigner project from pursuing more experimentation and research into the binary seed qr format (it's not even an option in released seedsigner software as I write this).

Does the seed tools app support the 'Bytewords Compact Seed Format'? I tried scanning the QR in the hackmd article and got an error. I assume no other wallets or coordinators are using it yet? As someone who contributes to the seedsigner project I'd be interested in adding this format as an QR output option in the future.

[ChristopherA]

@newtonick We were inspired by the @SeedSigner work to see if we could also support at 25x25 QR, which it looks like we can as UR uses only ASCII characters that the QR standard compresses. The additional advantage of the 'Bytewords Compact Seed Format' is that there is a small CBOR prefix and checksum, which helps with self-identification and preserves integrity.

We also want one that works with SSKR shares (a better alternative to SLIP39) but that hasn't been fully explored yet.

@wolfmcnally just puzzled this out this week, so it will be in a future release. Typically it will be in our free TestFlight beta for at least a week before, so you might want to sign up for that.

We'd love to work with you (and others) on supporting UR seeds, keys, descriptors, etc. for wallet interoperability.

[wolfmcnally]

To clarify @ChristopherA 's remarks just above: a ur:crypto-seed such as:

ur:crypto-seed/oyadgdwtlskskpwpwkwscfbdtbwdgdfmwzlpgrctfwwzry
---------------                                               UR header
               ------                                         CBOR structure
                     --------------------------------         Seed
                                                     -------- Checksum

...when transformed to upper-case produces a 29x29 module QR code. This is due to the ur:crypto-seed type indicator, the CBOR structure, and the four-byte (8 letter) CRC-32 checksum at the end. This pushes the requirements for module size over the desired minimum of 25x25 modules.

The experiment I performed was to see whether the bare Bytewords, including the checksum but without the UR header or CBOR structure, would encode to 25x25, and it does:

WTLSKSKPWPWKWSCFBDTBWDGDFMWZLPGRVDSRBBWF
--------------------------------         Seed
                                -------- Checksum

However to add the necessary CBOR structure to make the data self describing would require approximately another six bytes (12 letters) and that would probably take us over the limits of a 25x25 module QR code.

So while the above would not be perfectly self-describing as with the full UR format, a person encountering the QR code could determine 1) It is in Bytewords format, 2) Whether or not its checksum is correct, 3) The length of the message is 16 bytes (128 bits). From this they could deduce that the payload is probably a seed.

The ur:crypto-seed format, while of variable size, also supports additional metadata fields such as the date the seed was generated and a freeform UTF-8 notes field.

[jasonpearce]

I hope I'm not abusing you with feature requests. I simply like what you've started and want to provide feedback and ideas.

In Gordian Seed Tool > Scan, when I attempt to scan any multifactor QR backup code generated by Specter Desktop or Sparrow Desktop, I get the "Unrecognized Format" error. Feature request is to support multifactor QR codes from both Specter and Sparrow.

In one of those apps, it provides multiple QR code export formats for different kinds of hardware wallets. Some of the QR codes were animated, others were not. I tried them all (Bluewallet, Cobo, Keystone, Specter, Sparrow, etc.). The Gordian Seed Tool didn't accept any of them.

My desired use for your application would be to backup and securely store most singlesig seed phrases and multisig wallet configurations from a variety of popular software and hardware wallets that use QR codes. So far, most of my efforts and testing are failing or appear to be incompatible.

Is there something I could do or test better that might be more helpful or constructive? If so, please let me know. Thank you.

[ChristopherA]

I think the your Specter & Sparrow QR problems are a different problem than the @SeedSigner compact QR problem. Can we get your version numbers for both, or an example? Or steps to a specific generated QR that failed?

/cc @craigraw @stepansnigirev @k9ert

[ChristopherA]

@jasonpearce

We have a new beta version of Gordian Seed Tool for iOS and macOS 1.3.3 (46) in Testfilight at https://testflight.apple.com/join/0LIl6H1h

• Key Export: Fixed a bug where changing the network wouldn't always update the derived ur:crypto-account to reflect the change.
• QR code display: Reduced the threshold for a QR code to be animated from 800 to 600 bytes per segment.
• When printing SSKR shares two new options have been added:
  1. Before you could only print multiple share "coupons" on each page, which had to be cut apart. You can still do this, but the default is to print one share per page.
  2. All the information necessary to identify the shares and their group membership is now on a "summary page" at the beginning of the print job. This can also be turned off.
• Added an interface for exporting individual SSKR shares as ByteWords, ur:crypto-sskr, or QR code.
• All interfaces for generating and printing SSKR shares now display a "Generated" date and time to ensure that shares are compatible.
• The summary page for printing SSKR shares now has the notice: "The following verification words may be used to establish that printed shares are part of this SSKR share collection. Check them against the last four ByteWords of each share. Only shares that were created at the same time can be used together."
• Printed seed backup pages now include a "Derivations" section containing the Master HD key fingerprint and Ethereum account ID that can be derived from the seed.
• Fixed a bug when printing a seed backup page where the text in the UR section would sometimes be very tiny.
• Fixed bug where repeatedly printing or exporting a set of SSKR shares without leaving the SSKR presentation screen caused the shares to be regenerated and therefore incompatible.

Could you signup for TestFlight and download this test release and give us your feedback on this version? It is allways a challenge to get fresh eyes on a new version for weird edge-cases that core designers can't see.

[jasonpearce]

Thank you for considering and implementing some of my ideas and feedback. I've yet to try a Test Flight / Beta, but will give it a shot tomorrow to provide you some feedback.

[jasonpearce]

Nice work. I'm again grateful that you considered some of my ideas. The intent of my comments is to provide helpful feedback.

Print All Shares (selection issue)
On an iPad Pro, I sometimes had difficulty selecting the "Print All Shares" option between "Export Shares Individually" and "All Shares as ByteWords." The selection process would sometimes occur in the first vertical orientation. Once I rotated to horizontal and back to vertical, the issue goes away. I had a hard time reproducing consistently, so it is maybe user error.

Print All Shares > Summary Page:
A big improvement.

I assume this is a page I can print multiple times to include with each group and share if necessary. It doesn't overly weaken the the security if the last four words are shared to everyone in a group or among multiple groups?

Feature: It would be helpful if some kind of introduction or instructions or link to instructions existing on this summary page. If it is to be used to backup a seed phrase for inheritance purposes, the name of your App along with some instructions would greatly help the recovery process.

You could have a QR code to download your app from the iOS and Android app stores.

Then again, I can write up my own instructions to provide to each user. But having it on the same page helps prevent that information from being lost or separated over time.

Print All Shares > Individual Pages:
Also a nice improvement.

I recommend having both Group X of Y and Share A of B on each page. If someone had only page (Group 2 of 3, Share 1 of 3), they without a copy of the Summary Page they wouldn't know the context. Then again, I could just print multiple copies of the improved summary page.

Print All Shares > Print > (long press) Print > Save to Files
I recently learned how to save the document as a PDF in iOS Files. It's a hidden feature that requires a long press on the third Print option. Perhaps you can make this easier by offering a "Save All Shares as a PDF" option.

If someone wants a separate PDF of each Individual Page to Save to Files, they need to use caution to "print" just 1 page at a time without going back too far to print the next page. If they go back too far, your SSKR random number generation would create new QR codes. Granted, you warn them, but it's a mistake I made and had to start the tedious process all over.

I'll comment on Export Shares Individually next...

[jasonpearce]

Export Shares Individually
Great start, but not as useful as I hoped.

I love that you provide three export options: ByteWords, UR, and QR Code. I'm seeking a Combined option like the Print Individual Pages. A PNG or PDF that provided context like this:

Group 1 of 3, Share 2 of 5
ByteWords: tuna acid ... puff wasp
ur:crypto-sskr/goay..dapk
QR Code
Produced by Gordian Seed Tool on 2022-12-02.

I'm worried that exporting a ByteWord, UR, or QR Code without context is a recipe for mixing up the distribution to individuals/heirs or adding complexity to using them to recover a seed phrase.

Export Shares Individually > Share > Save Image or Save to files
Are you able to pass a file name with a standardized naming convention?

If I save a QR export to photos via Save Image, the filename is IMG_0069.jpg. It would be better if you automatically named it Group-1-of-3-Share-2-of-5.jpg.

If I try to save a ByteWord, UR, or QR code to Save To Files, the default file name is just "text.txt". It would be better if you also automatically named these files.

If I try to send as an Email, you could populate the Subject to state "Group 1 of 3, Share 2 of 3". (I know, the user's Sent folder would have all of the pieces for reassembly, even if he emailed nine different shares to nine different people. So not a great practice.)

In short, if you add a naming convention for images and files, it would make this Export feature more helpful and less tedious.

Export works
What you've created, however, works. I didn't observe any bugs.

[ChristopherA]

The file name issues we are working on. Sometimes Apple defaults gets in our way to do the right thing.

[ChristopherA]

Thank you for the detailed feedback 🙏

[ChristopherA]

It doesn't overly weaken the the security if the last four words are shared to everyone in a group or among multiple groups?

The words are only from the checksum, thus contain none of the sskr shard material. Mainly useful so you can request it back.

[ChristopherA]

It would be helpful if some kind of introduction or instructions or link to instructions existing on this summary page.

I’ve asked @shannona to look what else we should put on cover page.

Part of the challenge is that SSKR can be used in different ways, self-sovereign singlesig, self-sovereign multisig, social key recovery, and with others various multi-person multisig or collaborative custody.

If it is to be used to backup a seed phrase for inheritance purposes, the name of your App along with some instructions would greatly help the recovery process.

We have designed SSKR in hope that others will implement it as an ecosystem standard. Right now you can recover two ways, our apps on iOS & Mac, or on Linux from the command line. We hope soon with some of the dedicated hardware signers like Passport.

You could have a QR code to download your app from the iOS and Android app stores.

But it still probably can’t hurt to point to a web page of apps supporting sskr .

[ChristopherA]

I recommend having both Group X of Y and Share A of B on each page.

The design of these pages has been somewhat of a improvised compromise to date, as in social key recovery scenarios we are also wanting to avoid information in shards that might allow to identify who and how many others they might need to coerce to get additional shards. Thus the identifiers are only the checksums, and any shard can only know how many shards are in their group, not how many other groups or how many shards in those groups are needs for quorum.

But these are all tradeoffs. Increasing security also likely reduces resilience. As we advance these standards and more adopt them we’ll likely need to adapt.

[wolfmcnally]

In general a person who receives an SSKR share also needs to receive instructions from the sender that are too case-specific for us to provide. The most general instruction we could provide would be "Keep this safe and return it to the person who gave it to you upon request. When returning it, make sure you are returning it to the actual person who gave it to you."

How a trustee keeps it safe is outside the control of the sender, and thus necessarily up to the trustee, including how to avoid confusing it with other similar items they may be holding, and what medium to store it in.

If a trustee receives it digitally, they could print it out and save the physical representation somewhere, or they could keep it digital and keep it in a password manager or even just a file on their hard drive, as long as they can find it.

This is part of why social key recovery has redundancy like M of N thresholds: a trustee may become uncontactable, or the share they are holding could become lost or corrupted.

[wolfmcnally]

A corollary to the above is that, other than keeping their shares safe, and knowing who to return them to, trustees don't need to know anything else about what they're holding: not the number of groups, not the number of shares within each group, and not the group threshold or share thresholds within each group. The share itself includes a couple of these items, and we provide a bit more information on the printed share pages such as the group number and generation date, primarily as a convenience to the owner when distributing the shares. None of this information is for the benefit of the trustee.

[jasonpearce]

Thanks @ChristopherA and @wolfmcnally for your comments. I can see that you're focused on a wide range of use cases and standards (as you should be) that go beyond the subset of use cases I have in mind -- which I appreciate.

The use case I have in mind:
A user has a multisig wallet with geographically distributed hardware wallets. They want their geographically distributed family members to inherit the funds secured by the multisig wallets when the user and his/her spouse dies.

In this case, there's a reasonable degree of trust (they are loved family members). While the multisig and hardware wallets are the primary X of Y means of spending those funds, each hardware wallet's backup seed phrase should also be distributed and recoverable.

Already, while writing this use case I quickly understand that each use of your tool and SSKR is too specific to each user to account for the right balance of documentation or secrets (e.g. you are right). In my case, I want to favor ease of use over secrets and security (because I want non-technical family members to be able to recover funds). The security in this case study comes from geographical distribution of information, but your tool would have no way of knowing that.

In my case study, I'd want to provide each family member paper and a USB jump drive with the SSKR shards, which is why I would prefer better X of Y notation and filename naming conventions. You've made great points about other case studies that would want to keep that information secret.

Thanks for your time and contributions to security.

[shannona]

Per @jasonpearce, I'd suggest the following additional changes to the "Print" overview page:

Archived from **Gordian Seed Tool** vX.XX.
M of N sharding.

Gordian Seed Tool App available in the Apple App Store.
Code available at https://github.com/BlockchainCommons/GordianSeedTool-iOS.
Alternate software available at https://github.com/BlockchainCommons/seedtool-cli.

Store this overview in a safe place. Give individual share coupons on subsequent pages to friends or family and record their initials on this page for your reference. (Do not keep the share coupons together! Do not list out full names!)
 
You will be able to restore your seed by recovering M of your N coupons. The easiest way to do so is to scan the QR code for each share into Seed Tool using the QR/Scan icon at top. You can alternatively enter the words or the `ur:` into Gordian Seed Tool, the seedtool-cli command line program, or any other software that supports SSKR shares.

[checksum #1] Given To:  _____________
[checksum #2] Given To:  _____________
[checksum #3] Given To:  _____________

The verification words, above, may be used to establish that share coupons are part of this SSKR share collection. When you recover your coupons, check them against the last four words of each share. Also be sure that each share has the same date and time on it: only shares that were created at the same time may be used together

I'm hesitant to put in a QR to download the app because that might muddle the QRs that define the shares on later pages. Hopefully the source code URLs will take care of that in a worst case.

For the individual pages, I might just add the admonishment:

Please store this SSKR share in a safe place! It may be requested back at some time. Please ensure that the right person is requesting it back by meeting them in person or by talking to them on a video call. Thank you for your help!

[ChristopherA]

@jasonpearce @jblachly @moskovich:

The next beta of Gordian Seed Tool 1.3.3 (47) is available on TestFlight for both macOS and iOS.

• All actions that invoke the Share Sheet (including long presses on many of the displayed data items in the app) now have sensible default file names that are offered if the Share Sheet "Save to Files" option is invoked.
• On iOS, the Copy to Clipboard function now erases the clipboard 1 minute after the copy.
• On macOS, the Copy to Clipboard function is now available from the Share Sheet. Unfortunately, macOS does not support the self-erasing clipboard feature.

Here is a current list of all the default file names saved when using share sheet to file system related services:

Could you take a look at this TestFlight, and your own save-to file system needs, and see if these choices work for you?

We tend to be too conservative here for purely self-sovereign recovery scenarios (as @jasonpearce described above "multisig wallet with geographically distributed hardware wallets…geographically distributed family members to inherit the funds secured") as opposed to more pure social-key recovery or multi-person multisig scenarios. There is a balance here between security against collusion and compromise, and reliability for resilience.

[jblachly]

The share function has taken an unintentional step backward IMO:

Now, when I share ur:crypto-hdkey by text or email, it shares a /file/. This is undesirable, at least in the case of text message (email is debatable). AFAICT it still works over iMessage, but I was unable transmit over carrier SMS.

Given that the file name is not really a prominent feature (if at all) when sharing over text message, I suggest that that medium be limited to just sharing the ur: text string directly, as in prior versions.

[wolfmcnally]

I'll look into this.

[ChristopherA]

@jblachly:

when I share ur:crypto-hdkey by text or email, it shares a /file/

Interesting dilemma. I can see others wanting to send it as file. But I can see your point.

I know I never ran into this problem as I largely use the iOS version and use the copy to clipboard share sheet option when I want to paste in Signal, text or email. With this version, we now can copy to clipboard in macOS (this was not available before), and we've restored the erase clipboard function (only on iOS, not macOS).

Is there some reason you'd prefer not to use the clipboard share sheet?

[jblachly]

I'm definitely supportive of the copy to to clipboard functionality. Seems very useful. OTOH, it is potentially dangerous if the user has Handoff enabled because then clipboard contents dan be read by other Apple devices including desktop if in Bluetooth range, and a clipboard sniffer on the desktop could grab it.

I'm also using the iOS version, and the key advantage of the "share" function in any program is to rapidly share to a number of specific destinations (messages, email, notes, etc). Canonical behavior if that function in any APL is to share a native string or object -- not a file encoding a string. I'd argue this violates what users expect in a pretty significant way (I myself took a few minutes to figure out what was happening as I had used the prior version which sent strings)

Does Swift/iOS dev kit allow different formats (string/file) per destination selected in the share dialog?

If yes, great. If no, I would vote to deprecate the file share through that mechanism and instead have a separate file/save icon or menu item.

[wolfmcnally]

iOS is pretty flexible about how things are shared via the Share Sheet. In the last beta release we replaced the regular "Copy to Clipboard" function with a custom one that brings back the auto-erase feature that pre-Share Sheet versions of Seed Tool supported. It also had the added benefit of adding a "Copy to Clipboard" function to the macOS Catalyst version (albeit without the auto-erase feature.)

[shannona]

Some minor changes that I think might help clarity:

UR for response -> UR response
UR for key response -> UR response of key
UR for response -> UR response
UR for PSBT -> UR response of PSBT (assuming this is also a crypto-response? If not, just PSBT UR)
SignedPSBT -> SignedPSBT Base64
Base58 -> Key Base58

Generally I think that aligning as much as possible to [content] [encoding] [identification] will help keep things consistently clear.

[ChristopherA]

@shannona I'm wondering if it should instead be [identification] [content] [encoding] so that similar items together?

[jasonpearce]

Testing 1.3.3 (47) > Backup > SSKR > Export Shares Individually

In general, excellent.

QR to Photos: Photo file names are still IMG_0074.png instead of SSKR QR DRUM MONK IDEA DULL.png
QR to Email: Subject nor Body have the SSKR QR DRUM MONK IDEA DULL.png naming convention
QR to Files: Excellent (though no Group information, but I assume that’s by design)

Bytewords or UR to Files: Naming convention is good, but BlueWallet attempts to open the files when selected (but does nothing with them). I don’t recall that happening before. They are .txt files, so I’m not sure why BlueWallet tries to open them.

[wolfmcnally]

The new version 1.3.3 (48) in Test Flight today has a much improved naming scheme for anything that supports Save to Files. Please let me know what you think. Opening a new issue directly at the Seed Tool repo will bring a faster response.

[jasonpearce]

Testing 1.3.3 (47) > Backup > SSKR > Print All Shares

Also great. Does not yet have the additional wording and instructions mentioned earlier.

Print: Printing worked well.
Print > Long Press > Files: Thanks for also adding your naming convention .pdf.

[jasonpearce]

Testing 1.3.3 (47) > Backup > SSKR > All Shares As…

To Files: Also worked for both options. Also with your naming convention .txt. When select from files, Blue Wallet also tries to open both of them (but does nothing).