javaminecraftnixosdevopscommunity
contribution

I work on the backend, the security and reliability aspects of the Eden infrastructure. I maintain the NixOS deployment, and work on authentication, guild-log synchronisation, reward system, verification (releases, certificates, etc.) among others.

Eden is our guild on Wynncraft, a Minecraft MMORPG. A lot of guild life happens in Discord, while the actual game has its own chat, parties, and logs. EdenMod connects those pieces and gives members tools that fit into the game client.

It is a client-side Java/Fabric mod, published on Modrinth. The mod is the public part of a larger system that also includes a Discord bot, a database, a guild website and the infrastructure running them.

EdenMod's command help and a guild conversation containing both in-game and Discord messages.
The config screen of EdenMod.

Keep the conversation together

The mod captures guild chat and sends it to the backend over an authenticated WebSocket. Discord messages return through the bridge and are displayed in-game. Around that core are raid-party tools, Annihilation parties and timers, custom emotes, shared-item previews, territory overlays and guild-management screens.

The client has to cope with reconnects, world changes, account changes and overlapping events. Some of my work here involved serialising outgoing messages to avoid races, handling version changes and authentication retries, and keeping the client and backend protocols in step.

A simplified flow: EdenMod sends guild events to the bridge backend, which relays messages to and from Discord and records guild activity in PostgreSQL.
The bridge, simplified. The mod is public; the backend and deployment are maintained separately.

Identity and updates

The current WebSocket client proves that the connecting player holds a live Minecraft session through a Mojang challenge/response exchange. The Minecraft access token goes to Mojang; the bridge verifies the resulting session proof. Account linking and guild membership are handled alongside that connection identity.

I also worked on the update path. The installer checks the JAR digest and verifies GitHub/Sigstore attestation data, including the signing certificate chain, identity and signature. Related build tooling checks the embedded trust root’s freshness. This is release-verification work, rather than just downloading a file with the right name.

The release workflow runs checks and tests, builds the mod, and publishes versioned releases to GitHub and Modrinth. I contributed the release integration, verification work and JUnit test infrastructure.

Making guild records agree

Some useful guild information is available through Minecraft menus and logs rather than a convenient API response. I worked on reading those structures, parsing them into events and synchronising them with the backend.

Reward payouts make this particularly interesting. Log entries can arrive late, repeated-looking entries can be genuinely distinct, and a cancelled operation has different accounting from a failed one. The implementation reconciles confirmed outcomes against a log baseline, refreshes stale baselines and distinguishes explicit rejection from a missing confirmation before retrying.

The guild-log implementation and its tests capture those edge cases. Other work includes reading seasonal rating from raid results and keeping that data in sync with the guild’s records.

Running the surrounding services with NixOS

I maintain the declarative NixOS deployment for the guild’s services. It ties together Podman containers, PostgreSQL, nginx, sops-managed secrets and systemd. Container images are delivered through the registry and updated through Podman’s auto-update service, which I wrote about in the Lab.

The operational details matter here too: starting services after the database, giving the bot time to finish critical work during shutdown, separating application database access, and scheduling encrypted PostgreSQL backups with Borg. These are parts of the running deployment, alongside the mod’s own distribution pipeline.

I also contributed PKCE handling and WebAuthn passkey login to the Next.js guild website. The bot, website and infrastructure repositories are private; the mod’s public history provides the most directly inspectable part of this work.