Skip to content

The path to 0.5

Six stages, each usable on its own and building on the one before. Open Why this takes time on any stage for the detail.

Indicative timeline

Stage Dec Jan Feb Mar Apr
1. Foundations ■ ■
2. Access ■ ■
3. Teams ■ ■
4. Live operations ■ ■
5. Services ■ ■
6. Bundles and release ■ ■

Timing is indicative, from December 2026 to April 2027, and depends on each stage's checks passing. Stages overlap where they do not depend on each other.

1. Foundations: a faster, safer console

Winter 2026

  • The new Web Console
  • Single sign-on and licence management, as in 0.4
  • More reliable Egress Server builds
  • A security review of every part of the system's interface
Why this takes time

0.5 is built on a new, faster platform underneath, developed alongside the 0.4 releases you run today. Everything 0.4 gained in that time, such as sign-in, licensing and reliability fixes, has to be carried across.

  • Rebuilt, not copied. The way the console talks to the server changed in 0.5, so each 0.4 improvement is re-implemented and re-tested on the new platform.
  • Security review first. Before adding new ways for people to get access, we are checking that every existing action is properly restricted, and fixing what isn't.
  • One interface, not two. We finish the new console before adding features, so nothing is built twice.

2. Access: roles and groups

Early 2027

  • Administrator, operation lead and team member roles
  • Groups of people, with control over who sees which group
  • A record of every change to users, groups and operations
Why this takes time

Today Waveshift knows two kinds of user: administrators and everyone else. Roles touch every action in the system.

  • One rule book. Every action moves onto a single, central permission check, so access is decided the same way everywhere.
  • Tested per role. Each action is tested for every role, so a team member can never do what only an administrator should.
  • Nobody's access changes on upgrade. Existing users and Sites move into the new groups exactly as they are today.

3. Teams: callsigns and outside participants

Early 2027

  • Reusable team lists by callsign
  • Outside participants without a Waveshift account
Why this takes time

A callsign becomes a person's identity in several systems at once: the VPN, the map and the chat.

  • Different naming rules. Each of those systems has its own rules for names, so callsigns need one set of rules that works in all of them.
  • People who never log in. Outside participants need real accounts in the map and chat, without an account in the console, and with a clear way to remove them.

4. Live operations: change the team as you go

Spring 2027

  • Launch an operation straight from a team list
  • Add or remove people while it is running
  • Removal cuts VPN, map and chat access together
Why this takes time

Today an Egress Server's peers are fixed when it is built: changing who can connect means rebuilding it.

  • Changing a live network safely. People are added and removed while others are connected, without interrupting them.
  • All or nothing. Removing someone touches the VPN, the map and the chat. If any step fails, the change is rolled back rather than leaving them half removed.
  • Tested at every failure point, because a partial removal is the one mistake that must not happen.

5. Services: secure chat and a shared map for each operation

Spring 2027

  • Private messaging (Matrix) per operation
  • Situational awareness (TAK) per operation
  • Both created and deleted with the operation
Why this takes time

Both services already run as wsctl plugins, deployed and tested end to end. This stage brings them into the console and makes them meet the assurance bar for defence use.

  • Your own copy of the software. Service software is held in your environment, pinned to an exact version and signature-checked, so nothing changes without you knowing.
  • Kept patched. A rebuild pipeline keeps that software within patching timescales such as Cyber Essentials Plus.
  • Encrypted with keys you own, so deleting an operation and its keys makes its data unrecoverable.
  • Automatic, every time. Each operation gets its own servers, named for that operation, created and removed without manual steps.

6. Bundles and release

Spring 2027

  • One bundle per person per operation, as a file or QR code
  • Handover to outside participants, recorded
  • The 0.4 console retired; 0.5 released
Why this takes time
  • Credentials are issued once. Downloading a bundle again issues fresh credentials, so a lost bundle can be replaced without reusing the old one.
  • A full rehearsal before release. Every release candidate runs a complete operation end to end: build the team, launch, hand out bundles, change the team, close, and confirm everything is gone.

Common questions

Will our current deployment keep working?

Yes. 0.4 stays supported until you move to 0.5, everything in 0.4 carries forward, and existing Egress Servers keep working after the upgrade.

Do outside participants need a Waveshift account?

No. The operation lead adds them by callsign and hands them their bundle. They only ever reach that operation's chat and map.

What do team members need to install?

The WireGuard app for the VPN, a TAK app (ATAK, iTAK or WinTAK) for the map, and a Matrix app for chat. The bundle sets each one up and includes the certificate their device needs to trust the operation's servers.

Can one person be in two operations?

Yes. They keep a bundle for each on the same device and switch between operations. They have a separate identity in each, so nothing they share in one operation reaches the other.

What happens to messages and map data when an operation ends?

They are deleted together with the operation's servers. If you need to keep records, keep them before the operation is closed. How records are kept will be shaped by what you tell us: we are building this platform around our customers' needs and requirements, so it works the way you do.