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
cblgh pfrazee: feels like you might have opinions on a contacts API https://twitter.com/gozala/status/1088177108923297792
cblgh google is apparently floating a spec
pfrazee cblgh: yeah I saw that. Seems like a nice-to-have
@konobi: Would be very useful :)
@substack is hyperdrive-multiwriter still current? (https://github.com/substack/hyperdrive-multiwriter).
okdistribute aral this is a bit more recent https://github.com/mafintosh/hyperdrive/tree/hyperdb-backend
okdistribute aral and http://github.com/kappa-db/ is another way of doing multiwriter on hypercore
okdistribute https://github.com/noffle/multifeed
mafintosh there is some improvements in the pipeline atm, me and andrewosh are hard at work :)