Db level replicator call with option to provide thread keys

[jsonsivar]

This is to behave similar to the existing net.addReplicator call but accessible at the db level in addition to net. Moreover if we had the ability to optionally pass in thread keys, then we can use this to have both a replicator where the hub can't see the content (service only) or the hub does see the content in cases where we want data/files/acl to be served off the hub instead of a local instance.

More background: in our use-case for the Space app, we'd like to create the flexibility for someone to use the hub to back things up or configure another instance of Textile (maybe they run one on their own). In this case, we'd like to be able to add replicator to whichever hub instance they go to but with the read keys so that other users can hit the hub to access share files if p2p transport doesn't work between the users directly.

The one thing that's still open is how do users share files and send messages to each other if they are not both connected to the hub? I.e., in the scenario where user A is pointing to hub A. They share a file to user B who is also pointing to hub A. If user B switches to a backup node of their own (let's call this hub B for example), then the sharing and mailbox breaks so not sure if there is a way around this (hub of hubs?). Just putting that scenario out there as well in case we can brainstorm something in this thread.

[bitcard]

mark