Eric Drechsel bridging the gap between user-centric pki and device centric would seem to be on the critical path to making all these systems ergonomic. WIthout it the level of manual trust level management across nodes required by the user is comical (like one of those sped up Laurel and Hardy films).
It seems that P2P identity is a hot topic lately
konobi congrats substack =0)
@konobi Thank you; will have a read :)
karissa alexindigo one way to get hypercore running with react-native is to have a node process running simultaneously, which the react-native process talks to via unix sockets or http requests (for example)
karissa alexindigo there are some examples floating around http://github.com/cabal-club/cabal-mobile/
karissa alexindigo http://github.com/digidem/mapeo-mobile
@karissa I played with nodejs-mobile a bit. I wasn't able to run hypercore there out of the box and when I started to dig deeper, it's another thread with deoptimized JS runtime, and comparing it to react-native-sodium that uses native encryption I decided to try to make it work that way, so I can get use of native encryption and networking (not sure how that latest part implemeted in nodejs-mobile)
I'll check out other links, thank you
@aral there's https://github.com/fsteff/hypercore-encrypted though
and i think the best way to make something like this more ore less usable in the wider ecosystem would be to make all higher level tools accept a hypercore constructor function in opts, similar how these days you can pass your own instance of random-access-storage. multifeed/kappa-core already does it that way and it'll be a simple PR to hyperdb
i might try to find the time to do it soonish. that would also simply things if you want to manage storage for a lot of e.g. hyperdbs.
and then that could also maybe be the right place do start implementing block-level deduplicated storage. dunno if that would be doable at the random-access-storage layer (would it?=
karissa alexindigo okay, this might be the best example which has hypercore working on nodejs-mobile https://github.com/cabal-club/cabal-mobile/blob/master/nodejs-assets/nodejs-project/package.json
Been giving device authorisation in multiwriter some more thought and, contrary to my initial knee-jerk reaction, I think it can be done within the limitations of the current system. It should be possible to handle lost/stolen devices as long as the write key (secret key/private key) is never stored on any device. Since I’m using key derivation from a Diceware passphrase salted with the unique domain in Hypha, this should be easy to support in a usable manner (the passphrase has to be stored in a password manager – or a brain better than mine – anyway). So I’m thinking that the master passphrase will not be tied to any hypercore and every device’s writeable hypercore will derive its keys from the master key with the name of the device used as the salt. This means that on any node where the person enters the passphrase and the name of the device to be authorised is known, its public (and private) key can be calculated and the device authorised in the local hypercore. If a device is lost/stolen, lack of the passphrase will disallow further writing. Of course, this requires that the device is properly secured at other layers in the stack (i.e., auto lock, password on lock, full-disk encryption). Do any of you see any glaring issues with this?
yoshuawuyts (that = logviewer)
Like, typical password with a hash won't have a very high level of entropy compared to a truly random private key. Maybe encrypt the private key with a password and store that publicly?
@RangerMauve Cool, thanks :) I think I have the password/key generation down. The password generation process is based on Diceware (using the EFF word list) and I’m generating keys where the process has ~100 bits of entrophy. The key derivation is via scrypt (see https://github.com/jo/session25519) and the salt is globally unique (domain name). https://ar.al/2019/01/15/hypha-spike-diceware/ (Source: https://source.ind.ie/hypha/spikes/diceware)
(While we were working with the City of Ghent last year, I was trying out keeping the keys on the always-on node and doing just that – encrypting the private key with the passphrase – but I want the always-on node to not be privileged in any way. In fact, I want it to be less privileged than nodes that you have primary control over.)
@RangerMauve ;)
@RangerMauve PS. Just pinged you on fritter (remembered it after seeing your profile) – did you get those at all? Got lots of timed out errors.
- profile = homepage :)
@aral Not that I can see. What's your fritter profile so I can check if it loads. I'm at dat://fritter.hashbase.io/user/dat://3df8868d5c3420d7acdf72d17129e4569cf83723092314ea6b260d112797d8c8
paul90 RangerMauve (Gitter): The last message I see from you in fritter was from 5 days ago "It's been so quiet on here lately. :P" But, it took a couple of days to show up here... I'm at dat://fritter.hashbase.io/user/dat://76910d65f17c3f010972b2a02a72063ef60fb9dccb296f9cc2123c934da8bfc6