Bridges DNA definition

[lucksus]

Update

I've applied @zippy's change request to have a enum BridgeReference and I just reused struct dna::capabilities::Capability for the BridgeReference::Capability variant.

This way we can already specify a bridge dynamically through function signatures :)

Addition to DNA spec:

"bridges": [
    {
        "presence": "required",
        "handle": "DPKI",
        "reference": {
            "dna_address": "Qmabcdef1234567890"
        }
    },
    {
        "presence": "optional",
        "handle": "Vault",
        "reference": {
            "capabilities": {
                "persona_management": {
                    "capability": {
                        "membrane": "public"
                    },
                    "functions": [
                        {
                            "name": "get_persona",
                            "inputs": [{"name": "domain", "type": "string"}],
                            "outputs": [{"name": "persona", "type": "json"}]
                        }
                    ]
                }
            }
        }
    }
]

As per discussion with @zippy and @artbrock on 13/12/2018 I've moved the bridge definitions into the zome.

[philipbeadle]

We also need to be able to setup bridges at runtime, eg when a new private chat group is setup that has its own DHT :)

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (develop@72021eb). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff             @@
##             develop     #752   +/-   ##
==========================================
  Coverage           ?   72.43%           
==========================================
  Files              ?      146           
  Lines              ?     4953           
  Branches           ?        0           
==========================================
  Hits               ?     3587           
  Misses             ?     1366           
  Partials           ?        0

Impacted Files	Coverage Δ
core_types/src/dna/dna.rs	87.7% <100%> (ø)
core_types/src/dna/zome.rs	95.24% <100%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 72021eb...33f972b. Read the comment docs.

[codecov]

Codecov Report

Merging #752 into normalize-dna-module will increase coverage by 0.03%.
The diff coverage is 100%.

@@                   Coverage Diff                    @@
##           normalize-dna-module     #752      +/-   ##
========================================================
+ Coverage                 73.53%   73.55%   +0.03%     
========================================================
  Files                       140      140              
  Lines                      4733     4737       +4     
========================================================
+ Hits                       3480     3484       +4     
  Misses                     1253     1253

Impacted Files	Coverage Δ
core_types/src/dna/dna.rs	88.06% <100%> (+0.76%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b736d5a...0751e5e. Read the comment docs.

[lucksus]

@philipbeadle, we talked about your point yesterday. I see setting up these bridges as container concern. The UI that deals with several apps/DNAs/DHTs needs to have admin privileges (or rely on some signalling system) to install private-channel-DNAs. Those channel DNAs define (statically) that they can or need to bridge to some other DNA (Vault or a root chat DNA). They can do that by either locking in the DNA hash of that dependency (v1) or by defining a trait, that is set of functions they expect in their bridge app (follow-up)

Does that match with what you're thinking?

[lucksus]

See updated description:

I've applied @zippy's change request to have a enum BridgeReference and I just reused struct dna::capabilities::Capability for the BridgeReference::Capability variant.

This way we can already specify a bridge dynamically through function signatures :)

[lucksus]

@sphinxc0re please re-review.
@zippy, I know you have change Capabilities already in your branch. I would merge this one if you agree with the latest changes. Or we merge your's first and I fix conflicts in here. Anyway, I think we should have both merged in tomorrow and pair a bit on the following steps :)

[lucksus]

@philipbeadle, reusing the Capabilities struct we had in the DNA already I got this in quickly. Do think this covers everything you need? The root chat app could have a special capability meant for the private channels. That capability gets specified in the private channel DNA like above. The container can then match and suggest (via admin UI or yet TBD signal/request system) that these two DNAs can be bridged and change the container config accordingly if the user chooses so.

[zippy]

Yes. I like this. I think it will work well.

[sphinxc0re]

The Default implementation for Zome could be derived automatically, I think 🤔