network.yaml - HackerRivals Winner @ Vancouver Cloud Summit 2026

network.yaml is a conference networking app built for Cloud Summit attendees who want a faster way to find people they actually have something in common with.

Attendees scan an event QR code, fill out a short "config" about themselves, and get indexed into Elasticsearch. From there, the app builds a personal network graph from shared profile values: same editor, same OS, same first programming language, same school, same region, same company, or same role.

The result is a networking experience that feels closer to searching a live cluster than scrolling through a badge list.

What It Does

network.yaml turns attendee profiles into searchable, matchable documents.

Each attendee creates a lightweight profile with:

• name
• email
• role
• company
• education
• editor
• os
• first_programming_language
• country_of_origin

Elasticsearch stores and searches those profiles. The frontend then uses the results to power two main experiences:

• your network: a force-directed graph centered on the current attendee, showing people with shared values.
• search the cluster: a search page where attendees can search by name, role, company, editor, OS, language, school, or origin.

There is also an organizer-only event flow. Organizers create an event, generate a QR check-in link, and attendees enter through that QR code.

Why We Built It

Conference networking is usually awkward because the useful context is hidden. You see a name badge, maybe a company, and then you have to guess whether there is a good conversation there.

network.yaml makes the context visible immediately. If two people both use Neovim, started with Python, studied at UBC, or came from the same region, the app shows that connection directly.

The product is intentionally playful. People are represented like YAML config, but the matching is real.

Core Flow

1. An organizer creates an event from the internal event console.
2. The app generates a QR code for /checkin/{event_id}.
3. An attendee scans the QR code.
4. If their email exists, they confirm check-in and go to your network.
5. If their email does not exist, they complete the signup form, confirm check-in, then go to your network.
6. Their profile is stored in Elasticsearch and becomes discoverable to everyone else.

Product Surfaces

your network

The main graph view. The current attendee is the center node. Everyone connected to them shares at least one profile value.

More shared values means a stronger graph connection.

search the cluster

A fast attendee search powered by Elasticsearch. Users can search across public profile fields and open any result as a config.yaml profile card.

config.yaml

Every attendee profile is shown as a YAML-inspired card:

# config.yaml
name:           Jane Doe
role:           Backend Engineer
company:        Stripe
alma_mater:     UBC
editor:         Neovim
os:             Linux
first_language: Python
region:         Vancouver, CA

When viewing someone else's profile, the app also shows shared values and a small compatibility verdict.

Organizer QR Mode

The event creation page is intentionally kept out of the main user navigation. It is for organizers and demos.

From the internal event console, an organizer can create an event and display a QR code that attendees scan to join and check in.

The exact route is intentionally not documented here because it is not part of the public attendee flow.

Architecture

Browser
  |
  v
Vercel React frontend
  |
  | /backend/*
  v
Vercel FastAPI backend
  |
  v
Elastic Cloud / Elasticsearch

The repo uses Vercel Services:

• frontend/ is a Vite React app mounted at /.
• backend/ is a FastAPI service mounted at /backend.
• vercel.json wires both services together from one repository.

Tech Stack

• React
• Vite
• FastAPI
• Elasticsearch
• Elastic Cloud
• Vercel Services
• D3 force simulation for the normal network/search/profile graphs
• Three.js for the organizer live event wall
• QR code generation for check-in links

Elastic Usage

Elastic is not just a bolt-on integration here. It is the core data layer.

• Storage: attendee profiles, events, and records are stored as Elasticsearch documents.
• Search: profile search runs through Elasticsearch across attendee attributes.
• Matching: related users are derived from indexed profile values.
• Demo visibility: health checks expose whether the Elastic cluster is configured and reachable.

Repository Structure

.
├── assets/             # Shared static assets, exports, screenshots, and references
├── backend/            # FastAPI service for users, events, check-in, search, and matching
├── frontend/           # React interface for QR entry, network graph, search, and profiles
├── ARCHITECTURE.html   # Visual architecture artifact
└── vercel.json         # Vercel Services routing

Design Language

The brand is a light parody of cloud config files:

• Product name is always network.yaml.
• Profiles are treated as config.yaml.
• Signup is framed as "deploying your config."
• Search and matching explicitly reference Elasticsearch.
• The UI stays dark, terminal-adjacent, and Elastic-colored without becoming unreadable.