P2p

Protocols

Ping

Implementation

We have the implementation of a basic ping protocol. This is not actually used within Spacedrive but acts a reference for implementing a new protocol.

Spacedrop

Implementation

Spacedrop is a system for sending files quickly to other peers. It is intended for sending to peers that have not been paired into the library. It is great for sending a file to a friend on your same network running Spacedrive but you can use the regular file manager for sharing a file without another node in your library.

This protocol works but some of the following are missing features:

• Pause/resumable transfers
• Transfer a folder - ENG-1297
• Usage with sd-server will result in bugs if you have multiple web clients - ENG-1034 and ENG-1522

The following are known bugs:

• ENG-1298
• ENG-1035
• ENG-1203
• ENG-1211

rspc

Implementation

This protocol was an experiment to expose the rspc router of a node over P2P. Although it works this is a security nightmare so it has been disabled by default and hidden behind the wipP2P feature flag.

How to test this feature:

• Enable the wipP2P feature flag
• Enable the feature within the network page of settings
• Ensure "Enable remote acccess" is enabled on both nodes
• Click the "rspc remote" button on the node you want to connect to.
• If the connection fails you will be presented with a white screen, otherwise you will be given a library selection and once seleted you will be given Spacedrive UI running on the remote node.

Major problems with this feature:

• This protocol doesn't have any security (hence it being disabled by default). It's also a nightmare to secure as it's full access (including to do filesystem actions) or no access. - ENG-1646
• The rspc websocket connection established over the P2P system is leaked so it will never be cleaned up. Fixing this would require changes to rspc. - ENG-1647
• Any usage of rspc outside the React context will still be using the local node's rspc router. We don't do this often but we definitely do it. - ENG-1648

From my (oscartbeaumont's) perspective this was a cool experiment but not something we should ship because getting it's nightmare to get security right.

Sync

Implementation

This protocol takes care of sending sync messages between nodes. This is an alternative to the Cloud-based system.

This protocol uses sd_p2p_tunnel::Tunnel so ensure the recipient is paired into the library.

Loading thumbnails and files remotely

Implementation

This protocol takes care of loading both thumbnails and files remotely. This is used when the media is not available on the local mode.

This protocol transparently extends the custom URI protocol and uses information in the database to determine the node responsible for the file.

This protocol uses sd_p2p_tunnel::Tunnel so ensure the recipient is paired into the library.

Design issues

Right now the system relies on the instance_id column on the Location to table to determine which node to route the media request to. This is a suboptimal solution as a location may move nodes, a good example of this is a USB drive.

A better design would be to have an in-memory table of HashMap<LocationId, NodeRemoteIdentity> and then using another P2P protocol which sends a message to all connected nodes when a location comes online/offline on the current node.

Sync preview media

Unimplemented

Tracked by ENG-910