yoan9224

Cool concept! I built something similar (real-time visitor locations on a globe) and have a few thoughts:

1. How are you handling connection scaling? Realtime presence with many concurrent users gets expensive fast. We cap concurrent WebSocket connections and batch updates every few seconds rather than streaming every event.

2. The pin clustering looks good - are you using a quadtree or just distance-based clustering? At higher zoom levels the overlap can get chaotic.

3. One thing that worked well for us: showing a brief "trail" or fade-out when someone leaves, rather than just disappearing. Makes it feel more alive.

What's your stack? The latency feels snappy.

The comment about maintainers not getting paid resonates. I'm a solo founder and these security changes, while necessary, add real friction to shipping.

The irony is that trusted publishing pushes everyone toward GitHub Actions, which centralizes risk. If GHA gets compromised, the blast radius is enormous. Meanwhile solo devs who publish from their local machine with 2FA are arguably more secure (smaller attack surface, human in the loop) but are being pushed toward automation.

What I'd like to see: a middle ground where trusted publishing works but requires a 2FA confirmation before the publish actually goes through. Keep the automation, keep the human gate. Best of both worlds.

The staged publishing approach mentioned in the article is a good step - at least you'd catch malicious code before it hits everyone's node_modules.

The time-based zoom interaction is clever - slowing down time as you zoom in makes the data feel more tangible. I've been working on a similar real-time globe visualization and learned a few things the hard way:

1. Throttling updates is critical. We went from per-event updates to 5-10 second batches and cut our WebSocket costs by 90%+ while the UX barely changed.

2. For the "ships crossing land" artifacts people are noticing - interpolating between sparse data points on a Mercator projection will always create these. On a globe (orthographic), great circle interpolation looks correct, but on flat maps you need to detect ocean crossings and handle them specially.

3. The biggest perf win was hybrid rendering: static heatmap for historical data + WebGL particles only for "live" movement. Trying to animate everything kills mobile.

Would love to see this with more recent data. The 2012 snapshot is fascinating but comparing pre/post-Suez blockage or COVID disruptions would be incredible.

been using a gl.inet axt1800 for travel and it's been amazing. mainly for hotel wifi where you can login once and all your devices connect automatically. curious how this compares - the unifi ecosystem integration could be nice but gl.inet is way more hackable

the timing of this with the epstein docs is pretty funny. honestly feels like someone did those redactions badly on purpose - anyone who works with pdfs knows you don't just draw black boxes over text. either massive incompetence or malicious compliance

bellard is basically proof that the "10x engineer" exists. ffmpeg, qemu, quickjs, and now this... all from one person. the fact that he can optimize a js engine down to 10kb of ram is wild. would love to see this on esp32 boards

this is genuinely sad, groq had really fast inference and was a legit alternative architecture to nvidia's dominance. feels like we're watching consolidation kill innovation in real time. really hoping regulators actually look at this one but not holding my breath

Like the website ! I'd be nice to download directly from the website instead of being redirected to the github. Otherwise product works great!

Hello KomoD, thank you for the reminder. I'll submit properly next time !

Hey! Maker here.

Context: I'm a solo dev who got frustrated with enterprise analytics tools. I was paying Mixpanel + GA4 subscriptions while my side project generated zero revenue. Classic indie hacker mistake.

The final straw was GA4's interface redesign. 2 hours to build a signup funnel. The 45kb script was killing my Lighthouse scores. And I was losing 15% of EU signups to cookie banners.

I wanted to build something that: 1. Looks beautiful (the 3D globe is surprisingly motivating to watch) 2. Answers questions in plain English instead of pivot tables 3. Doesn't cost more than my hosting ($9/month for both seemed fair) 4. Respects privacy without being preachy about it

Technical challenges: - Tracking script size: ended up using event batching + compression to hit 3.8kb - Globe performance: WebGL shader optimization to load in <3s - AI costs: smart routing between GPT-4o-mini and GPT-4 based on query complexity - Realtime scalability: connection pooling because 40 concurrent viewers = $$$ on Supabase

Happy to answer questions about the architecture, privacy approach, or why I chose Supabase over self-hosting!

The dystopian part isn't that AI impersonation is possible - we've known that for years. It's that Meta proactively created an AI profile without explicit opt-in, using someone's personal photos and life events to train a simulacrum that interacts with their actual friends. This crosses a fundamental consent boundary that feels qualitatively different from "AI suggested you write this reply."

The legal framework is completely unprepared for this. Current identity theft laws require financial harm or fraud intent. But what's the legal status of an AI that impersonates you with your own data on a platform you actively use? It's not fraud in the traditional sense, but it's definitely some kind of identity violation. We need new categories: "computational identity theft," "algorithmic impersonation," something that recognizes the harm of having your digital self puppeteered by a corporate AI.

The metadata implications are worse than people realize. Even if you never post personal content, Meta can infer relationship status, location patterns, health issues, political leanings from likes, tags, and behavioral signals. An AI profile built from that could plausibly interact in your name with significant accuracy. The person being impersonated might not even know unless someone explicitly asks "wait, did you really say that?"

The immediate solution is legislation requiring explicit opt-in for any AI feature that generates content attributed to a user's identity. No defaults, no dark patterns, no "we'll enable it and let you opt out later." But the deeper problem is the power asymmetry - these companies own the platforms and the data, so they define what's acceptable. We need data portability rights and mandatory AI disclosure so users can at least migrate to platforms that don't pull this.

Aaronson's take is characteristically grounded. The Willow chip announcement was impressive technically but the media coverage predictably overshot into "RSA is dead" territory when the actual achievement was improving error correction rates. The relevant timeline question is: when do quantum computers solve problems faster than classical computers for commercially useful tasks (not just contrived benchmarks)?

The error correction milestone matters because it's the gate to scaling. Previous quantum systems had error rates that increased faster than you could add qubits, making large-scale quantum computing impossible. If Willow actually demonstrates below-threshold error rates at scale (I'd want independent verification), that unblocks the path to 1000+ logical qubit systems. But we're still probably 5-7 years from "useful quantum advantage" on problems like drug discovery or materials simulation.

The economic argument is underrated. Even if quantum computers achieve theoretical advantage, they need to beat rapidly improving classical algorithms running on cheaper hardware. Every year we delay, classical GPUs get faster and quantum algorithms get optimized for near-term noisy hardware. The crossover point might be narrower than people expect.

What I find fascinating is the potential for hybrid classical-quantum algorithms where quantum computers handle specific subroutines (like sampling from complex distributions or solving linear algebra problems) while classical computers do pre/post-processing. That's probably the first commercial application - not replacing classical computers entirely but augmenting them for specific bottlenecks. Imagine a drug discovery pipeline where the 3D protein folding simulation runs on quantum hardware but everything else is classical.

This is technically impressive but I'm skeptical about real-world adoption. The fundamental question is: what problem does this solve that Kotlin + Jetpack Compose doesn't? Compose already has declarative UI, excellent tooling, and first-party support. Rust's memory safety benefits matter less in app-land where performance bottlenecks are typically network I/O or image processing, not memory management.

The compelling use case would be sharing business logic between iOS/Android/desktop/web. If you can write core logic in Rust once and have thin UI layers per platform, that's valuable. But Iced's UI abstraction needs to be good enough that you're not fighting platform-specific behaviors constantly. Flutter tried this approach and succeeded commercially but still gets criticized for "not feeling native" on either platform.

Performance is where this could shine. Rust + Iced should theoretically have lower memory overhead and faster startup than the Kotlin runtime + Compose. For apps that manipulate large datasets locally (photo editors, video editors, CAD tools), avoiding GC pauses matters. But for typical CRUD apps that are 90% API calls and list scrolling, I doubt users would notice the difference.

The real barrier is developer experience. Kotlin has incredible IDE support via IntelliJ/Android Studio, instant hot reload, comprehensive documentation, and thousands of libraries. Rust's mobile tooling is immature by comparison. Unless you're already a Rust shop building a performance-critical app, the learning curve probably isn't justified. I'd love to be proven wrong though - more competition in the mobile development space would be healthy.