fazo96
commented
6 years ago I agree, but that separation is already there. I think it's the name of the function that's confusing:
putDIDAndWaitForReplication just puts the didId => multihash mapping into orbitDb and returns only when the DB has been replicated remotely. It does nothing else, it does not do any IPFS operations or any DID operations. Just writes an oplog operation object with a couple of strings into OrbitDB, so this call is just OrbitDB module doing OrbitDB stuff.
Actually writing the DID to IPFS is done a couple lines above in the file you linked, which is the Chlu "DID on IPFS" module, bridging DID specific functionality (in chlu-did) with IPFS and OrbitDB.
Creating and signing are done in the chlu-did module. This file you linked wraps the signing and verifying functions to make them resolve DID IDs to the public key through IPFS+OrbitDB and also to make it easy to sign multihashes.
I agree we should have cleaner interfaces between modules and we will: when we set up the query, collector and publisher and also the api client, the need for this ChluIPFS monolith won't be there anymore, we will split it into its current modules (with some refactoring to clean up) and then use those modules individually in the query, collector, publisher and api client.
https://github.com/ChluNetwork/chlu-ipfs-support/blob/fa355b2e64529ed6f6b32d36b5cc5d629bb7e634/src/modules/did.js#L99
@fazo96 should we consider decoupling such integration. We should aim to have cleaner interfaces between the components. IPFS does ipfs stuff, orbitdb uses IPFS, and finally DID uses IPFS. DID should not be a module inside the IPFS lib, as we originally had it.
Nothing is going to break, but reusing code will become a problem in the future.