To those of you in the know about modern browser tech:
Does it seem at all conceivable that an SPV wallet could be built entirely in
JavaScript? And if indeed it is within the realm of the possible, how would
such a thing be safely distributed for use? Would a signed Chrome Plugin be an
ideal
This is just me making notes for myself, I'm not seriously suggesting this
be implemented any time soon.
Mozilla Persona is an infrastructure for web based single sign on. It works
by having email providers sign temporary certificates for their users,
whose browsers then sign server-provided
We have been discussing something like this over here too, as well as exploring
more esoteric blockchain+signature-based SSO implementations as discussed by
John Light and others.
One of our long-term ambitions with Hive is to provide a (mostly)
user-transparent, decentralized authentication
Oh, I forgot to make it clear - Chrome apps/extensions can make raw TCP
socket connections:
http://blog.chromium.org/2012/11/introducing-tcp-listen-new-api-for.html
You would do it as a packaged app:
http://developer.chrome.com/apps/about_apps.html because then they're a
lot more similar to
On 9 August 2013 14:08, Mike Hearn m...@plan99.net wrote:
Bitcoin sought to reduce dependence on trusted third parties, where as,
persona is increasing the reach of trusted third parties. The keys and
passwords are stored on mozilla's servers, sometimes on your email
providers. Persona, is
On 9 August 2013 13:59, Wendell w...@grabhive.com wrote:
We have been discussing something like this over here too, as well as
exploring more esoteric blockchain+signature-based SSO implementations as
discussed by John Light and others.
I've been using SSO for years using an X.509 private
Packaged app pages always load locally. This allows apps to be less dependent
on the network. Once a user installs an app, they have full control over the
app's lifecycle. Apps open and close quickly, and the system can shut apps down
at any time to improve performance. Users can fully
Guys,
I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol. We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it
No, it's not -- but that's certainly very cool to see Jeff.
How is BitPay going to put this to use?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Aug 9, 2013, at 3:08 PM, Jeff Garzik wrote:
Certainly. BitPay is working on such a wallet:
https://github.com/jgarzik/wally
On Fri, Aug 9, 2013 at 1:58 PM, Wendell w...@grabhive.com wrote:
No, it's not -- but that's certainly very cool to see Jeff.
How is BitPay going to put this to use?
Well, wally is just a demo application, a command line client to
prove a technology.
The main development is in places like
anyone tested the secure encrypted p2p email: http://bitmail.sf.net
SVN here:
svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code
http://sourceforge.net/p/spot-on/code/commit_browser
--
Get 100% visibility
Payment protocol is locked down for v1 already. But did you read it? It
doesn't use addresses anywhere. Payments are specified in terms of a list
of outputs which can contain any script. Of course it could be a
pay-to-address script, but pay-to-address uses more bytes in the chain and
there isn't
It's BIP specified and implemented in Bitcoin-Qt so now is the time to
start :) I'm hoping that most wallets can announce support near
simultaneously
On Fri, Aug 9, 2013 at 10:12 PM, Alan Reiner etothe...@gmail.com wrote:
That's fine. I just want to make sure it's considered for
Jesus, please stop this. :(
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
On Aug 9, 2013, at 9:01 PM, Randolph D. wrote:
anyone tested the secure encrypted p2p email: http://bitmail.sf.net
SVN here:
svn checkout svn://svn.code.sf.net/p/spot-on/code/ spot-on-code
14 matches
Mail list logo
