P2P

Under the hood the backend components relies on lib-p2p for communicating among the other federation peers.
The setup is similar to IPFS' usage of lib-p2p, although adapted for a much specific use case.

trile largely uses p2p to pass messages between the federation peers by using a publish/subscribe pattern.

Messages

Heartbeat (controller)

• Source: the controller.

• Information: IPFS cluster metadata.

• Destination: any federation member in the network.

• Frequency: 1 message per minute.

• Purpose: controller's proof of life, a "I'm alive" shout out.

Heartbeat (member)

• Source: members.

• Information: current sharing folder CID.

• Destination: the controller.

• Frequency: 1 message per controller heartbeat received.

• Purpose: member's proof of life and an updated vision of their lastest CID. Helps in bringing consistency to the controller when messages are lost or not fully processed.

Check-in

• Source: members.

• Information: current sharing folder CID.

• Destination: the controller.

• Frequency: 1 message at startup time.

• Purpose: tells the controller that the instance has just started. It will make the controller to store the federation member information on database and will make sure the reported CID is the one replicated in the federation.

Check in's ACK

• Source: controller.

• Information: plain ACK.

• Destination: the member that sent the original check in message.

• Frequency: 1 message per check in message received.

• Purpose: tells the member that their data is synced across the federation.

Sharing folder update

• Source: members.

• Information: current sharing folder CID.

• Destination: the controller.

• Frequency: every time the content of the sharing folder changes.

• Purpose: makes the controller initiate the replication process across the federation.

Sharing folder update ACK

• Source: controller.

• Information: plain ACK.

• Destination: the member that sent the original message.

• Frequency: 1 message per update message received.

• Purpose: tells the member that their data is synced across the federation.

Forced sync

• Source: members.

• Information: current sharing folder CID.

• Destination: the controller.

• Frequency: every time a sharing folder update message is not ACK after some grace period.

• Purpose: makes sure the controller is listening & replicating member's updates.

Forced sync ACK

• Source: controller.
• Information: plain ACK.
• Destination: the member that sent the original message.
• Frequency: 1 message per forced sync message received.
• Purpose: tells the member that their data is synced across the federation.