Open protocol for soaring flight data

Your flights.
Your identity.
You decide who sees them.

igc-net gives every pilot a portable cryptographic identity and protocol-level control over who can access their flights, across every participating portal.

Without igc-net
Portal A
Portal B
Portal C

Same flight. Three silos. Three identities. No control.

With igc-net
pilot identity pilot_id
Portal A
Portal B
Portal C

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.

The ecosystem has portals. Pilots have no control.

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.

Scattered 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.

No cross-portal privacy

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.

No selective sharing

You cannot share a private flight with your club without making it public to everyone. Private and public are binary, platform-defined states.

Your data dies with the platform

If your home portal closes, your flight history goes with it. There is no neutral layer beneath portals that keeps your data alive.

A best-effort public census completed on 9 April 2026 identified at least 16 active public portals and services handling IGC upload, viewing, scoring, or storage. None provides standardised cross-platform exchange, shared identity, or a neutral long-term archive.

One identity. Every portal. Yours forever.

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.

Your root identity

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

Your login credential

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

Your access key

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
pilot
You
Portal A
Portal B
Portal C
Future portal

The same identity, recognised everywhere. You carry it with you.

Technically curious? The full cryptographic model is in the protocol specification.

Three modes. You choose. The protocol enforces.

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.

Public

Open to everyone

  • Full track visible to anyone
  • Discoverable on every participating portal
  • Can be archived by any node

Good for flights you want fully open: competitions, showcase flights, community sharing.

Protected

Track without your identity

  • Track visible to anyone
  • Your name, wing type, and personal details are removed from the public version
  • Full raw file visible only to portals you trust

Good for flights you want shared without exposing your identity in the public record.

Private

Visible only to you

  • No content visible to the public
  • Full raw file visible only to portals you trust
  • The flight's existence may still be announced on the network, but its content is not

Good for training flights, early experiments, flights you never want publicly visible.

Private access grants: under your control

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.

Share with the right people, not the whole internet.

Groups let you share private flight access with specific pilots, without changing your publication mode and without giving away your access key.

Private group

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.

Public group

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.

Follow

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.

Private group access
pilot
You (owner)
Private group
M1
Club mate
M2
Coach
M3
Student
Members can fetch your private flights
Cross-portal group
Portal A
P1
Portal B
P2
Portal C
P3
Same group
Shared access across every portal they use

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 is not a competing portal.
It is a shared protocol that portals integrate.

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.

Connect to an existing network

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.

What integration gives you

  • Pilot identity and authentication via passkey
  • Cross-portal flight discovery without bilateral agreements or scraping
  • Access-control enforcement without building key management
  • Group and social graph without building a friend system
  • Archival durability on university infrastructure

Integration path

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.

igc-net network: example node topology
Paragliding Site Publisher + Indexer Archival Eager policy Relay Metadata only DHV GeoFiltered (DE) Research GeoFiltered (Alps) DHV-XC Publisher + Indexer new flight Gossip Blob transfer
For pilots, portal teams and the soaring community

igc-net Whitepaper v0.3

Overview of the protocol, privacy model, and groups. Start here.

Download PDF →
For implementers and researchers

igc-net Technical Report v0.1

Wire-format architecture, gossip protocol design, and project history.

Download PDF →

Built on a few strong ideas

Pilot-owned identity Your pilot_id is a cryptographic credential you hold, not a platform-assigned account number
Fine-grained access control Three publication modes enforced at the protocol layer, not by portal policy
Group-based sharing Selective access for specific pilots without changing publication mode
Content-addressed Identical bytes produce the same BLAKE3 hash everywhere, with no duplication across portals
Decentralised No central server, no registration, no approval needed to participate
Protocol-first Language-independent specification; Rust reference implementation; Python wrapper
Geographic filtering Build local or national archives automatically by bounding box, without bilateral agreements
Archival retention Flights remain retrievable while at least one archival node continues to retain and serve them
Extensible analytics Invalid-track detection, safety signals, thermal and wind estimates, and scoring. Open to multiple providers.

Start using igc-net

For Pilots

igc-net becomes available to you when your portal integrates it. Ask your portal team to support igc-net.

Share this site

If you fly with people who care about flight data privacy and portability, point them here.

Read the Pilot Guide

Understand what igc-net gives you: identity, privacy modes, groups, and revocation.

Pilot Guide →

Talk to us

Questions, feedback, or just want to say hello? Find us on Telegram.

Telegram group →

For Developers and Portal Operators

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.

Read the Spec

The normative protocol specification. Language-independent, versioned, and open.

github.com/igc-net/specs →

Try the Rust implementation

cargo install igc-net-cli igc-net announce flight.igc github.com/igc-net/igc-net-rs → docs.rs/igc-net →

Python wrapper

pip install igc-net PyPI package → github.com/igc-net/igc-net-py →

Portal Operator Guide

Practical guide for portal teams covering integration scope, access categories, and requirements.

Portal Operator Guide →