fleekyits outside of the hyperdrive mount directory
fleekyso there is ~/Hyperdrive
fleekywithin that i would like to symlink to an outside directory
andrewoshoh I see, yeah currently we're sandboxing symlinks within ~/Hyperdrive so that they can't reference external files
andrewoshsymlinking between mounts inside of ~/Hyperdrive should be supported. beyond that keeping your external directory synced through other means (or through a yet-to-be-written
hyperdrive synccommand) is the way to go
fleekythanks for the explanation
andrewoshyeah if you hit bugs with the rsyncing ping me or open an issue. don't want that part to be giving you trouble
okdistributeserapath good news, i think for your project. multifeed might be adopting the 'discovery-key' event from corestore
okdistributemultifeed right now does a manifest feed but there's movement on also supporting the discovery-key method
yeah, i'm just reading it. found it in the source code, but i did look deep into the kappa core down to multifeed and mux code and i looked into hyperdrive and got an in-depth explanation from mafintosh too, but didn't spend much time yet to check out the details of corestore.
...i thought the way hyperdrive works is having a feedkey from which you derive a discoverykey and thats basically for the metafeed and the first message gives you the feedkey for the contentfeed and the rest of the metafeed is a hypertrie where you get additional feedkeys via the 'mounts' key
rangermauveLike, once I create a hypercore with a derived key, will I be able to write to it if I load the key without re-deriving
andrewoshrangermauve: the keys are derived from a master key and a name (which is stored on disk in a file called
name). the private key is regenerated at runtime from those two things, but you don't need to pass the name in any subsequent time you load the core
rangermauveAs long as it's the same namespace, right?
rangermauveAnd even if I use the namespace, it'll deduplicate to the existing feed that isn't writable?
andrewoshnah the namespacing won't affect the writabililty of the core. it's really just a convenience around the
defaultfunction and also replicating sub-groups of cores, but it doesn't affect write permissions currently
andrewoshas in the
store.get(key)case will still generate the correct key
rangermauveCool, thank you!
rangermauveandrewosh: mafintosh: Renamed
.destroyData. How does that sound? Also, gonna update my hyperdrive PR to match
okdistributeandrewosh pfrazee how easy would it be to hack cabal in there?
pfrazeehmm probably need a hypercore api and a way to hook into the hypercore replication
pfrazeewhich you could do in the short term with a browserified copy
pfrazeecould look into (finally) tackling the hypercore api though
pfrazeeyeah. If anybody’s trying it hmu if you hit issues
okdistribute...and not having to run so many electron apps simultaneously 🤪