Thing is, if the message gets to the recipient through a slightly more circuitous route, and that route adds only a fraction of a second to the total travel time, then what’s the difference? In other words, if there’s an extra relay or two between me and the peer I’m communicating with, is that really any different than my “direct” connection?

Some might argue, correctly, that IP addressing is the most efficient way to exchange messages on the internet (i.e. relatively small message size and relatively small delay), but CypherPoker.JS isn’t a twitch game and can easily afford an extra moment or two to exchange slightly bulkier data.

Working with an excruciatingly slow connection has convinced me that even with 1990’s dialup it would be unlikely that anyone would notice a difference; on anything faster it’d be a moot point.

So, putting aside my exacting notions of what constitutes “peer-to-peer networking” I was able to came up with a lengthy list of connectivity options, the first two of which I was able to implement with satisfyingly reliable success (and more are in the works).

WebRTC is still in there and is used when trying to connect to peers but now when you want open up your CypherPoker.JS services or peer connection you can also use WSST (WebSocket Sessions Tunneling) or SSH (Secure Shell) tunneling; simply flick a switch to generate a SDB (see below), and share it via email, discussion forum, Facebook, Twitter, text message, as part of a web link (URL) … whatever.

At the other end the recipient plugs the information into their copy of CypherPoker.JS and boom … you’re both connected!

You can also add the SDB to the end of a URL by using the sdb parameter like this ephemeral tunnel-to-desktop link (used in the browser):

https://monicanagent.github.io/cypherpoker.js/demo/web?sdb=AQEAAADDAAAJV1NTVHVubmVsAQAaV2ViU29ja2V0IFNlc3Npb25zIFR1bm5lbC4CAgMDBgAAXXsiZW5kcG9pbnQiOnsiYWxpYXNlcyI6WyJiYmFkYzRmNGNlOTJiYjljMDdlNmIyNTAzM2E0Zjg5ZTU2MmQ5Yjc3NjE0NTQ4YTY5YWU1YzEyMWNhMGMzZDU1Il19fQQCAC5jeXBoZXJwb2tlcmpzLXNlcnZpY2Vzc2VydmVyLXplaHhpcGpzenUubm93LnNoBQAAAAAAABMHAAEIAAICAgMDCwAFCQAGCgAH

(Note: SSH tunneling isn’t as reliable as WSS tunneling when one end of the connection is the browser so WSST is the default/preferred option)

Bundling for a Split

Up until now, CypherPoker.JS has only used multiplexing, a fancy term for a single communication channel being shared by multiple parties, kind of like an adult chat line. Except less explicit.

There also wasn’t a way to specify where you wanted to connect to without manually updating configuration data.

In version 0.4.1 peer-to-peer communication has been separated from all the functional messaging like account management, blockchain interactions, etc. Instructions on how and where to connect for either/or can be included at startup (in the URL, as above), or via the user interface with an option to save and restore the information.

This is a necessary preparation for the next bunch of updates, especially when it comes to using native clients for cryptocurrency handling.

The idea is that, on the desktop, players can handle their own accounts and blockchain interactions but may want to connect to external peer-to-peer rendezvous points to find other players.

In another scenario, browser-based players may want one service provider to handle their account(s) and another for peer-to-peer game messaging.

And, of course, if you’re running your own services you’ll want an easy way to share information about how people can connect to you.

Splitting P2P (peer-to-peer) and API (account, blockchain, and other services), communication means that you may now need to send two potentially separate addresses (usually URLs), along with some extra information about what those addresses actually represent.

In addition, web/browser connectivity is famously limited so we might need to provide a few alternatives in case one or two connection options are unusable (looking your way, WebRTC).

Throw into the mix the possibility of including additional information (game tables to automatically join, for example), plus non-URL-based connection options, and now we’ve got a bunch of information we need to deal with, so I came up with a compact way to share it all: the Services Descriptor Bundle.

Here’s an example of what a small SDB might look like if we shared it using “minified” JSON, a compact native JavaScript format:

[{“entity”:”api”,”transport”:”wss”,”protocol”:”ws”,”host”:”168.90.10.3",”port”:8090},{“entity”:”p2p”,”transport”:”wss”,”protocol”:”ws”,”host”:”192.12.89.69",”port”:3221}]

Here’s that exact same information in the smallest SDB variant called SDB-s Base85:

z!”Au1!s/T*W*0N1"Ws06!!!!.!W`B)”9?4G=[`K&PlLda

And here’s that information in a format called SDB Base64. It’s slightly longer but URL friendly (i.e. it can be tacked onto a web link without getting mangled):

AAAAAAANAgEDAgQAqFoKAwUfmgEAAAANAgEDAgQAwAxZRQUMlQ==

Basically, SDB is multi-URL shortening on steroids but it doesn’t require any external services and you can store lots of additional information with it.

Plus, you can encrypt the SDB if you want to share it in public without giving away the details to anyone without the password. This is very useful if you have private connections that change regularly, kind of like dynamic DNS.

There are technical details available if you want to nerd out and a simple-to-use JavaScript library if you just want to include it in your project(s). It also comes as a npm module for Node.js (my first one!)

Up next: more cryptos!

Implementing the connectivity options took a little longer than I’d wanted, thanks in part to the lofty promises of WebRTC. But until it’s time to revisit the software’s connectivity options, and other than fixing whatever bugs pop up, I think I can safely turn the page to start on the next big thing and that will be the addition of desktop (native) cryptocurrency support which will include other currencies such as Bitcoin Cash and Monero.

Lumping the implementation of BTC and BCH support together makes sense since they’re both extremely similar, down to their APIs and the way that transactions are generated.

Support for Monero will be a little different when implemented but the transaction fees are currently very attractive and addition of the cryptocurrency was requested (I do listen to suggestions!) so I it’s on the schedule.

I haven’t nailed down any steps beyond the stated cryptocurrencies support but adding Ethereum smart contracts and support for Tor as another peer-to-peer networking option will definitely be in there somewhere.

In any event, there’s going to be no shortage of work and I’m actively seeking help. If you’re a UX designer, front-end dev, or Node.js coder, I’d love to hear from you.

Configuring the desktop client and it’s services is something that’ll need to be built into a user interface, and soon. This is mostly brand new work without much deep integration so in my opinion it’d make a great introductory item to implement.

I’ve also tagged some issues and included detailed information for anyone wanting to jump into similarly new-ish development or, if you prefer to fiddle with the user interface of the software in a less structured way, there’s a general guide available to get you started.

And, of course, if you’d like to help as a user there’s plenty of testing to be done, both in actual game play and in setting up and running the services. For this it’d actually be beneficial if you don’t have much technical expertise since (ideally) you shouldn’t need it.

Drop me a line here, on GitHub, on the subreddit , or on Twitter regarding any of the above topics or with questions/comments and I’ll be in touch ASAP (I don’t have regular internet access so I can’t promise it’ll be immediate).