Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move signing to external wallet #2

Open
DougAnderson444 opened this issue Dec 2, 2024 · 8 comments · May be fixed by #3
Open

move signing to external wallet #2

DougAnderson444 opened this issue Dec 2, 2024 · 8 comments · May be fixed by #3

Comments

@DougAnderson444
Copy link
Contributor

DougAnderson444 commented Dec 2, 2024

let sv = mk.sign_view()?;

This signing needs to be done from an external function.

@DougAnderson444
Copy link
Contributor Author

I have this change compelted here but I will wait for cryptidtech/multikey#3 and cryptidtech/multisig#2 to resolve before opening the PR, and the dependency tree is downstream from those deps.

@DougAnderson444
Copy link
Contributor Author

nudge @dhuseby

@dhuseby
Copy link
Member

dhuseby commented Jan 25, 2025

I just merged the multisig PR. Thanks

@dhuseby
Copy link
Member

dhuseby commented Jan 25, 2025

And poked Mike about the blsful update to crates.io

@dhuseby
Copy link
Member

dhuseby commented Jan 25, 2025

just fixed the multikey one

@DougAnderson444 DougAnderson444 linked a pull request Feb 14, 2025 that will close this issue
3 tasks
@dhuseby
Copy link
Member

dhuseby commented Feb 25, 2025

@DougAnderson444 I've been thinking for some time that there should be a standard protocol for activating external cryptographic services. Here's a proposal I made years ago for abstracting the cryptographic operations out of git: https://github.com/cryptidtech/git-cryptography-protocol/blob/main/Git%20Cryptography%20Protocol.md

It would be cool to generalize the proposal, update the spec, and implement it in Multikey/Multisig

@dhuseby
Copy link
Member

dhuseby commented Feb 25, 2025

FIDO is similar I think.

@DougAnderson444
Copy link
Contributor Author

Yeah that's interesting. I think ultimately something like this is what is needed as part of the evolution.

I'll give it some thought. Implementing something like that would require an overhaul to the public API, likely having the user implement some signing trait that returns a future, instead of using a closure like it does now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants