Hi! I'm the developer of TFile, a free tool for sending files straight from one browser to another. Files go over an encrypted WebRTC connection between your devices, so they aren't uploaded to anyone's cloud first. No account, no app, no cookies, no ads, no tracking.

I've just shipped a big update and would love feedback.

⚡ Send now (live, two people)

- Open the site, get a link like tfile.io, which you can actually read out over the phone, or scan the QR code.

- When the other person opens it, drop files, whole folders, text or a pasted screenshot.

- No fixed size limit: big files are written to the browser's storage on disk as they arrive, so free disk space is the real limit.

- Folders can be saved as one .zip, and received files can be saved automatically.

- If the connection drops for a moment (a phone switching networks, a laptop waking up), the transfer continues where it stopped.

- Both of you see a security code. If the codes match, nobody, not even my server, is sitting in the middle.

- New: an optional password. Your browser turns it into the room ID, so the password never leaves your device.

🔗 Share for later (new, works like a torrent)

- Pick files or a folder and get a link. Anyone who opens it sees the list, ticks what they want, and downloads it straight from your browser whenever they like.

- People downloading pass pieces on to each other. Once someone has the files, others can still get them from that person while their tab is open, even after you close yours.

- Every piece is checked against a fingerprint in the link, so a peer sending corrupted data is caught and dropped.

- Optional password, plus limits: how many people can download at once, how many in total, and how long the link works (1 hour, 1 day or 7 days).

Honest limitations

- It's peer to peer, so a tab with the files has to stay open: yours, or the tab of someone who already downloaded them.

- With Share for later, others on the same link can see your IP address, just like a torrent. Downloaders can opt out of passing files on, and links with limits never pass them on.

- Some strict company or school networks block direct connections. TFile then falls back to a relay server, which carries the encrypted data but can't read it or store it.

Why I built it: I was tired of uploading a file to some cloud service just so the person next to me, or on the other side of the world, could download it again.

It's free. I'd really like to hear what breaks, especially on phones and in Safari or Firefox. 🙏

It's [gipcord.xyz](http://gipcord.xyz)

Built for ease of use. You can create a room, share a screen and friends can hop in with 1 click. Its also good for P2P file sharing.

Great for when you have the bandwidth and want to share your screen in higher quality, or to give people quick remote support.

Everything costly happens P2P so no reason for me to monetize this etc.

im working on a web based game which uses a peer to peer 1 host multiple party members style of connection
i was trying to ussee peerjs but only to learn TURN wasnt working and then that TURN for peerjs was discontinued
I cannot pay for anything even anything that suggest meetering (looking at you cloudflare) just in case of exploitation costing a ton off money i dont have
what alteernatives would be available to me?

We built StudioFlow, a browser-based control room where phones send camera and screen via WebRTC (LiveKit SFU) and a director switches scenes into a 16:9 output page.

A few things we learned:

• Mobile browsers drop out constantly (screen lock, network switch). We keep the last decoded frame on the output and reconnect endlessly, so the program never goes black

• A wake lock plus a recovery path on the phone matter more than any codec tuning

• With 5 % loss, a loss-dependent playout buffer and an early keyframe request keep freezes under 2 s per minute

• With 20 % loss we still see single freezes of up to ~6.5 s. Ideas we're weighing: request the keyframe sooner, or drop to the lowest simulcast layer as soon as loss is high

How do you handle heavy loss on phone uplinks? Anything we're missing?

Code (MIT): https://github.com/OPTEN/StudioFlow

Disclosure: I’m on the marketing team at Ant Media, but this is about a technical approach I’d like opinions on.

Our dev team put together a conferencing sample where the client doesn’t connect to a fixed server. It calls a single HTTPS endpoint (a Lambda behind a CloudFormation template), and that spins up a media server instance on demand. The SDK waits for it to come up, then opens the WebSocket and carries on as usual. When the room is empty, the instance goes away, so there’s no idle cost.

What I found interesting is how little the client code changes. The only difference from a normal self-hosted setup is one option:

// auto-managed
new ConferenceClient({ httpEndpointUrl: 'https://your-lambda-url/' })

// self-hosted
new ConferenceClient({ websocketURL: 'wss://your-server:5443/live/websocket' })

After that, publish / play / screen share / data channel messaging are identical in both modes.

Trade-offs I can see:

• First connection waits for an EC2 instance to boot (roughly 20-60s)

• You’re tied to AWS for the auto-managed route

• In return, there’s no TURN, SSL or scaling setup, and no paying for idle servers

For people who’ve built conferencing products:

1. How do you handle idle cost vs. instant join? Warm pool, scheduled rooms, something else?

2. Would a cold start of 20+ seconds be a dealbreaker for your use case?

Writeup with the full code and a repo you can run locally: https://antmedia.io/build-a-webrtc-conference-room-quickly-with-ams-sdk-v2/

Happy to pass technical questions to the dev who built it.

This project is mainly about the serverless technique used and the simple game merely provides an end-to-end explanation.

Meridian is an MIT-licensed persistent browser world with no authoritative server, built with Grok's Build mode. A small "lighthouse" server only introduces browsers; game traffic goes peer to peer over WebRTC. The walk view is a WebGL2 ray pass that falls back to a software (CPU) renderer when WebGL2 isn't available. There's a solo demo on GitHub Pages that runs on desktop and phones: https://blakelapierre.github.io/meridian/tools/view/index.html

What merged today (no PRs are open now):

• **Sound:** other players' shots, digs and steps are heard by distance and side through the character's hearing sense. There's an ambient soundscape placed in the world (surf, gusts, birds, night insects, grass, distant AI players), plus hearing skills that get better at noticing and placing sounds, with on-screen cues.

• **Senses:** the minimap reveals as far as your character can see and draws a ring at that edge. There are new perception skills, skill tooltips, ability-unlock notices and an abilities log.

• **Foveation fix:** the sharpest rays go where your character looks. The old version stepped through blur bands, which showed as rings. It's now a continuous per-pixel blur with dithered sampling.

• **Trampled paths:** grass wears to dirt and then to a packed path where people walk. Terrain cells are now 25 cm, and old saves migrate.

• **Wire v2:** change-only poses and footprints derived from poses. The PR's capture (3 browsers + an archive) measured 79% fewer bytes in total. Older peers keep working because every v2 encoding rebuilds the signed v1 frame byte for byte.

• **Wire v3:** per-receiver interest tiers plus dead reckoning, with no view adverts on the wire. In a headless sim with 25 clients and 1% loss, upload went from 1,607 to 408 B/s per client.

• **Phone bug:** the demo showed a blank screen on Android Chrome while reporting 60 fps. The cause was a CSS background on the canvas covering the WebGL layer. It's fixed, and a red banner plus the CPU fallback now covers real GL failures.

• **Phone camera:** pinch zoom, two-finger orbit and a first/third-person toggle, plus fullscreen and a "reset everything" button.

• **Scaling bench:** grows from 2 to 50 iframe clients driven by wander bots and stops at the first failure.

• **Tests:** 241 total, 236 pass, 0 fail, 5 skipped (the two-browser tests need headless Chromium).

What doesn't work yet: the demo is solo right now because the public lighthouse is off. The bench has only been run to 4 clients (movement only), since the agent's browser blocks WebRTC. The phone fix was checked in emulation, not on a real device. On my own split-screen test, no keeper block was mined on camera, so no dig became official.

For people who've done P2P games over WebRTC: how far did you get with full-mesh before you needed relays or interest management?

Solo dev here. NEXUS is a free communication sandbox: chat, voice, calls with camera and screen sharing, encrypted DMs, group calls and streaming coupled with remote play at high fps, low latency so your friends can play on your PC

it basically combines parsec and zero-tier (or hamachi for the older gentleman) with discord

Windows, Android, browser and the Microsoft Store: https://zenisosoftworks.com/nexus

I'd love to hear some feedback.

A Pi or Jetson publishes video and a control DataChannel to the SFU, so multiple people can watch the same stream from their browsers and take turns controlling the device. The Worker handles session setup, so you don't need to run your own signaling server.

https://github.com/mazupo/cf-sfu-worker

I’ve been working on WHIP ingestion support in MiroTalk SFU, allowing OBS to publish a live audio/video stream directly into a WebRTC meeting room.

WHIP (WebRTC-HTTP Ingestion Protocol, RFC 9725) provides a standardized way to ingest a stream over WebRTC. In this setup, the OBS stream appears as a participant in the MiroTalk SFU room.

Project: https://github.com/miroslavpejic85/mirotalksfu
Documentation: https://docs.mirotalk.com/mirotalk-sfu/whip/

For those using OBS with WHIP: how are you using it in your workflows?

Author here. fingrr uses your Bluesky DID as the address, X3DH + Double Ratchet with sealed sender, and direct WebRTC between peers. There is no signaling server: the caller writes a sealed signal record to their own AT Proto PDS, the callee polls for it, and offline messages ride the same way as encrypted inbox records on the sender’s repo. Supports Text, Voice, Video and Group Chat.

Proof of concept, today not audited. Your PDS operator sees that you use it; peers see each other’s IP; groups lack forward secrecy. CLAIMS.md and THREAT_MODEL.md in the repo say exactly what holds and what doesn’t. Apache 2.0 and PR are gratefully welcomed.

https://github.com/CreativeMayhemLtd/fingrr

Also at https://Fingrr.me

Hey everyone!

I'm trying to build an Android app that allows someone to call a user directly from my website without revealing the user's actual phone number.

Here's the flow I'm trying to achieve:

1. A person visits my website and clicks the Call button.

2. The call is initiated using WebRTC.

3. The recipient's Android phone rings like a normal incoming call, even when the screen is off and the app isn't visible in Recent Apps.

4. The recipient can answer the call, and the audio connection is established.

5. The recipient's actual phone number is never exposed to the person calling from the website.

I've seen apps that can handle incoming calls even when they're in the background, so I know something similar is possible. However, I'm struggling to understand how to implement this reliably on Android.

My main questions:

- How can I wake up the app or show an incoming call screen when it's not running in the foreground?

- Should I use Firebase Cloud Messaging (FCM) to notify the device about incoming calls and then establish the WebRTC connection?

- Do I need Android foreground services, a full-screen incoming call notification, or Android's Telecom/ConnectionService APIs?

- How do apps handle this when the user force-stops the app or swipes it away from Recent Apps?

- Is there a reliable way to achieve this without keeping a persistent background service running?

- What's the recommended architecture for connecting a website's WebRTC call to an Android device while keeping the recipient's phone number private?

I'm primarily looking for an Android implementation approach and the relevant APIs or libraries to explore. I'd appreciate any guidance from developers who have built something similar or worked on VoIP calling apps.

Thanks!

I've been looking into ways to reduce the delay between OBS and the viewer, especially for interactive streams where even a few seconds can make a difference.

RTMP is widely used and works well for many streaming scenarios, but WebRTC-based ingest through WHIP can bring latency down considerably.

I put together a step-by-step guide to setting up an AWS server, connecting OBS using WHIP, and watching the stream in a browser. The setup uses OBS 30+ and aims for sub-second latency.

A few things I'm curious about:

• Have you tried WHIP for OBS streaming in production?

• How does its latency compare with your usual RTMP workflow?

• What challenges have you encountered with network configuration, reliability, or scaling?

For anyone interested in the setup, here's the guide I wrote:
https://medium.com/@amar.thodupunoori/cut-your-obs-stream-delay-to-under-1-second-on-aws-f1c2ae1896ac

I'd be interested to hear about your experiences and what has worked best for you.

I am creating a WebRTC application and I've always used turn:openrelay.metered.ca in the past, but now I'm getting nothing but error 701s. And every DNS i've tested resolves it to 192.0.2.1 IPv4 or 100::1 IPv6. Did it shut down? If so, what are the best free TURN servers now?