Configuration option to disable metadata sharing now always sends without optional parts, and complains if you scan a code with required parts.
Lots of quality of life fixes done today. It no longer shows metadata choices if there is no choices to be made (none was request, or those that was requested was all previously known)
i've now replaced the old phonegap barcode scanner with bitpays scanner plugin, which lets me add fully customized UI on top of the preview.
i saw your video on CashID. Looking forward to learning more about it in the future. It's amazing how much is happening on Bitcoin CASH.
There's a memo topic for CashID, in case you want to get the updates as they come <3
If there is, it is a good reason to implement delegated child keys and keep your main identity elsewhere, like on your wallet. Hopefully this will come in a few months, with CashID <3
i saw your video on CashID. Looking forward to learning more about it in the future. It's amazing how much is happening on Bitcoin CASH.
saw this post today. any validity to their claim? https://memo.cash/post/417c6e57342cf1100b6edab7e6bff418c8da3bcb400c5a58e4843fa4236eeede
If there is, it is a good reason to implement delegated child keys and keep your main identity elsewhere, like on your wallet. Hopefully this will come in a few months, with CashID <3
Is CashID somewhere implemented?
You can't keep innovating *in core functions*. You can keep innovating in lots of other parts. :)
User feedback is important. If anyone tries CashID out, please let me know how well it works for you.
I don't know why, I can't install the lastest realease on my phone. Previous was working fine.
It might be two things that I know of:
1) I changed the internal name
2) I lost the signature keys and made new ones.
Both of those can be fixed by uninstalling first.
A bit tired after 5 failed recording attempts, and some coughing due to sore throat, but generally a nice video:
With the PHP library in reasonable good shape, I will turn my attention back on the android identity manager, while I wait for implementors to give me feedback on the library.
"Forward blocks", a neat way to use/abuse 4 horrible things at the same time. Jokes aside, I read the first 2-3 pages of the paper and it's complex. Really complex.
The status code section of the specification has been updated. Old status codes should be phased out.
So you basically reinvented X509?
At first, I just want to say "no, it's not". Then I read the first part of the X509 wikipedia page and there are similarities. I guess it comes down to what "basically" means here.
I'm not sure yet, but probably a custom action like you said. Delegated keys is something I was hoping to start working on in next few months. Once I dig in I'll know more.
While for a custom action, the identity manager / wallet could both sign, build and broadcast the TX, then return TXID in response.
For compatibility, offer a generic solution as well
I'm not sure yet, but probably a custom action like you said. Delegated keys is something I was hoping to start working on in next few months. Once I dig in I'll know more.
Based on MIP, there is two actions sign: one that grant, and one that revoke, permission.
Generic a=sign&d=data can be used, but memo client would need to build and broadcast TX.
Good. Let me know if you have any questions.
I can translate to Russian and Kazakh.
Hey will this allow me to use my vanity gen addresses on Memo.cash? I don't ever want to upload their private keys.
with this, you can use your vanity address as your identity. your posts won't be made by it directly, but linked to it. memo would have their own child keys, which you sign to approve.
#0conf -- Why would a thief double spend in a store when it's the same as walking out the door without paying and it's more time to be recorded on a security cam.
#commonsense
Final worklow, with memo.cash as example:
user visits memo.cash. scans CashID code, logs in. memo.cash create child keys, user use CashID to sign them, memo.cash can now post for user
If I understood this right, then my only complaint on memo.cash (that I am not in control of my own keys) is finally solved - and with a userfriendly design!
The user could then post a revocation transaction on-chain that delinks the child key at a given blockheight.
Final worklow, with memo.cash as example:
user visits memo.cash. scans CashID code, logs in. memo.cash create child keys, user use CashID to sign them, memo.cash can now post for user
Just to be make sure I understand this correctly:
any memo-implementation creates child keys, puts a request on-chain that if signed by the users master key, links it to user identity
The user could then post a revocation transaction on-chain that delinks the child key at a given blockheight.
