Decentralization

[delucis]

Currently a single client acts as the host and all communications pass through them.

The host could provide connected clients with the peer IDs of all other clients so that they can also establish connections between each other (a “full-mesh topology”). At that point, various other possibilities arise: each client could be responsible for processing and emitting their own state updates instead of sending an action to be processed and emitted by the host. Then if the host drops out, the clients (via their existing connections) could agree a new host amongst themselves and keep playing.

A variation on this would be the host just transmitting a list of IDs for all connected peers to allow them to establish connections only in the case the host goes offline.

Decentralization would also mean storing match state in all clients, which would also be more robust.

This should probably be an optional feature.

[delucis]

For the full state to be present on all clients, the host would presumably have to send over the full database state to a connecting peer on connection. This would include credentials as suggested in #1, so would render that authentication approach more or less useless.

[jonaswre]

In a p2p scenario authentication would need to be handed through encryption. The host could store a public key from the client. And a client could then send something that's encrypted with the private key. Any peer could then verify the player.

[jonaswre]

This could also be used to provide a mechanism for clients private state being present on all clients.

[delucis]

Nice idea! Do you think we could implement that already?

Currently each client has a metadata object for itself:

p2p/src/index.ts

Lines 106 to 108 in 7066e90

	private get metadata(): Client["metadata"] {
	return { playerID: this.playerID, credentials: this.credentials };
	}

Which we send as part of the initial connection to the host:

p2p/src/index.ts

Line 156 in 7066e90

const host = this.peer.connect(this.hostID, { metadata: this.metadata });

(credentials in this context is a standard property that is set via the boardgame.io client.)

When the host receives the connection request, it checks if a client for the requested playerID previously connected, and if they did, then checks the credentials match what was previously provided:

p2p/src/host.ts

Lines 100 to 117 in 7066e90

	// If no credentials exist yet for this player, store those
	// provided by the connecting client and authenticate.
	if (!existingCredentials && credentials) {
	this.db.setMetadata(this.matchID, {
	...metadata,
	players: {
	...metadata.players,
	[+playerID]: { ...metadata.players[+playerID], credentials },
	},
	});
	return true;
	}
	// If credentials are neither provided nor stored, authenticate.
	if (!existingCredentials && !credentials) return true;
	// If credentials match, authenticate.
	return credentials === existingCredentials;

Would the two sides of this connection simply need an additional step locally to encrypt/decrypt the credentials? Or would an additional negotiation be needed where the client demonstrates it can encrypt a token provided by the host?

Happy to look at a PR for this!

[jonaswre]

I've created a small prototyp. https://github.com/jonaswre/p2p/commit/e4249c96741c2b96df102f97cb5be37aec34957f.

I've not tested it in a webclient but made some unit tests. This should be as secure as your current authentification is. But if any other client gets access to the signed message (not persited anywhere) they could use that and replay it. But you have the same issue with your current model. To make the process more secure, one would need to sign every action that is send. And if we add a counter to the action and the server only accepts actions with lastCounter + 1 we could counter replay attacks.

But that would need a bit more restructuring.

[delucis]

Cool, thanks! I’ll try to read through those changes soon (I don’t know much about cryptography so I’m a bit slow).

If you want to try it out in a browser, you could download a copy of the example CodeSandbox: https://codesandbox.io/s/boardgame-io-p2p-demo-0loyd (File > Export to ZIP) and install your local fork:

# in repo for @boardgame.io/p2p
# compile Typescript to JS
npm run build
# create a tarball for the p2p module
npm pack

cd ../boardgameio-p2p-demo
# install dependencies
npm i
# install the local tarball instead of the remote dependency
npm i ../p2p/boardgame.io-p2p-0.3.0.tgz
# serve the demo app
npm start

[jonaswre]

After a little adjustment my change works.

[delucis]

Great to hear! I should have time over the weekend to take a look at your changes — look forward to it 😄

[jonaswre]

To be honest I think taking your approach to P2P will be very difficult because many features will be need to be implemented.
I think I will checkout libp2p, ipfs, orbitdb. This libraries will already implement many of the needed features.

OrbitDB is a Database that's already P2P with authentication. Might be a better fit then doing everything ourselves.

[delucis]

Hi @jonaswre, I’m just trying out your changes with the example code and I get a TypeError: invalid encoding thrown by the call to decodeBase64 in verifyMessage.

Did you see that while you were testing? Does the use of private/public keys impose certain restrictions on the formatting of credentials?

[jonaswre]

Hi @delucis,

I've just checked to be sure. I dont get any error when running the demo. Do you get the errors in "npm run jest" The keys are returned as Uint8Array and then base64 encoded so the credentials just have to be able to store a base64.

[delucis]

The tests pass. I’m reading through in detail and now I see the keyPair option. I’m guessing I maybe have to provide that for this to work?