# Bridging across hApp bundles.

(A Neighbourhood is a collection of one or more hApp bundles)

[Draft document to get conversation going. Can be filed in the appropriate place once formalised]

### Two kinds of bridging across DNAs.

- Bridging within a hApp bundle


In this case, bridging can also be used in validation rules, since the same DNAs are available to all agents.

- Bridging across hApp bundles


In this case, since User Y cannot access the source of the entry, there is no way they can ensure validity. **User X can 'fake' the entry by forking Holochain itself.** There are a couple ways to address this:
1. Require User X to pass the entry only with a 'validation receipt' that can be checked by another agent. However, this doesn't entirely solve our problem because:
- The validation receipt doesn't have much meaning outside of its context i.e. DNA. User X may not have received a validation receipt because of a 'silly reason' that is critical in DNA F, but not critical for DNA C.
- More importantly, User X can completely fake validation receipts, just like they faked the entry.
- What about validation receipts which include a capability token, such that the validatee can make checks against the private source chain of another agent?
2. Allow user X to pass the entry, but enforce penalties if the data is found to be invalid at a later date, but other agents who can run audits in DNA F at a later date. Perhaps each DNA also maintains a list of 'defaulters' based on their context, apart from the warrant system. This seems a bit off-vibe though.
3. **We could also address this by bridging only through 'trusted nodes'**. So if User X's data from another DNA is required, User X has to run a RPC to User Z (present on both DHTs), who runs a bridge call, then allowing user X to pass the entry. If it's an encrypted entry on the other DHT, User Z can be granted a capToken by User X. The only concern here is we cannot access info from DNAs that 'trusted' nodes are not part of. Also, every users data is being accessed not by them, but by other agents (but I guess they would have access to this data at a later date anyway?)


4. **Bridging on peer-to-peer interaction, then validating a proof of that interaction**. This pattern is a valid and secure one in these circumstances:
- Alice is in both DNA-A and DNA-B.
- There is a peer-to-peer interaction between Alice and Bob in DNA-A that depends on an action from Bob in DNA-B.
- The interaction can be attested in some self-validating form.

The pattern goes like this:
- Bob commits something in DNA-B.
- Bob initiates a peer-to-peer interaction with Alice in DNA-A.
- Alice bridges to DNA-B to see if Bob action is there.
- Alice approves the peer-to-peer interaction, providing some kind of proof.
- This proof can be committed to the DHT (with validation rules being "only is valid if Alice has signed it") or can be use as a self-validating proof in other spaces.

Real example from LeaP: a student can only attend a course if they have paid for it in the mutual-credit DNA. Here, each course is in a dinamically created DNA, and there is a global course-catalog DNA to see all courses available. Simplified steps (Alice as teacher and Bob as student):
- Bob sees a course in the public LeaP DNA and wants to join.
- Bob calls "buy_ticket_for_course" in the public LeaP DNA. This call gets the payment info for that course, gets the amount to pay, and bridges to the mutual credit DNA, making an offer to Alice for that amount.
- Following that, Bob notifies Alice of the offer, and Alice checks if the offer amount corresponds to the amount to pay for the course.
- Alice accepts the offer, signing the transaction and **minting an untransferable ticket for this course to Bob**.
- Bob joins the DHT, committing as proof for joining the ticket Alice has minted it. The membrane validation rules check that the ticket contains Bob's public key, the signature of the teacher, and the appropriate course hash.

Here is the detailed mechanism: https://hackmd.io/nNspQKCOREeSobsj_4YMMA?both

----

Additional thoughts:

**Sid**: I like the approach of bridging through a 'trusted' node. It basically means the community still has to take a gamble on who they think is trustworthy. Trust continues to be a 'human decision' as opposed to 'tech assuming the role of guaranteeing trust'. In this case tech just eases th process of preserving and porting data once we decide to trust and agent.

Worth thinking about:

- What happens when we make bad trust decisions:

graph TD
    Start --> Stop

**Guillem**: I think that depending on the use case and the roles, one pattern should be used or another. First, I think it's very important that the membranes of the DHTs are very carefully defined, to allow the appropriate members inside the DHT. Then, examining the roles, it becomes clear who is an authority for which kinds of data, and what can be build from the data that helps us validate it in other DNAs.
One thing that has always helped me is imagine real life environments and interactions. For example, if we are to validate that an agent is a valid representative for a group. We can imagine okay, what would that look like in real life? It would be something like the representative of a medieval goverment going out into the realm and having to proof to someone they are a valid representative of the king (I know we don't like monarchies and such, it's just fun and useful to imagine these scenarios). In this case, for example, the "courts" are one DNA space, and the exterior world (for example, a farm) is another one. We can think of at least these patterns when the representative has to proof to the farmer they are an approved representative:
- The representative carries a "proof of representation", containing the signature of the king (or all signatures necessary from the group of people they represent). In medieval times, these are actual signatures or also seals. The proof would also probably contain an end date for the representation, to avoid infinite abuse of the proof. The farmer can trivally see if the end-date has passed, and the representative has to come back to the court to receive an extended proof of representation, which now he may be denied. **This is carrying a proof from another space, and doesn't require bridging since the proof is self-validating**.
- The farmer can directly call the king (if we imagine phones were invented in medieval times). Calling into the court space necessarily means calling a member of the court and **trusting them**. **This is bridging through trusted nodes**. And here to be more certain, you could call more than one member of the other DNA and check their answers, although differences in them might be due to eventual consistency in the DHT.