It's a bit of a mess in terms of commits, I'll brush it up after all tests are good and will create a PR, just to discuss the thing
pfrazee built a log viewer for beaker https://usercontent.irccloud-cdn.com/file/4iJ93nZr/Screen%20Recording%202019-01-22%20at%2010.30.12%20AM.mov
pfrazee cblgh: thanks!
konobi RangerMauve: the illustrations here give a better overview: http://mathmesh.com/Technical/
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)