How to Try Egonex ECP in .NET 8 and Send Emergency Alerts with an 8-Byte Payload

#emergency #dotnet #iot

Disclosure: I was asked by the ECP team to evaluate their SDK and write an honest review. All opinions are my own.

Emergency alerts are usually discussed in terms of speed, reach, and reliability. But there is another variable underneath all of that that matters just as much in practice: how much data the system has to move to describe the alert in the first place.

That is part of what makes ECP, short for Emergency Communication Protocol, interesting. In the default ProofCard run, the sample produces 669 bytes in CAP XML, 270 bytes in JSON, and just 8 bytes in ECP’s UET format. When modified to the earthquake scenario used in this walkthrough, the output becomes 686 bytes in CAP XML, 279 bytes in JSON, and still 8 bytes in ECP UET. The project also reports an average 96 percent data reduction. Those numbers are striking enough that they deserve more than a quick skim of a README.

They are also interesting for reasons beyond a neat benchmark. In emergency systems, smaller payloads can matter when alerts need to move across constrained or failure-prone links, and many public-warning delivery channels still impose practical size or formatting constraints on what can be transmitted. For low-bandwidth deployments or any workflow where overhead matters, the difference between a few hundred bytes and a single-digit payload is not just cosmetic. It can shape how efficiently a message is encoded, transmitted, retried, and inspected.

This article walks through the practical side of that claim using the open-source .NET 8 SDK. The goal is simple: clone the repository, get the environment working, run the tests, execute the samples, modify one of them, generate a real payload, and then verify the result in ECP Studio. By the end, the point is not just to repeat that ECP is compact, but to see what the workflow actually looks like when the SDK is run locally and the output is validated step by step.

Getting set up

The setup path is straightforward on paper. The repository can be cloned, restored, and tested through the normal .NET CLI flow, which makes this feel familiar if you have worked through a standard .NET repository before.

git clone https://github.com/Egonex-Code/ecp-protocol.git
cd ecp-protocol
dotnet restore
dotnet test

There was, however, one environment issue worth mentioning because it is the kind of thing that can derail a hands-on review early. In the local run, dotnet test initially failed with a missing Microsoft.NETCore.App 8.0.6 message because the machine only had .NET 10 installed while the solution targeted net8.0. Installing the .NET 8 SDK resolved the version gap, but the shell was still resolving dotnet to an older local install under .dotnet, so the PATH had to be corrected before the CLI started returning an 8.0.4xx build.

Once the environment pointed at the right SDK, the rest of the process snapped into place. The repository restored successfully, and the full test run passed across the solution, which is exactly the kind of baseline confirmation worth getting before drawing any conclusions about the SDK itself. That also helped separate an environment problem from a repo problem, which is always useful when writing about a developer workflow.

Since this run, the repository added a global.json pin with rollForward: latestFeature (released in v2.0.6), so new clones should not run into the same SDK resolution issue.

Figure: Full dotnet test run on net8.0 passing across the ECP solution.

Running the samples

The best place to start after setup is the ProofCard sample because it makes the central claim visible almost immediately. In the default run, the sample output shows CAP XML at 669 bytes, JSON at 270 bytes, and ECP UET at 8 bytes. In the modified earthquake run from this walkthrough, the output is CAP XML at 686 bytes, JSON at 279 bytes, and ECP UET still at 8 bytes.

That is the moment where the protocol starts to feel concrete. It is one thing to read that a format is compact; it is another to run a sample and see the same alert represented across multiple encodings with the byte counts sitting side by side in the console. The ProofCard sample works well because it does not bury the value proposition in pages of explanation. It just shows the numbers and lets them do most of the work.

Figure: ProofCard size comparison output showing CAP XML vs JSON vs ECP UET.

Figure: Byte comparison chart for the Fire scenario (CAP XML 669, JSON 270, ECP UET 8).

To make the exercise more than a copy-and-run test, the next step was to change the scenario. The local notes modified the sample from a fire scenario to an earthquake scenario, updated the zone hash to 2002, and switched the alert call to EmergencyType.Earthquake. That change produced output identifying the scenario as EARTHQUAKE / Zone 12, along with a new proof hash and a generated payload, which made the sample feel like an actual SDK surface rather than a fixed demo.

A simplified version of the alert call looked like this:

var alert = Ecp.Alert(
    EmergencyType.Earthquake,
    zoneHash: 2002,
    priority: EcpPriority.Critical,
    timestampMinutes: 12345
);

This is one of the more encouraging parts of the SDK experience. At the level tested here, the API surface for a basic alert does not feel huge, and the changes needed to move from the default scenario to a custom one are small enough to follow without getting lost in abstraction.

Another sample worth checking is the signed-envelope round-trip flow. In the local walkthrough, that sample generated an HMAC key, encoded an envelope, and then attempted validation with both the correct key and the wrong one. The wrong-key path returned IsValid False, which is a compact but effective demonstration of validation and tamper detection behavior.

Figure: ECP.Sample.Minimal plus 02-EnvelopeSignedRoundtrip, including wrong-key verification failure (IsValid: False).

Figure: Signed-envelope decode flow showing valid-key success and wrong-key failure.

Verifying in Studio

The most satisfying part of the process came after generating a real payload locally. Running the modified sample with payload output enabled produced the UET hex value 2C001F48C0E40000, which then became the input for the browser-side verification step.

Pasting that value into ECP Studio’s Decode tab parsed it back into the same fields used in the sample, including EmergencyType: Earthquake, Priority: Critical, ZoneHash: 2002, and TimestampMinutes: 12345. That round-trip is what ties the whole workflow together. The code generates the bytes, the browser tool decodes them, and the fields line up without needing an extra helper script or custom parser.

Figure: dotnet run -- --show-payload output, including CAP, JSON, and UET hex (2C001F48C0E40000).

Figure: ECP Studio Decode tab parsing 2C001F48C0E40000 into Earthquake/Critical/ZoneHash 2002/TimestampMinutes 12345.

Studio also helps with the part of the protocol that is harder to communicate through prose alone: comparison. The local notes mention using the Compare tab to make the size differences easier to grasp visually as scenarios change, which gives the browser tool a real role beyond simple decoding. It becomes a practical companion to the SDK rather than just a nice extra.

This is also where the broader implication of the compact payload starts to click. If a machine-readable emergency alert can be represented in 8 bytes for its core form while equivalent CAP XML and JSON representations are measured in the hundreds of bytes in the same sample, that can matter in emergency systems, low-bandwidth environments, and any workflow where message overhead competes with transport constraints or reliability goals. Even when the surrounding system still needs richer metadata, logs, signatures, or interoperability layers, reducing the size of the core alert token can change the shape of the transmission problem.

What stands out

What stands out most after running through the SDK is not that the repository is unusually complex. It is that the path from install to validation is fairly short once the machine is pointing at the correct .NET 8 environment. The repository tests provide a clear baseline, the ProofCard sample shows the size difference immediately, the scenario changes are easy to follow, and Studio closes the loop by decoding the locally generated payload back into readable fields.

That is what makes the 8-byte claim more interesting than a headline. In this case, it was not just a number in project copy or a benchmark repeated from a README; it was something that could be reproduced locally, inspected in the console, modified through a small code change, and verified through the project’s own browser tooling.

For developers working near emergency communications, constrained networks, or systems where payload size affects efficiency, the practical takeaway is straightforward. ECP becomes much easier to evaluate once it moves from an abstract compression claim to a concrete engineering workflow: clone the repo, run the SDK, generate the alert, and verify the bytes yourself. And that is really the point of a hands-on review like this one: not just to admire the 8-byte number, but to test whether the path from idea to validation is real. Developers who want to work with the encoder and decoder directly can start with the ECP.Core package on NuGet.