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.
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....
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.
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.
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.
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.
The real question for these third party services is whether each customer has a separate bank account. If there's one bank account per customer, and the third party service goes down, accessing the money probably isn't too bad. You can deal with the bank. They have regulators and obligations.
If it's one consolidated account, then it probably takes a bankruptcy court to untangle the mess.
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.
> 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.
Ugh. The bankruptcy court has to bring in forensic auditors, they try to reconstruct who owns what, and it takes a long time to sort things out. The bank's responsibility is only to have the total amount on deposit available to the bankruptcy court.
This is a really good argument for not using such a service.
The data breach did not cause the collapse of Synapse. Synapse has been a slow rolling collapse for the past 2ish years due to horrible management. Ultimately Synapse imploded when Mercury left Synapse as a BaaS provider to partner directly with Evolve BT. The Synapse collapse definitely put Evolve into the spotlight as someone with a ton of turmoil, lack of sufficient oversight and insufficient technological governance.
Evolve is an otherwise obscure bank chartered in Arkansas but headquartered in Tennessee (a little sketchy) that has over-leveraged itself. This is why it was hit with a Cease and Desist from the FDIC. The C&D also probably contributed to them becoming a target for LockBit.
Evolve is also the underlying bank for Stripe Treasury, although to my knowledge, their have been no new partnerships with them. I have heard the number 2 thrown around. Of note, Shopify is the main person for whom this was built and uses this.
Consequently if you have submitted KYC/KYB information for Shopify, Mercury, Yotta, Dave, any other past Synapse partners, or some Modern Treasury partners your data was breached. This seems to be the primary information shared along with account and routing numbers. This becomes problematic especially as part of the check involves external account and routing numbers along with SSN of any UBOs.
Fintechs do not partner with small banks because of debit card fees but because of Dodd Frank regulations (primarily).
Wow, Mercury’s account and routing numbers were all leaked, along with all KYC info? Is there a way to confirm that?
Their email made it sound much less serious.
(Apropos nothing, sorry about your motorcycle accident — I hope you’ve recovered well. Thank you for this comment; the severity of this breach wasn’t apparent till now.)
Is now afraid to get on my motorcycle today. If you linked an external account, then most likely. However, it is my understanding that Mercury had a very relaxed KYC and I would suppose their user are not impacted by external accounts. The more likely victim of external accounts are B2B participants of partners of Evolve. This would most likely be true for Shopify. FWIW, routing numbers are public.
Other data included in the hack is Evolve's emails in the form of outlook data files. Affirm is another definite impacted individual. VA loan data is probably also included in this hack.
