To be honest, I seriously doubt anyone is going to have time to put multiplayer action into their jam games.
Well, if people have their own codebase to work from, anything is possible. My own library includes things ranging from compression functions, router reset and IP rotation, automatic imageshack URL uploads (under registered accounts) to (now non-functional) SMTP email, to pulling image links from the GOES satellite weather website, earthquake data from USGS, efficient text parsing systems, 'conversation' text generator (that works by script), basic musical instrumental script system (that can play multiple instruments in parallel).
In-fact, part of the codebase is used to post to a forum to demonstrate how false information can be broadly propagated by automated systems (which combines the automatic image uploading, etc). I've had to reconstruct some fundamental classes (being able to access, read and remove header fields from a HTTP request is highly important in uploads, SFML has it set to private and therefore inaccessible to even subclasses). I suspect people's ingenuity is unlimited. I mean, imagine a forum based computer game?
I'm planning to offer up the compression algorithm to SFML (no licence, public domain) at some point after I clean up and finish testing the recursive functions. It's not a fantastic algorithm (don't expect it to be on par with gzip), and it's written using C programming style (so it would probably need to be encased such to be C++ in classes or namespaces), but...
...It'd have no licensing terms (public domain, no need for credit or anything or additional license bulk), works with pre-existing std::string, configurable settings (so if it's taking too long, you can simplify the pattern search, and if it's not compressed enough, you can increase the complexity). Settings don't affect the receiving end (so you can decompress a heavy level search compression just as you would a light search, no need to communicate settings). It can handle machine code and text code alike, so you can feed in file data raw and it'll spit out the compressed version (however, it's optimised towards text-based data: the more randomised the data stream, less returns you get, and if there are no returns to be had, it doesn't compress the data stream).