igc-net gives every pilot a portable cryptographic identity and protocol-level control over who can access their flights, across every participating portal.
Same flight. Three silos. Three identities. No control.
One identity. Every portal. Your rules.
Developed at NTNU Distributed Systems Engineering Lab, a public university research environment. Ongoing work includes providing archival capacity on university infrastructure.
There are at least 16 active portals and services handling IGC upload, viewing, scoring, or storage. None of them interoperate, and none of them give the pilot ownership of their own flight identity.
The same IGC file gets a different ID on every platform. Your 10-year flight history is split across six portals with no common thread.
Privacy is a per-portal setting, not a pilot right. There is no way to keep a flight private on one portal and share it on another. Each portal decides its own rules.
You cannot share a private flight with your club without making it public to everyone. Private and public are binary, platform-defined states.
If your home portal closes, your flight history goes with it. There is no neutral layer beneath portals that keeps your data alive.
When you register on an igc-net-enabled portal, you get a cryptographic identity that belongs to you, not the portal. You can take it to any other igc-net portal. If your home portal disappears, your identity and flight history travel with you.
A cryptographic key generated once and held by you or your home portal. Every flight you upload is anchored to this identity. It never changes, even if you move to a different portal.
pilot_id
A separate credential you use to log in to portals. If it is ever compromised, you replace it. Your root identity and flight history are unaffected.
pilot_auth_did
Controls which portals can read your private flights. Grant it to a portal you trust. Revoke it when you no longer do. Revocation takes effect immediately across the network.
private_access_keypair
The same identity, recognised everywhere. You carry it with you.
Technically curious? The full cryptographic model is in the protocol specification.
Every flight you upload gets a publication mode. The mode determines what the network can see. You can change it at any time, and the change takes effect immediately on every compliant portal.
Good for flights you want fully open: competitions, showcase flights, community sharing.
Good for flights you want shared without exposing your identity in the public record.
Good for training flights, early experiments, flights you never want publicly visible.
You give a trusted portal your access key. It can now access your protected and private flights. When you revoke the key, or rotate it because you no longer trust a portal, that portal loses access immediately, enforced across every compliant portal on the network.
This is a protocol-level guarantee.
Not a portal's policy. Not a terms-of-service promise.
Groups let you share private flight access with specific pilots, without changing your publication mode and without giving away your access key.
You create a group and add your club mates or students. They can now access all of your private and protected flights, without any change to your publication mode. No one outside the group can access them.
Your coach can see all your training flights. The rest of the world cannot. You did not change a single flight's settings.
An opt-in collective. Every member's flights, regardless of publication mode, become accessible to all other current members. Membership is by invitation and explicit acceptance.
Join your club's group. The whole club sees your flights and you see theirs, even the private ones. Leave the group and access ends.
Subscribe to another pilot's uploads. See when they fly. Your access to their flights follows their publication mode. If you share a group with them, you can see their private flights too.
Follow a colleague. Get notified when they post a new flight. If you are in their group, you can see the full private track.
Groups and follow are part of the protocol specification, not a feature any portal has to build separately. When a portal integrates igc-net, its pilots' groups and social connections work across every other igc-net portal they use.
igc-net defines the exchange rules so portals can interoperate. Your portal keeps full ownership of its UX, analytics, community, and monetisation. Integration uses a gRPC sidecar alongside your existing backend.
Pilots using igc-net already have a portable identity, flight history, access preferences, and social graph. A portal that integrates igc-net connects to these directly, without rebuilding them from scratch.
igc-net uses BLAKE3 content addressing, Ed25519 signatures, and canonical JSON for deterministic signing. The transport is iroh. The reference implementation is a Rust library with a gRPC sidecar interface.
Overview of the protocol, privacy model, and groups. Start here.
Download PDF →Wire-format architecture, gossip protocol design, and project history.
Download PDF →pilot_id is a cryptographic credential you hold, not a platform-assigned account number
igc-net becomes available to you when your portal integrates it. Ask your portal team to support igc-net.
If you fly with people who care about flight data privacy and portability, point them here.
Understand what igc-net gives you: identity, privacy modes, groups, and revocation.
Pilot Guide →The protocol, specification, and reference implementations are open. Integration uses a gRPC sidecar that runs alongside your existing backend, so you do not need to replace any of your current stack.
The normative protocol specification. Language-independent, versioned, and open.
github.com/igc-net/specs →cargo install igc-net-cli
igc-net announce flight.igc
github.com/igc-net/igc-net-rs →
docs.rs/igc-net →
Practical guide for portal teams covering integration scope, access categories, and requirements.
Portal Operator Guide →