blakeburnette

TLDR; I basically wanted to create something that combines my virtual world efforts in Zwift with my real world efforts and both matter. Racing tying it all together. Creating the bike computer was delightful and easy. I am really confused by how hard the virtual world is to create, but then again GTA6 took like 42 years, so maybe I shouldn't be surprised.

Technicals:

Turning a noisy GPS trace into a "you rode this segment, in this direction, at this time" wass a real problem, so I used an HMM map-matcher — Newson-Krumm / Viterbi, the same family OSRM and Valhalla use. Candidate road edges are the hidden states, the emission probability is a Gaussian on how far each fix sits from an edge, and the transition probability punishes disagreement between along-road distance and straight-line distance. It's direction-aware (forward, reverse, and out-and-back all mint separately) and this was shockingly difficult to implement.

The thing that actually makes it fun is that the racing happens during the ride. When you hit a segment you're chasing, you get a live +/- against a ghost of the current holder. Originally this came in as a static ghost divided evenly by the total time, however, that is not accurate so now we use an actual reconstruction of their splits, so if they went out hot and you're clawing it back on the second half, you see exactly that, in real time. Instead of one all-time board that goes hopeless, crowns live on rolling windows (today / this week / this month / all-time), so there's almost always a bar that's genuinely in reach. That's a direct fix for the "my PR is unreachable on 19 of 20 rides" problem every mature Strava segment eventually has. And we added something called Keeps & Trials which, think Pokemon Gym, where time degrades over time on short circuits to allow you to race them over and over and over.

Map coverage is demand-driven. I was tempted to just map everything all at once, but I didn't want to just blow cash on hosting for the world when it isn't needed. So rather than pre-ingest everything, now when a rider shows up somewhere new, the area gets tiled with H3 hexes (Uber's hex grid, res 5, ~100 sq mi a cell) and only the uncovered hexes trigger a road-graph build from OSM/Overpass. The hex index is the dedup key, so the rule is literally "never ask the API for a place we already have," and the map fills in exactly where people ride and nowhere they don't.

Sensors are BLE GATT against the standard profiles — FTMS for smart trainers, Cycling Power (including pedal balance and the whole Zwift controller matrix: Click, Play, Ride, Sterzo), heart rate, speed/cadence. On the phone that's CoreBluetooth; on the desktop/world side there's a native Rust BLE stack so the same sim can run off a real trainer. Although, I don't own a power meter to validate that in the real world so if anyone wants to do that....

This is lovely.

Since this is still in development, it fluctuates slightly, but the floor is effectively

WASM - 374KB Raw || 148KB gzipped

JS and HTML - 31KB Raw || 8KB gzipped

Total - 404KB Raw || TLDR; 156KB for the end user

I appreciate all of your feedback so far. It is incredibly helpful. Everyone in this room is so much smarter than I am so thank you for helping point me in the right direction. And of course if anyone wants to contribute, I would love nothing more than that.

Mobile and scroll. Yeah. I have been struggling with these.

I need to add some love into those two areas for sure. As well as Safari and edge cases, etc. If anyone wants to contribute...

I totally get the benchmark is arbitrary for most usecases. I have gone back and forth on how to benchmark this, what's repeatable, what's fair, etc... What you see is largely me building something that lets me test performance, and rendering 10k rows with no virtualization is deliberately the dumbest possible case, it's a stress test, not a recommendation.

Largely the difference, as I am aware of those two options. They build on the traditional DOM. I took this approach, and as I was attempting to speed processes up I was consistently running into issues where I was beholden to C++ and Blink. The more I tried to beat Svelte, it seemed that I was hitting limitations with traditional web architectures, javascript and the DOM itself. They are fantastic options. I support writing Rust everywhere. But I was kind of over the many issues with JS (security, performance limitations, etc...). I had a vague curiosity about the ability to abandon the traditional DOM, thoughts on WASM and long story short I went for it. So what you are seeing is not a traditional DOM, inspect the demo page and compare it to the Svelte demo. I built my own DOM, but when you compile Nectar it automatically gets picked up as a traditional DOM by screen readers and SEO (this still needs some love). Initial loads, I am still really struggling with, but sorts and filters are quite performant.

Regarding FBOs, that is exactly what is happening with Synapse/Evolve. Customer funds and corporate funds were all comingled and reconciled across an inaccurate ledger held within an FBO. Whether the inaccuracies belong to the bank, or to Synapse is where the debate lies. What is also incredibly suspect in this case is that Mercury was able to transfer (IIRC) 49 million USD of money from Synapse's established FBO with Evolve to Evolve directly (under the ownership of Mercury). The ability for Mercury to have moved these funds is a massive red flag.

Regarding regulators and obligation -- in any of these relationships the bank is ultimately responsible/liable for any AML/TFL, money, etc... irregularities. A BaaS provider can effectively do everything wrong to the point its underlying bank is shut down, and switch to a different partner bank.

This gets into the nuances of fintech, BaaS and neo-banking. A consumer cannot reasonably be expected to understand these. The industry and regulators have effectively stated as such. Your money is, indeed, technically FDIC insured to 250k. It is not insured against the collapse of an intermediary party such as Mercury. FDIC insurance ONLY covers the collapse of a chartered US bank.

Mercury itself is not FDIC insured. If Mercury collapses, your money is not insured. If Evolve collapses, your money is insured. That's the official stance.

The majority of the banking industry is built on Cobol. Open Banking is the only real path forward. The issue of the US vs EU open-banking is the number of community banks.

The, unfortunate, most reliable banks from a technology/data perspective are ones that are large enough to be loathsome to deal with. Think JP Morgan, BoA.

Even banks of that size, Comerica, have had massive ledgering issues recently, so they are not immune.

Some reputable players in the BaaS industry are Unit, JP Morgan, Jack Henry, Moov(Massive plug for them), VGS (works with Visa and MC btw). If your neo-bank works with them, I would trust my money there. I do trust my money with one of those partners.