WorldsClient

A modification of the Worlds.com client and a launcher for running it on Linux. It is built on your machine from a client you already have.

Guide: building and using it →

What it adds

Feature	What it does
Security fix	The client will no longer run programs downloaded from servers you have not trusted. Why this matters.
Chat encryption	Optional. Messages between people sharing a passphrase are encrypted; the server and the network see only ciphertext.
Server selector	A list of servers, in the launcher and in a menu inside the client, instead of hand-editing `.ini` files.
Stability fixes	Guards on the paths where a server, or the renderer, can make the client misbehave.
Mods in Lua	A folder of Lua the client loads at startup. There is a guide.
Bots	Programs that log into a server as clients of their own, visible to everyone.
HTTPS	On a runtime whose own TLS stopped being usable years ago.
Two kinds of server	It works out whether it reached a legacy server or an extended one, and behaves as the original client does on the first.

One checkbox on the first tab of the startup menu, Disable every modification, turns all of it off and leaves the stock client behaving exactly as it always did. That switch is the first thing to know about it.

The security fix, in detail

Unmodified, the client downloads WorldScript*.class files from whatever address is currently configured as its content server and hands them straight to defineClass. Those classes then run with the full rights of the person playing: their files, their network, everything.

Any server — hostile, or merely one whose content host has been taken over — can run arbitrary code on the machine of everyone who visits. This is not specific to any operator; it is the design, and it has always been true.

The modification refuses downloaded code unless it comes from a host you have accepted. The server you are configured to connect to counts as accepted, so ordinary play is unchanged; anything else has to be allowed deliberately. Four modes are available, from refusing everything to the original behaviour, which is kept for compatibility and labelled for what it is.

The stability fixes

A zero update interval no longer breaks movement. VAR_UPDATETIME travels in microseconds and the client divides by a thousand. A server that sends milliseconds by mistake leaves the client dividing by zero, and every remote avatar freezes or flies off. The interval is now floored.
The dead upgrade check is off, and only that. The rest of your configuration is left alone.
The script server is written where the client actually reads it. It is looked up in override.ini's [Runtime] section, not worlds.ini's [Gamma]. With nothing there the client falls back to a dead address and every custom avatar silently becomes the default one.
Assertion failures while building are guarded. The renderer used to raise an assertion when asked about an object with no live geometry. Four call sites now check first.

How it is built

The client is decompiled, repaired, patched and recompiled. Every step is a script, so the whole thing can be redone from a newer jar. The modification's own code is separate from the client, and the client is touched in exactly seven places, each of which only calls into that package — every one listed, with its before-and-after text, so anyone can check it.

Full walkthrough: the guide.