Microsoft’s new Phone Link can also let you make and receive calls and mirror your iPhone’s notifications to your Windows PC.

A first look at using iMessage from a PC with Microsoft’s Phone Link app

As the lead engineer for our Bluetooth messaging and contact sync stack, I designed and implemented the Message Access Profile (MAP 1.1) and Phone Book Access Profile (PBAP 1.1.1), both essential for enabling iMessage, SMS, call history, and contact integration between iPhones and Windows PCs. I crafted the architecture for both profiles, implemented the majority of the codebase, and built the automated test infrastructure to validate their functionality. Due to platform limitations—specifically, the lack of L2CAP support in Windows user-mode applications—we were restricted to legacy RFCOMM-based versions of the profiles (MAP 1.1 and PBAP 1.1.1). While newer versions existed, they required L2CAP and were therefore out of reach, making timely qualification of the older specs absolutely critical. I joined the Bluetooth Special Interest Group (SIG) and took full ownership of the official qualification process, completing all required compliance testing, documentation, and coordination to obtain the licenses and patent rights necessary for shipping. I also represented Microsoft at the SIG’s UnPlugFest, where I tested our implementation with real devices from Apple, Google, Samsung, and others to ensure interoperability. Thanks to early delivery and rigorous validation, we qualified both profiles before their official deprecation deadline. Missing that window would have made it legally and technically impossible to ship these features—potentially derailing the entire iOS cross-device effort.

MAP & PBAP Bluetooth Profile Implementation – Core to iOS Cross-Device Functionality

Apple’s walled garden has long limited third-party developers from enabling deep integrations with iOS. For years, this made it virtually impossible to support meaningful cross-device functionality between iPhones and Windows PCs. I co-developed a pitch with my manager and coworker proposing a bold workaround: leveraging Bluetooth to enable seamless cross-device features, inspired by how iPhones interact with modern cars. Our proposal included working prototypes for initiating and receiving phone calls, sending and receiving iMessages, syncing call history and contacts, and displaying iOS notifications—all on a Windows PC paired with an iPhone. The demo impressed leadership all the way up to the Corporate Vice President level (two steps from the CEO), securing executive buy-in to greenlight the initiative.

iOS: Solving Apple's Walled Garden

To streamline onboarding for our iPhone + Windows cross-device experience, I proposed leveraging Apple’s then-new App Clip framework to eliminate friction for first-time users. At the time, App Clips were completely uncharted territory within Microsoft. I pitched the idea to leadership: users could scan a QR code from the Phone Link app on their Windows PC using the iPhone’s native camera, instantly launching a lightweight App Clip for our iOS companion app, Link to Windows. Within seconds—no App Store visit required—users could consent, pair their iPhone via Bluetooth, and unlock calling, messaging, contacts, call history, and notification sync on their PC. I built the initial prototype, secured executive buy-in, and led the feature through to production. This App Clip experience became the primary onboarding path, ultimately accounting for well over two-thirds of all new user activations and playing a pivotal role in the product’s success. We were also the first team at Microsoft to ship an iOS App Clip in a live product.

iOS App Clip

Microsoft is updating its Phone Link app to support file sharing to iPhone devices. It allows a Windows PC to send or receive files from an iOS device.

Microsoft starts testing iPhone file sharing for Windows PCs

Two years after launching our Bluetooth-only iOS integration, we expanded Phone Link to support Microsoft Account (MSA) sign-in—unlocking advanced features like cross-device file sharing between iPhones and Windows PCs. I led the engineering effort to evolve our onboarding system into a hybrid model supporting both Bluetooth and MSA-based pairing. This was a critical-path dependency for launching file sharing, as highlighted in The Verge’s coverage. This onboarding flow introduced substantial UX and architectural complexity. I collaborated closely with product managers and designers to craft an experience that was flexible yet intuitive. Users could onboard via an App Clip-powered Bluetooth flow—requiring no app install—or opt into a full app experience for enhanced capabilities like file sharing via MSA. Full app onboarding also supported both methods from the outset, and the Phone Link Windows app had to accommodate all permutations seamlessly. My work enabled millions of users to get connected in seconds while providing a smooth path to richer features like file sharing—delivered on top of the robust foundation I built.

iOS File Share

The Spatial Weather System is a sophisticated cloud-based platform that processes and serves meteorological data through a secure, scalable infrastructure. At its core, the system fetches GRIB2 weather data on a fixed interval, processes it into a geospatial format, and makes it available for efficient querying by location through a RESTful API.

The data pipeline begins with automated ingestion of weather data into a temporary S3 bucket, which triggers a processing Lambda function that converts the GRIB2 data into GeoTIFF format while reprojecting it to the WGS84 coordinate system. The processed data is stored in a PostgreSQL database enhanced with PostGIS extensions, enabling powerful geospatial queries and analysis. Docker is used extensively throughout the development and deployment lifecycle, ensuring consistent environments for both production and testing, and simplifying the management of dependencies and services such as GDAL and PostGIS.

The database is hosted within a private AWS VPC, ensuring data security while maintaining high availability. The system employs IAM authentication for database access and implements comprehensive security measures, including API key authentication, rate limiting, and CORS policies. Database schema changes are managed through Liquibase, providing version control and automated deployment capabilities. The platform exposes its functionality through a RESTful API built with API Gateway and Lambda functions, allowing clients to query weather data based on geographic coordinates and time ranges. The system includes automated maintenance tasks, data lifecycle management, and comprehensive monitoring through CloudWatch.

This architecture demonstrates a modern approach to handling geospatial data, combining cloud-native services, containerization with Docker, and specialized geospatial tools to create a robust, secure, and scalable weather data platform.

Spatial Weather

As we expanded Phone Link to support Microsoft Account sign-in and cross-device file sharing, I led the complete redesign of our Link to Windows AASA website to support both App Clips and iOS universal links. This work was foundational to evolving our onboarding flow from Bluetooth-only to a full-featured, account-enabled experience. In doing so, I pioneered two key UX solutions that navigated around restrictive and poorly documented iOS platform behaviors—solutions that are now gaining traction across the industry as best practices for building seamless iOS onboarding flows. First, I solved the long-standing iOS limitation of lacking native deferred deep linking, which Android supports out of the box. We needed a single QR code that could install the app and carry onboarding context into the first launch. Without a solution, users would have been forced to scan the same QR twice. I developed and productized a novel workaround: our website copies the original link into the iOS clipboard just before redirecting to the App Store. When the app is first launched, it checks the clipboard, asks for permission, and resumes onboarding exactly where the user left off. This clipboard-based deferred deep linking flow was both elegant and reliable, and became a core enabler of our frictionless setup experience. Second, I discovered and addressed a non-obvious iOS behavior: universal links don’t trigger app launches if they match the domain of the website the user is currently on. This broke deep linking from our AASA site for users who manually entered the URL. To resolve this, I introduced a second universal link domain and routed CTA clicks through it, preserving full context via query parameters. This allowed deep linking to work reliably across all user entry points, including App Clips, QR scans, browser links, and manual visits. These solutions not only resolved major platform constraints—they helped define new patterns for building premium onboarding experiences on iOS. By navigating undocumented edge cases and crafting highly maintainable, user-friendly architectures, I set a new standard for how large-scale iOS UX should be built. These flows became core to the success of our iOS offering and are now being looked at as models for other Microsoft and industry teams alike.

Universal Link Onboarding & Deep Linking – Inventing New Patterns for Seamless iOS UX

Partnered with the Windows Bluetooth team to implement the Bluetooth Hands-Free Profile (HFP) in the HF role, allowing Windows PCs to function as Bluetooth headsets for mobile phones. This work enabled users to make, receive, and control cellular calls directly from their desktop—marking a key first step in Microsoft’s now expansive cross-device strategy. I contributed to low-level API development and system integration to support real-time call controls, audio routing, and device state synchronization. This project laid the technical foundation for what would become a full suite of phone-to-PC continuity features across Windows and mobile platforms.

Windows Bluetooth HFP – Enabling Phone Calls from PC via Hands-Free Profile

Following the successful launch of our MAP and PBAP Bluetooth integrations, new regulatory requirements under the EU’s Digital Markets Act (DMA) created compliance risks for the broader Phone Link product. To align with DMA mandates without exposing the entire Phone Link stack to third-party extensibility, Microsoft reclassified Phone Link as a core Windows feature. This reclassification, however, created a conflict: our Bluetooth MAP and PBAP profile qualifications had been explicitly filed as non-Windows components. Without resolution, we faced potential noncompliance with either the DMA or the Bluetooth SIG—jeopardizing the licensing status of our critical iOS cross-device functionality. I led the coordination effort across multiple stakeholders—including the Windows Bluetooth team, Microsoft’s legal counsel, our product team, and the Bluetooth SIG. I drove the discussions that aligned legal interpretations, technical implementation details, and certification requirements. Ultimately, I led the successful reclassification of our profile qualifications in a way that preserved SIG compliance while satisfying DMA constraints. This work ensured uninterrupted licensing and feature delivery for millions of users in the EU and globally, protecting one of the most critical components of our iOS integration work.

SIG Compliance

Share files instantly with secure peer-to-peer connections. No uploads, no storage, just direct file sharing between devices. Fast, private, and easy.

Pourtle | Instantly share files, photos, and more

Pourtle is a real-time content-sharing web app that enables instant, bidirectional transfer of files, photos, videos, and notes between two devices—most commonly from phone to computer—using a secure WebRTC connection. I built the full stack from the ground up. The backend consists of a Python-based AWS Lambda microservice using WebSockets to facilitate WebRTC signaling between clients. Connections are initiated by scanning a QR code or entering a short pairing code, similar to smart TV app auth. Once connected, data is transferred directly between peers—no centralized storage involved. The frontend, built in React with Material UI, delivers a seamless and responsive UX optimized for both mobile and desktop users. The app is fully cloud-hosted via AWS S3 + CloudFront, with infrastructure defined in CloudFormation. Continuous integration and deployment are handled through GitHub Actions, automatically deploying the site and backend on PR merges and content updates. This project highlights deep expertise across real-time networking, full-stack development, cloud infrastructure, and DevOps—demonstrating end-to-end technical ownership and production-grade engineering.

Pourtle

A technical breakdown of my website intertwined with lessons I've learned along the way

How I Built alexfischman.dev | Alex Fischman

My personal portfolio site, alexfischman.dev, is built with Next.js, combining client-side rendering and static generation for a fast, responsive experience. It uses Material UI for styling and a markdown-based personal blog. The site is hosted using AWS S3 + CloudFront for global delivery, with infrastructure defined via CloudFormation. CI/CD is fully automated through GitHub Actions, which triggers deployments on both pull request merges and new blog post commits—ensuring the site stays up to date with zero manual effort. This project showcases not only my front-end development skills but also my ownership of cloud infrastructure and DevOps practices, making it a robust and scalable hub for my engineering work and writing.

alexfischman.dev

I was selected by the newly formed Microsoft Phone Link team (known as Your Phone at the time) to lead the calling development effort in the new Windows app. This work was building on the Windows OS work I had led to enable calling functionality via Bluetooth (HFP) on desktop. I partnered with PM/Design to build a calling experience from scratch in the Phone Link app. This included an onboarding experience for a user to Bluetooth pair their Windows PC with their mobile phone and once onboarded, dial phone calls, answer phone calls, and interact with phone calls. Additionally, we added support for contact syncing and call history in Phone Link.

Phone Link Calling – Launched Bluetooth Calling from PC to Millions of Users

Served as the lead engineer responsible for bringing our product into compliance with the EU’s newly introduced Age Appropriate Design Code (AADC)—a regulation prohibiting most forms of data collection from users under a certain age. The project was high urgency, with significant legal and financial implications for non-compliance. I implemented age detection logic and built conditional UX flows that dynamically adjusted the interface based on user age group—proactively hiding or disabling features that involved data sharing or personalization. In parallel, I led a comprehensive refactor of our telemetry systems across both Windows and Android codebases to ensure no data was collected for users flagged as underage. This work was delivered on an accelerated timeline to meet legal deadlines, and successfully safeguarded Microsoft from noncompliance penalties while reinforcing our commitment to responsible data handling and child safety.

AADC Compliance – Protecting Young Users in Line with EU Privacy Law

As the primary engineer for call control UX, I led the design and development of modern calling interfaces across both experimental and mainstream Windows devices. This included building a fully functional telephony experience for Andromeda, Microsoft’s tented dual-screen device, where I implemented core controls like mute, hold, DTMF, and hang-up—all tailored for a flexible dual-display form factor. In parallel, I architected and delivered the new calling UI for Windows desktop—bringing a polished, standards-compliant phone call experience to the Windows PC platform. This work required close collaboration with PM and Design to ensure consistency with Windows UX guidelines and accessibility expectations, especially given the scale of the desktop user base. Together, these efforts pushed forward the Phone Link platform’s vision of seamless, native call integration across form factors—laying the groundwork for future extensibility and cross-device continuity.

Cross-Form Factor Call UI – Modern Telephony Experiences for Windows Devices

Redesigned the Windows Phone dialer experience by developing a fast and memory-efficient T9 contact search engine. I implemented a persistent Trie-based indexing system that dynamically reindexed contacts on add, remove, or update operations—delivering instant, accurate matches as users typed on the keypad. In parallel, I partnered closely with PM and Design to craft and implement the user experience for integrating smart search directly into the dialer UI. This feature shipped to all Windows Phone users and significantly improved contact accessibility from the native dialer.

Smart Dialer: T9 Contact Search for Windows Phone

As part of Microsoft’s strategic partnership with Samsung to preinstall our Link to Windows Android app on Galaxy devices, I served as the technical point of contact for multiple core Phone Link features—supporting ongoing integration, compliance, and quality assurance efforts across the partnership. A key requirement was passing Samsung’s biannual QA certification cycle ahead of major device or OS launches. I was directly responsible for diagnosing and resolving issues surfaced by Samsung’s QA team—often under tight timelines—to ensure our features remained fully functional and certifiable. This work was mission-critical to maintaining preinstall status and ensuring continued product availability on flagship Samsung devices. Beyond unblocking product delivery, the role offered invaluable cross-geo collaboration experience. I worked closely with Samsung engineers in South Korea to align on feature readiness, edge case behavior, and cross-platform integration, contributing directly to the success of one of Microsoft’s highest-profile mobile partnerships.

Samsung Partnership Engineering – Cross-Geo QA & Feature Ownership for Galaxy Devices

Led the accessibility overhaul of the Windows Phone Dialer app to ensure inclusive use for users with visual and motor impairments. This included implementing visual accessibility features such as high contrast mode and text zoom, as well as integrating auditory support via screen reader (Narrator) compatibility—enabling full voice-based navigation through the dialer interface. The project required tight collaboration with accessibility guidelines and OS-level APIs to deliver a fully navigable and compliant experience for all users.

Accessible Dialer: Voice & Visual Accessibility for Windows Phone

Engineered and integrated support for metered networks within Windows networking settings—enabling the OS and applications to detect cost-sensitive networks like cellular and automatically enter a low-data mode. This system-level feature ensured that apps behaved responsibly on metered connections, helping users avoid unexpected data charges and improving overall control over bandwidth usage. The implementation required close integration with the Windows networking stack and alignment with platform-wide data usage policies.

Metered Network Mode – Data Cost Awareness in Windows Networking

Handpicked as the engineering lead for phone calling in Microsoft’s newly formed Phone Link team (then Your Phone), I architected and built the feature from the ground up—delivering full Bluetooth-based calling between Windows PCs and Android phones. This marked one of the first major capabilities in Microsoft’s cross-device initiative, and rapidly scaled to millions of users worldwide. Leveraging the Bluetooth HFP infrastructure I had previously implemented at the OS level, I created a fully native calling experience within the Phone Link app. I led development of the end-to-end stack, including device onboarding via Bluetooth pairing, real-time call controls (dial, answer, mute, hang up), contact sync, and call history. I also collaborated closely with PM and Design to define the user journey and ensure a polished, Windows-aligned UX. The feature was instrumental in establishing Phone Link as a flagship experience for Android + Windows integration, earning widespread media attention—including The Verge’s 2020 coverage and early previews. Today, it continues to serve as a foundational feature used by millions of users to stay connected across devices.

Cross device connectivity re-architecture

# <a href="https://pourtle.com" style="color:rgb(78, 158, 237);; font-weight: inherit; text-decoration: underline;">Pourtle</a>'s Backstory
\
This isn't a startup, but it was fun to give this project one of those startup-y names. Find a word that feels related to your product in some way, then mess with it a little bit to create a spelling that resembles that word. But it cannot be directly that word. Something something cool factor.

Spoiler, I thought of **portal** first as my relevant word. A few hours of creative brainstorming, ideation, and long discussion, and Pourtle was born. It's like it was meant to be.

Why is portal relevant though? What is this?

I consider myself technologically savvy. Growing up, my dad brought internet to our house in 1997. I've had Facebook since 2007. Smart phones since 2009 (shout out Palm Pre). Dropbox since 2010. And a software engineering - related degree since 2015. The diploma says Electrical Engineering but there was a lot of coding within that curriculum.

All that, and **I still struggle to move my digital content between my devices**. I can't tell you the amount of times I've sent myself a photo on Facebook Messenger to get a picture from my iPhone onto my PC. Or a blob of text that I needed to copy/paste. OR A URL! Just enthusiastically remembered that use case and it's a constant pain point. Facebook Messenger for whatever reason has been the lightest weight mechanism I use to do this which is now a habit.

This isn't unchartered territory though. Apple demonstrates masterclass in this problem space, as long as you use Apple products. A number of cloud services with names containing "Box" or "Drive" exist for this as well. My last project at Microsoft even aimed to solve this.

There's always a catch though. Some quid pro quo. Whether that's monetary, advertisement mind share, data collection, etc. You're valuable and companies take a little bit of your value in exchange for the value they provide. There's nothing wrong with that, it's the basis of business. But in my experience, that requirement has always surfaced through an elongated user experience to accomplish the goal of moving content.

_Sign-in's, downloads, installs, uploads, sign-ups, syncs, etc. etc._

There's also often the compromise of sharing your content with a company. Letting them see it, letting them process it, letting them store it. Privacy is front and center in a lot of ways at a lot of companies, but things can and do go wrong. Hackers are unfortunately good at their jobs and attacks or leaks make headlines every now and then.

Okay, enough spotlighting what is not the biggest problem the world is facing today. The existing solutions are good enough for most and I put up with them from time to time. Let me bookend this section.

I saw an opportunity for a fun project that adds regular and simple value to my life. I have a lot of devices and a lot of content across those devices. And I fairly often need to move my content between my devices. So I built myself (and any of you that want to try it) a connection between my devices to move my content.

Like a portal. Sorry, pourtle **.
 
 

# Overview
\
**30 second elevator pitch! Read quick!**

Need to move a photo, file, link, or more between your phone and computer?

1. Go to [pourtle.com](https://pourtle.com) on your computer
2. Click Get Started and scan the QR code with your phone's camera
3. Your phone and computer are connected! Share whatever between the two devices

No accounts, no uploads, no storing your content somewhere in the cloud. Just a direct connection between your devices to move your content. When you're done, just close out of it and know all your content remains only on your devices.

![Screenshot of Pourtle user experience](/blog/2025-07-23-introducing-pourtle/ux.png)
<figcaption style="text-align: center; font-size: 0.98em; color: #aaa; margin-top: 0.5em;">
 Pourtle user experience as seen on both computer and phone
</figcaption>
 
 

# Technically Speaking
\
One of my favorite things about software engineering is the ability to imagine something, and then just build it. It can sometimes feel like creating art out of logic, and more often than not the only resource required is time.

The more you do this though, the more you realize how frameworks can expedite that process and hone in your thinking to a high-quality solution. I lean into that here.

## First Principles

I approached this space from first principles.

**Problem**: Your content may exist on one device when you have a one-off need for it on a different device.

**Conventional thinking**: Cloud-based, account-based, or closed-ecosystem solutions are standard

### Step 1: Question the Assumptions

1. **Why are cloud solutions popular?** For repeated access on multiple devices
2. **Why are accounts required?** For cloud access and/or business value 
3. **What is the minimum technical solution that could solve this?** A direct data connection between two devices

### Step 2: Break Down the Requirements

* **One-time transfer** – No need for repeated access or persistent storage
* **Cross-platform** – Must work across all platforms and devices (with internet)
* **No friction** – No downloads, no sign-ups, no learning curve
* **Privacy** – Content shouldn't leave a user's devices

### Step 3: Explore the Technical Landscape

Browsers are one of the common denominators across all personal computing devices with internet access and are user expectation. This spans phones, tablets, and PCs, which are also the surfaces most often used to interact with your content.

Examining browser technologies and what could be leveraged, the industry-standard **WebRTC** peer-to-peer protocol appeared as the perfect candidate for a real time, secure data connections directly between devices.

It's not an out of the box solution though, rather an interface of common functionality that (essentially) all browsers implement and make available to applications for consumption. The application layer atop it has a few responsibilities:
- **Signaling** – Coordinate the initial handshake between peers (offer/answer exchange)
- **Connection management** – Handle ICE candidate exchange and connection state
- **Data channel setup** – Establish the bidirectional data pipe for file transfer
- **File chunking** – Break large files into manageable pieces for reliable transfer
- **Error handling** – Gracefully manage network issues and connection drops
- **Session management** – Generate unique session codes and validate peer connections

Those application requirements felt achievable and equally a fun learning challenge for me. I had not previously worked with WebRTC but came away eager to get my hands dirty. Onwards.

### Step 4: Define the Solution

With the work cut out for me above, I dove into defining how this will actually look in code.

#### The Web App

The overarching solution is comprised within web technology to leverage the browser's WebRTC functionality, and served as a web app from the domain pourtle.com. While multiple web frameworks and hosting solutions could've been chosen, I sided with a stack familiar to me:
- **React**: open-source front-end JavaScript library optimized for user interfaces
- **JavaScript**: the programming language used with React (note TypeScript could have also been used)
- **Material UI**: React component library implementing Google's Material Design Language
- **AWS S3/CloudFront**: Static web hosting with a global CDN to distribute

Contained within this web application are my WebRTC implementations for the user experience, connection management, setup, file chunking, and error handling. Sparing the nitty gritty details, some clean layering is in place to provide the UI layer with a simple messaging abstraction to send and receive a file, photo, or text. 

#### Backend Service

The most ambiguous piece which I'd like to focus on entails building the signaling channel paired with the session management. The WebRTC protocol entails an initial handshaking sequence that is established on an external transport (as the WebRTC connection doesn't exist yet).

First, let's establish roles. Every Pourtle session consists of two devices. One acting as a **creator** (starts the session, gets a 6-digit code) and one acting as a **joiner** (enters that code).

##### The Flow

1. **Creator** device visits pourtle.com → backend generates unique session code → code displays on screen
2. **Joiner** device scans/enters code on pourtle.com → backend matches with creator device → both devices know they found each other
3. **Handshake begins** → devices exchange WebRTC setup messages _through_ my backend
4. **WebRTC connects** → backend steps aside, devices talk directly

##### The Architecture

Admittedly I'm cheap when it comes to projects like these. Why pay Amazon for a server to run 24/7 that I use <10 times per month when I could instead pay them for Prime and HBO Max (with ads)? **AWS Lambda + API Gateway WebSockets** means I only pay when someone's actually connecting devices. Widely known as a serverless architecture.

There's a stateful piece to this too. This state lives in **DynamoDB**:
- Creator starts session → store `{sessionCode: "123456", creatorId: "abc"}` 
- Joiner enters code → update to `{sessionCode: "123456", creatorId: "abc", joinerId: "xyz"}`
- Now when "abc" sends a message, the backend can relay it to "xyz".

This relay messaging allows them to exchange WebRTC handshake info, and upon completion the backend becomes irrelevant. Direct peer-to-peer connection takes over. **Aka WebRTC!**

I'm a visual learner, in case you are too:


```mermaid
sequenceDiagram
 participant A as Device A (Creator)
 participant WS as Lambda + API Gateway + WebSocket
 participant DB as DynamoDB
 participant B as Device B (Joiner)

 Note over A,B: Initial Session Setup
 A->>WS: init (no code)
 WS->>DB: PUT SessionCode + ConnectionId[A]
 WS-->>A: 6-digit session code
 
 Note over A: User shares code with Device B
 
 B->>WS: init (sessionCode)
 WS->>DB: UPDATE ConnectionIds += [B]
 WS-->>B: "joined session"
 
 Note over A,B: Peer Readiness Signaling
 A->>WS: signal {type: "ready"}
 WS-->>B: relay ready signal
 B->>WS: signal {type: "ready"} 
 WS-->>A: relay ready signal
 
 Note over A,B: WebRTC Handshake (SDP Exchange)
 A->>A: Create RTCPeerConnection + DataChannel
 A->>A: Generate SDP offer
 A->>WS: signal {type: "offer", sdp: offer}
 WS-->>B: relay offer
 
 B->>B: Create RTCPeerConnection
 B->>B: Set remote description (offer)
 B->>B: Generate SDP answer
 B->>WS: signal {type: "answer", sdp: answer}
 WS-->>A: relay answer
 A->>A: Set remote description (answer)
 
 Note over A,B: ICE Candidate Exchange
 A->>WS: signal {type: "ice", candidate: candidate1}
 WS-->>B: relay ICE candidate
 B->>WS: signal {type: "ice", candidate: candidate2}
 WS-->>A: relay ICE candidate
 
 Note over A,B: Direct P2P Connection Established
 A->>B: RTCDataChannel open
 B->>A: RTCDataChannel open (bidirectional)
 A->>WS: Close WebSocket (optional cleanup)
 B->>WS: Close WebSocket (optional cleanup)
 
 Note over A,B: File Transfer (P2P Only)
 A->>B: File chunks over DataChannel
 B-->>A: Progress acknowledgments
```
 
 

#### Conscious Design Decisions

I am intentionally omitting the use of a [TURN server](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) at this point. 

This equates to **devices must be on the same network to share content**.

My reasoning for this choice:
1. **Cost**: a TURN server would add compute cost and while valuable, again I'm already paying for HBO Max (with ads).
2. **Use cases**: a user's devices (particularly mine) are very frequently on the same network, where there is no need for a TURN server in the first place
3. **Privacy**: Content is more secure given it is not traversing across networks.
4. **Complexity**: [K.I.S.S.](https://en.wikipedia.org/wiki/KISS_principle), no pressing need

This is not an irreversible decision. A TURN server could be added in some day if it made sense.

### Step 5: Write the code
![Screenshot of Pourtle coding session](/blog/2025-07-23-introducing-pourtle/coding.png)

Feel free to check it out! [Repo](https://github.com/afisch710/quick-relay)

## I Love Feedback

Thanks for taking the time to read this post and hopefully you had a chance to play around with [pourtle.com](https://pourtle.com). If you notice any issues, have any feedback, or just want to have a conversation, you can absolutely reach out to me at any of the social links below.
 
 
Cheers!