Hacker News, Distilled

Parallels to Current Drone/UFO “Lights in the Sky” Stories

• Many see the 1954 windshield pitting scare as analogous to current drone/UFO reports (especially New Jersey), where increased attention leads to a surge in sightings and interpretations.
• Commenters note people are now noticing planes, stars, Venus, satellites, and consumer drones they previously ignored, then labeling them as “mysterious drones.”
• Examples: a governor misidentifying stars as drones; local news mislabeling Venus; people flying their own drones to “hunt” other drones, further confusing the picture.

Mass Hysteria, Attention, and Collective Delusion

• The thread frames the 1954 event as a mix of:
  • Attentional/confirmation biases (you “can’t unsee” pitting once primed).
  • Frequency illusion (once primed, you suddenly “see it everywhere”).
• Debate on terminology:
  • Some prefer “collective delusion” or “mass hysteria.”
  • Others argue people were actually noticing real pits, but wrongly concluding they were new.
• Many historical analogues cited: Havana syndrome, killer clowns, Mad Gasser of Mattoon, Monkey-man of Delhi, Pennsylvania UFO–Bigfoot wave, dancing plagues, witch trials, Cold War scares.

Debate Over What’s Actually Flying Around Now

• One side: most recent “mystery” videos are explained by planes, helicopters, stars, satellites, flares, fireworks, consumer drones, camera artifacts. NYT analysis reportedly found no conclusive drone footage.
• Other side: insists there are genuine large, quiet drones/UAPs with unusual light patterns and behavior; some suggest military origin and say official non-denials support this.
• Strong pushback: humans can’t reliably judge distance, size, or speed of unknown lights at night; personal eyewitness certainty is not strong evidence.

Narratives, Conspiracies, and Human Psychology

• Several comments focus on:
  • How media, social networks, and partisan outlets direct attention and outrage.
  • “Low Information High Satisfaction” explanations (conspiracy-like stories that feel good with little evidence).
  • Humans as highly suggestible animals, prone to overconfidence, confirmation bias, and social proof—even among educated or “rational” people.
• Some find the takeaway “terrifying”: societies can rapidly self-organize around false or overblown beliefs with minimal triggers. Others see this as a stable, longstanding human trait to understand and manage, not panic over.

Clarifications on the 1954 Windshield Case

• Consensus: most pits were long‑existing wear and tear newly noticed after media coverage.
• The “epidemic” was less about new physical damage and more about a sudden, socially amplified shift in perception.

General reception & use cases

• Many Linux users report using Solaar for years without issues, often via distro repos or Flatpak.
• Common uses: pairing devices to Unifying/Bolt receivers, checking battery status, toggling Fn vs F1–F12 behavior, disabling tap-to-click, and adjusting MX-series features like scroll-wheel ratchet thresholds and gesture buttons.
• Some only use it occasionally (e.g., after battery changes or device moves) but consider it essential “quality of life” tooling.
• A few found the rule editor and gesture configuration confusing and gave up for simple remaps.

Comparison with Logitech’s official software

• Logitech’s Windows/macOS tools are widely criticized as bloated (hundreds of MB, Electron-based), resource-hungry, intrusive (auto-running agents, upgrade checkers), and phoning home; the “offline” corporate build is said to still contact Logitech.
• The addition of an “AI prompt builder” to the mouse driver is seen as emblematic bloat.
• Some praise Logitech’s features: per-application profiles, automatic profile switching, cross-computer mouse/keyboard and clipboard sharing, and lightweight Onboard Memory Manager for programming onboard profiles.
• Several users explicitly say they buy Logitech hardware because Solaar lets them avoid the official software on Linux.

Why a peripheral manager is needed

• Base HID drivers handle typing and pointing, but not:
  • Programmable buttons, macros, DPI/polling changes.
  • Scroll-wheel clutch/detent control and reassignment of wheel vs extra middle button.
  • RGB lighting control and persistence.
  • Per-device behavior (MX keyboards’ media vs F-keys, special laptop-like shortcuts).
• Some posters argue these are “niche” or goofy, others respond that such features are exactly why these premium devices sell.

Dongles, pairing, and connectivity

• Discussion of three receiver families: single-device dongles, Unifying (up to 6 devices), and newer Bolt (BLE-based, more secure).
• Bolt and Unifying are incompatible; users end up with multiple dongles for different Logitech lines (MX, Lightspeed, etc.).
• Solaar is valued for managing receiver pairing fully on Linux; Logitech also provides a web-based pairing tool.
• Connectivity tips: use Bolt instead of Bluetooth for reliability (though some report the opposite on Linux); avoid USB 3 ports or use short USB 2 extension cables to reduce 2.4 GHz interference.

Device quality and longevity

• Mixed reports on Logitech durability: some mice and keyboards working flawlessly for 10–14+ years; others see switches double-clicking in 2–3 years, especially on some gaming and budget models.
• Several users replace switches with higher-quality parts (TTC, Kailh, etc.), or choose brands that emphasize repairability.

Alternatives & broader ecosystem

• Other Linux tools mentioned: Piper/libratbagd, logiops/logid, input-remapper.
• On macOS, users recommend SteerMouse, BetterMouse, Mac Mouse Fix, and similar tools over Logitech’s own software.
• Thread situates Solaar within a growing Linux hardware-management ecosystem (e.g., CoolerControl, LACT, Boatswain).

Implementation details & portability

• Solaar is written in Python and is not a kernel driver; it talks to devices via HID++ over existing HID drivers.
• Some express desire for first-class Windows/macOS ports; there are experimental macOS attempts but nothing polished yet.

Nostalgia & Historical Parallels

• Many compare 1‑800‑ChatGPT to GOOG‑411, TellMe, ChaCha SMS search, and 90s-era phone-based or dot‑com services (e.g., “call the internet,” AOL keywords, novelty sites like zombo.com).
• Some note it “feels like” something early Google or Yahoo would have launched, with a playful, retro marketing vibe.

Intended Users, Accessibility & Use Cases

• Strong interest from people who want hands‑free access while driving, walking, cooking, or doing housework; phone calls integrate better with car systems and voice assistants than a dedicated app.
• Several mention this is ideal for people without smartphones, with only landlines, or in restricted environments (e.g., jail, flights with messaging-only Wi‑Fi).
• Debate over whether older (50+) users are a target: some assume they prefer phones; others push back, calling that stereotype wrong and noting many in that age group are highly tech‑literate.

Perceived Value vs. Gimmick

• Enthusiasts see this as:
  • A genuinely useful new channel (especially via WhatsApp/SMS).
  • A “killer feature” for hands‑free voice, and a low-friction trial for non‑users.
• Skeptics view it as:
  • A gimmicky wrapper over existing capabilities.
  • Evidence that model quality may be plateauing, with energy shifting to “bells and whistles.”

Model Quality, Hallucinations & UX

• Mixed reports: some get instant, correct answers; others see misrecognition (e.g., simple math questions via voice) and verbose “LLM yap” that feels more annoying when spoken.
• Confusion over model identity and knowledge cutoff: the FAQ says Oct 2023, but some sessions claim GPT‑4 with a Jan 2022 cutoff.
• Generally acknowledged that LLMs can hallucinate, especially on precise specs or recent media, though others argue their reliability has improved and is task‑dependent.

Data Collection, Privacy & Ethics

• Many assume this will generate large volumes of telephony-grade voice data, useful for training speech, customer support agents, and user-preference models.
• Some are uneasy about calls being recorded, caller ID handling (including blocked numbers still being recognized for rate limits), and whether disclaimers should be repeated every call.

Technical & Implementation Notes

• Built on Twilio SIP trunking with custom SIP servers for logic (usage limits, user-specific greetings) and internal access.
• Telephony constraints (8 kHz bandwidth, noisy environments) are discussed as challenges; users note background noise can still trigger misinterpretation.

Free Tier Details & Usage Limits

• New free GitHub Copilot tier in VS Code includes ~2,000 completions and 50 chat requests per month.
• Many full‑time developers consider this far too low (“a few days” or “one day” of use); hobbyists or occasional coders may find it sufficient.
• Several see it as “shareware” or a funnel to upsell Pro, not a truly free professional tool.
• Some developers plan to downgrade/cancel paid plans but keep using the free quota opportunistically.

Copilot vs Cursor, Windsurf, Codeium & Others

• Numerous users say they switched from Copilot to Cursor or Windsurf and find those significantly better, especially for:
  • Multi‑file edits and patch application.
  • Inline multi‑line edits and “edit around cursor” behavior.
  • Faster, more relevant autocomplete.
• Others argue Copilot Edits and chat+edits are improving and closing the gap but still feel clunky or unreliable for large refactors.
• Some feel Copilot remains “glorified autocomplete” compared to more agentic tools.
• A minority report opposite experiences: local tools or alternatives like Continue felt worse than Copilot for them.

IDE Ecosystem & Workflow

• Strong divide between:
  • VS Code / Cursor / Windsurf users, who praise rapid AI integration and multi‑file agents.
  • JetBrains users, who value superior navigation, refactoring, debugging, and tooling, and bolt on AI via Copilot, Cody, CodeGPT, etc.
• Several keep two tools open: one “real IDE” (JetBrains, Visual Studio) plus an AI‑centric editor (Cursor/Windsurf/Zed).
• Vim/Neovim users rely on plugins (copilot.vim, CopilotChat, Continue, CodeCompanion) but feel still behind Cursor‑style experiences.

Privacy, Training, and Licensing Concerns

• Many worry Copilot free tier is partly about harvesting more proprietary code for training.
• Settings default to allowing use of editor code snippets for “product improvements”; some are uneasy even with opt‑out, citing policy changes and vague language.
• Strong objections to:
  • Training on public code without explicit consent.
  • Terms that forbid using Copilot outputs to train competing AI systems.
• Some developers have left GitHub entirely or moved to “no AI” forges and self‑hosting.

Local & Open Models

• Active interest in local or BYO‑API setups: Continue + Ollama, Tabby, Cody+Ollama, Qwen2.5‑Coder, StarCoder, Llama, Gemma, etc.
• Debate over tradeoffs:
  • Local models: more control and privacy, but slower, require hardware, often weaker than state‑of‑the‑art cloud models.
  • Cloud SOTA (Claude, GPT‑4/4o, Sonnet): better quality and large‑scale edits, but proprietary and metered.

Impact on Work, Quality, and Jobs

• Some report huge productivity gains (rapid test generation, boilerplate, sweeping UI or config changes).
• Others find AI‑heavy codebases chaotic: inconsistent style, duplicated patterns, subtle bugs, and dependence on agents for any nontrivial change.
• Broader skepticism: AI may accelerate sloppier software, erode skills, displace workers, and concentrate power and knowledge inside a few vendors.

Market & Strategy Views

• Several see Microsoft’s move as classic “embrace, extend, extinguish”: bundling Copilot with GitHub/VS Code to starve startups.
• Others predict eventual price hikes once dominance is secured.
• Some believe AI tooling is overhyped, unprofitable at current costs, and may see a correction when returns and maintenance burdens become clearer.

Battery life, chemistry, and the “10‑year” claim

• Some argue “that’s not how batteries work” and expect real life closer to 2–3 years.
• Others cite Energizer Ultimate Lithium AA datasheets (≈25‑year shelf life, ~3,500 mAh) and low self‑discharge to say 10 years is plausible when replacing a ~200 mAh CR2032.
• Lithium primaries are highlighted as far more leak‑resistant than alkalines and widely used in “10‑year” smoke alarms.
• Concern: AA cells or contacts might age or leak before 10 years, especially if people ignore the “use lithium” guidance and install cheap alkalines.

Size, use cases, and UX trade‑offs

• Many find the enclosure too big for keys, wallets, pets; better suited to luggage, camera bags, tools, RVs, boats, storage units, etc.
• Some say annual CR2032 replacement is trivial, especially with Find My low‑battery alerts; others complain of “battery fatigue” when managing many tags and other sensors.
• A recurring theme: “set it and forget it” is valuable for rarely accessed or hard‑to‑reach locations (hidden in cars, trailers, cases, time capsules).

AirTag protocol longevity and Apple obsolescence

• Skeptics doubt AirTags and protocols will be fully supported in 10 years, citing Apple’s history of deprecating ports (FireWire, etc.).
• Others argue Apple tends to support accessories for a long time, that AirTags ride on the broader Find My ecosystem, and that cutting off v1 entirely would anger customers heavily invested in tags.

Theft tracking vs. loss prevention and stalking concerns

• Strong debate over whether AirTags are useful for anti‑theft:
  • Pro: Numerous anecdotes of recovering bikes, cars, luggage, and cameras by tracking tags, often involving police assistance. Hidden placements and disabling the speaker can make removal hard.
  • Con: Anti‑stalking features (iPhone/Android alerts, chirping) and ease of physical removal make them unreliable against determined thieves; they’re designed primarily for “lost,” not adversarial scenarios.
• Some worry longer life + waterproof, muffling enclosures could aid stalkers; others call this overblown given existing ways to hide tags and system‑level anti‑tracking alerts.

Reliability, software, and hardware aging

• A few question whether AirTag firmware or protocol assumptions (e.g., key rotation, watchdog behavior, memory leaks) were designed for 10× expected battery life; others note watchdogs and constrained RAM would expose most bugs well before a year.
• Disagreement over whether other components (sensors, capacitors) or software aging make 10‑year expectations unrealistic; some cite decades‑old electronics still working fine.

Alternatives, DIY, and adjacent products

• Multiple DIY suggestions: CR2032‑to‑AA adapters, 3D‑printed housings, OpenHaystack‑based NRF52 beacons with AA packs, and cheap Chinese enclosures.
• Comparisons to cellular/NB‑IoT asset trackers: more expensive and subscription‑based but better for theft, since they lack anti‑stalking constraints.
• Some prefer rechargeable or different form‑factor trackers (credit‑card shapes, bike‑integrated mounts) over a bulky AA pack.

Why Meta Migrated Java → Kotlin

• Many agree Meta can justify large one‑time investments for modest gains in safety/productivity at their scale.
• Kotlin is now the de facto Android language; staying on Java is seen as “legacy” and hurts hiring and developer satisfaction.
• Null‑safety in core frameworks is viewed as critical when 1B+ Android users are affected; even a rare NPE can cost millions.
• Several argue that partial migration (Java + Kotlin) leaves “nullability chaos”; going all‑in reduces mixed‑language friction.

---

Perceived Advantages of Kotlin Over Java

• Less verbosity: data classes, top‑level functions, expression bodies, properties, default immutability.
• Built‑in null safety without annotations/tooling; nullable vs non‑nullable types enforced by the compiler.
• Stronger type system: better generics, function types, declaration‑site variance, type aliases, contracts.
• Language features not easily matched by Java + tools:
  • Extension functions and delegated properties.
  • Sealed classes, exhaustive when, pattern‑matching‑like constructs.
  • Coroutines for async / generators; keyword arguments; interface delegation.
  • Powerful DSL support (scope functions, lambdas with receivers, infix/operators).
• Multiplatform story (JVM, JS, native, WASM) lets orgs share models/logic across platforms.

---

Critiques of Kotlin and Counterpoints

• Some dislike loss of checked exceptions; see unchecked‑only flow as worse, even with Result.
• Others argue checked exceptions in Java are painful and top‑level handlers + explicit unwraps are enough.
• Concerns about:
  • Coroutines vs preemptive lightweight threads; function coloring and ecosystem lock‑in.
  • Lambda/DSL style making code hard to read; “every library its own mini‑DSL”.
  • Extension functions scattering behavior across files; harder to see where methods come from.
  • Tooling lock‑in to JetBrains IDE; weaker LSP support than Java.
• Some see Kotlin as only “marginally better” given modern Java (records, lambdas, Optional, pattern matching, Loom, Valhalla), plus strong Java tooling and static analyzers.
• Others insist Kotlin is vastly better because Java can’t undo legacy choices (null‑by‑default, mutability, openness).

---

Android, Ecosystem, and Oracle

• Android is Kotlin‑first; some newer libraries (e.g., Jetpack Compose) are Kotlin‑only or Kotlin‑centric.
• Using modern Java on Android can be awkward (desugaring, limited standard library); Kotlin sidesteps this.
• Several tie Kotlin and Go’s rise partly to unease with Oracle’s stewardship of Java, though others note Kotlin still rides the JVM.

---

Process, Automation, and AI

• Meta built an automated pipeline around JetBrains’ Java‑to‑Kotlin (J2K) converter.
• Deterministic, correctness‑preserving transforms are preferred over LLMs, which can silently produce wrong but compiling code.
• Some worry about lost git blame granularity; others note careful file moves can preserve history, but per‑line history still gets noisy.

Approach to reducing nitpicks (embeddings & KNN)

• Many commenters find the final solution (embedding comments and doing KNN-style similarity filtering) plausible, even if “hacky.”
• Some note this is effectively a simple classifier; suggest trying other ML models (random forest, XGBoost, small neural nets) on top of embeddings.
• Idea of a “universal nit” via averaging embeddings across customers is proposed; authors say they’ll try it and already combine upvoted/downvoted sets to reduce false positives.
• Concern raised that clustering might incorrectly suppress comments about specific modules/classes if many prior comments there were downvoted.

Prompting vs post-hoc filtering

• Several argue the problem “should” be solvable via better prompting, including:
  • Clearer definitions instead of “nits” (e.g., “stylistic/pedantic/trivial comments”).
  • Explicit severity labels at the end of responses.
  • Chain-of-thought plus tagging nitpicks for removal in a second pass.
• Others report similar experiments with severity scores and LLM-as-judge that still misclassified important issues as nitpicks.
• Discussion of known failure modes: action bias, long-context confusion, ambiguous wording, conflicting instructions.

What counts as a nitpick?

• Strong disagreement on whether the article’s example is actually a nitpick; some see it as important for long-term maintainability.
• Many emphasize that nitpickiness is context- and company-dependent, and even the same comment can be trivial in one PR and crucial in another.
• Some suspect ego or “ship fast” culture may drive pressure to label valid criticism as nitpicking.

Usefulness of AI code review bots

• Mixed views:
  • Supporters see value as a first-pass “extra pair of eyes” that catches style, duplication, and obvious problems before human review.
  • Critics report high noise, hallucinated issues, and little real benefit compared to linters and human review; fear juniors over-trusting AI feedback.
  • Several argue code review is precisely where human judgment, knowledge-sharing, and mentoring are most important.

Linters, alternatives, and metrics

• Debate whether AI review adds more than well-tuned linters/formatters; proponents point to more nuanced, context-aware rules.
• Others say overly complex rules are themselves the problem.
• Metric choice criticized: “percentage of comments addressed” may reward leaving fewer comments; suggestions include normalizing by files or lines changed.

Pricing & incentives

• Some see the quoted per-file/per-dev pricing as expensive, especially for lower-wage markets or cash-strapped orgs; others note it’s a small fraction of developer salary.
• Commenters highlight that LLMs being billed per token may bias toward verbosity, though competition and user instructions can push toward concision.

HTTP status codes and API semantics

• Debate over whether HTTP status codes are good design for app-level errors.
• Some argue app-specific error payloads should dominate, with HTTP codes only indicating transport-level success/failure.
• Others insist layered design makes sense: HTTP handles resource/transport status (e.g., 404, 429), app errors go in the body.
• Disagreement over using 404 for “resource not found in DB” vs “endpoint doesn’t exist”; some see both as 404, others prefer 200 with an empty/“no results” payload.

Feed reader behavior & conditional requests

• Central complaint: many RSS/Atom readers poll too frequently with unconditional GETs of large feeds.
• Proper behavior cited: send If-Modified-Since / If-None-Match and respect 304 Not Modified.
• Some readers do this correctly; others hammer feeds every few minutes and ignore caching semantics, effectively wasting bandwidth.

Aggressive rate limiting and 429 responses

• The blog in question returns 429 and advises a 24‑hour retry for clients that repeatedly fetch unconditionally.
• Supporters: servers owe clients neither unlimited requests nor special treatment; 429 + Retry-After is a clear signal, and misbehaving clients should fix caching.
• Critics: blocking after 2 hits in 20 minutes for a 500KB RSS feed is “hostile” and punishes end users, especially behind shared IPs or when testing new readers.
• Semantic dispute over whether 429 is “rate limiting” vs “blocking,” but practical effect is the same: no content during the window.

Bandwidth, feed design, and caching

• The feed contains 100 full posts (500KB). Some say that’s excessive and should be trimmed (e.g., fewer items, summaries only).
• Others defend full-content, long-history feeds; the real waste is clients re-downloading unchanged content instead of using conditional requests.
• Examples given where individual readers account for noticeable percentages of a site’s yearly egress.

Bots, LLM scrapers, and infrastructure

• Several report big increases in bot and LLM-related traffic, often ignoring robots.txt and faking user agents.
• Approaches mentioned: blocking datacenter IPs, “bot motels” (trapping crawlers in junk content), poisoning indexes.
• Some suggest CDNs, WebSub/pubsubhubbub, or third-party hubs to offload polling; others resist CDNs as corrosive to an open, independently hosted web.

Miscellaneous tangents

• Grammar digression on “which” vs “that.”
• Reflections on falling traffic for small sites, search downranking, paywalls, and monopoly/antitrust politics.

Nature of the work and PTSD

• Many describe Facebook-style moderation as “absolutely grim” and uniquely corrosive: constant exposure to murders, suicides, child sexual abuse, torture, war gore, etc., for 8–10 hours a day.
• Commenters stress that occasional exposure to brutality (accidents, illness, a few violent videos) is not comparable to “mainlining” it full-time.
• Some note that people often think they can “handle it” until cumulative exposure triggers PTSD or other lasting effects.

Comparison to other traumatic jobs

• Moderation is compared to paramedics, ER staff, police, soldiers, suicide hotlines, and CSAM investigators.
• Key differences cited:
  • Volume and density of disturbing material are much higher.
  • Moderators are powerless to help victims, unlike first responders.
  • Often minimal support, low pay, and outsourced contractor status.
• Others argue many professions carry trauma and that susceptibility varies widely between individuals.

AI, automation, and technical fixes

• Strong support for using AI to reduce human exposure, especially for “obvious” repeats via hashing or classifiers.
• Counterpoints:
  • AI can’t fully replace humans; new and borderline content still needs human labeling.
  • Moving the problem to dataset curators just shifts the trauma.
  • Concerns about over-censorship, lack of appeals, and corporate incentives to remove staff once AI is “good enough.”
• Debate over on-device vs server-side scanning for CSAM, and the civil-liberties risks of scanning users’ private devices.

Centralization, incentives, and platform design

• Several argue giant centralized platforms inherently concentrate the worst content and create industrial-scale trauma; more federated or self-hosted models might limit spread and scale.
• Others note federation (e.g., Mastodon) also has moderation whack-a-mole problems and can harbor abusive instances.
• Many blame engagement algorithms rather than mere hosting; calls for simple chronological feeds and less growth/engagement pressure.

Compensation, exploitation, and equity

• Dispute over paying Kenyan moderators a fraction of US rates:
  • One side calls it straightforward exploitation enabled by borders and local labor markets.
  • Another says “local market rate” is normal and workers chose these jobs over alternatives.
• Some suggest hazard pay, strict exposure limits, mandatory psychological support, and time-limited rotations; others question whether such work should exist at all at current scale.

Security concerns vs. geopolitics

• Many see the move as partly justified: routers are critical choke points, TP-Link has a long vulnerability history, and Chinese state leverage over companies is viewed as a serious risk (botnets, infrastructure attacks, backdoors, coerced updates).
• Others argue the focus is selective and political: all major router vendors have poor security track records, US/Western agencies also tamper with networking gear, and the US is not applying the same standard to domestic or allied companies.
• Some say if the US were serious, it would enforce uniform security/privacy rules (including data-broker bans and anti‑“cloud lock‑in”) rather than targeting specific Chinese brands.
• There’s debate over whether this is legitimate security hardening or protectionism to preserve US tech dominance and raise prices.

Router firmware, updates, and responsibility

• Widespread consensus that consumer router firmware is generally bad: slow or nonexistent updates, many CVEs, insecure defaults, cloud dependence, and short support lifetimes.
• TP-Link is called out for especially poor patching and update discipline; some suggest bans or tariffs should target insecure products regardless of country.
• Proposals: regulators scan ISP address space for vulnerable routers, require ISPs to pressure/suspend customers until patched, and force vendors to allow third‑party firmware (OpenWRT/DD‑WRT) and not sell near‑EOL devices as “new”.
• Some highlight that even “open” router stacks still rely on closed Wi‑Fi firmware blobs from chipset vendors.

Alternatives, brands, and architectures

• Popular alternatives mentioned: Ubiquiti/UniFi, Mikrotik, Aruba Instant On, Ruckus (often off‑lease), GL.iNet, Protectli + pfSense/OPNsense, OpenWRT One, generic mini‑PCs as routers, and separate APs.
• Experiences with TP-Link are mixed: some praise price/performance and reliability; others report instability, poor mesh behavior, forced registration, and dark patterns.
• Several recommend a “router-as-PC + APs” approach for better control and longevity, but acknowledge complexity for non‑experts.

Home networking & IoT design debates

• Strong thread arguing for:
  • Client isolation via VLANs or AP‑level mechanisms.
  • Default denial of Internet access for IoT, with local brokers (e.g., MQTT) mediating behavior.
  • APs evolving into trusted, frequently updated “edge platforms”.
• Counterpoints: whitelisting Internet domains is hard at scale; vendors want cloud lock‑in; most users can’t manage VLANs; and “client isolation vs. easy casting/streaming” is a real usability trade‑off.

LLM–LLM Conversations and “Cooperation”

• People report running models against each other (e.g., via local tools) and observing endless polite “goodbye” exchanges.
• Many argue this is just next-token prediction over human-style data, not genuine cooperation or cultural evolution.
• Some note that models are usually forced by the surrounding code to always reply; they lack a true “end of conversation” state.

End-of-Conversation and Agent Framing

• Suggestions: introduce explicit “[silence]” or “[end-conversation]” tokens, or treat “end chat” as a tool the model can call.
• Others counter that models are optimized to always respond and don’t “decide to obey”; they just continue the script.
• A popular framing: LLM interactions are like movie scripts where a writer extends text containing fictional agents; “cooperation” is a property of the story, not the underlying program.

Mimicry, Reasoning, and Consciousness

• One side: LLMs just mimic patterns; there’s no new culture unless they create their own slang or styles, not found in training data.
• Counterpoint: humans also learn from examples; cultural evolution only appears in larger interacting populations.
• Debate extends to whether LLMs “reason” or could be conscious, with comparisons to ordinary software and even rocks or chemical reactions. No consensus is reached.

Security, Prompt Injection, and Token Trust

• Prompt-injection is framed as hard because the model sees one undifferentiated text stream.
• Proposed fix: “colored” tokens (trusted vs untrusted) or stronger treatment of system messages.
• Critics note annotation and conceptual complexity, arguing we should mostly reuse standard security principles (least privilege, user prompts, defense in depth).

Paper’s Methodology and Claims

• Several see the work as interesting for game-theoretic / evolutionary analysis (e.g., Donor Game and indirect reciprocity).
• Skeptics say parameter choices are arbitrary; results may be artifacts of the setup or output style (more detailed vs vague strategies) rather than deep training biases.
• Concerns about weak ablation/sensitivity analysis and overreaching language around “cultural evolution” and “falsifying” broad claims about LLM cooperation.

LLMs as Experimental Agents

• Some are excited about using LLM agents for large-scale social or game-theoretic simulations, potentially aiding sociology and theory-of-mind research.
• Others caution that cultural effects in LLMs are transient (lost once context is gone), so “evolution” may be very different from human culture.

Overview of the new H‑1B rules

• Thread participants say the changes include:
  • Beneficiary‑centric lottery (one person, one draw; passport required).
  • Easier job changes: can start work upon petition filing rather than waiting for approval.
  • Extended “cap‑gap” so F‑1 students keep work authorization longer while transitioning to H‑1B.
  • Founders can self‑petition if they effectively control the company.
  • More roles tied to research institutions are cap‑exempt, including some startup research hires.
  • Clarified “specialty occupation” rules, especially for interdisciplinary AI roles.
  • Stronger fraud checks, mandatory site visits, and “bona fide job offer” requirements.

---

Green cards, dual intent, and backlogs

• Several comments stress H‑1B is explicitly a dual‑intent visa; using it as a step toward a green card is legal.
• Long green‑card queues (especially for Indians and Chinese) are described as “decades long,” creating de‑facto semi‑permanent H‑1B status and strong employer leverage.
• Per‑country caps are heavily criticized as arbitrary and discriminatory; defenders say they preserve diversity.
• Some want caps eliminated or a single global queue; others argue caps prevent single‑country dominance.

---

Labor markets, wages, and abuse

• One camp says there is no real shortage of US tech talent; H‑1B is framed as wage‑suppression and “indentured servitude” via deportation risk.
• Others counter that:
  • H‑1Bs often earn similar or higher total comp at big tech firms.
  • The main abusers are offshore “body shops” and IT consultancies, not core product companies.
• Reported abuses:
  • Multiple sham entities submitting registrations for one person.
  • Fake offices, ghost jobs, and PERM ads placed where no US worker will realistically see them.
  • Underpayment via misclassified roles or low prevailing‑wage levels.
• Proposed fixes from commenters: high H‑1B wage floors (e.g., 90th percentile), auctioning visas, or heavy per‑visa fees to ensure only truly scarce hires are sponsored.

---

Startups, founders, and self‑petition

• New founder‑friendly rules (self‑petition if owning or controlling the company) spark debate:
  • Some fear shell LLCs purely to obtain visas.
  • Others note you must still meet prevailing‑wage and job‑reality tests, and argue this is good if you can genuinely fund your own salary.

---

National competitiveness vs. citizen protection

• Pro‑H‑1B side: US tech dominance, “brain drain” of other countries, and net economic growth depend on attracting top global talent; restricting this pushes work and offices abroad.
• Skeptical side: in a period of large tech layoffs, expanding or easing H‑1B is seen as directly harming US workers and weakening bargaining power.

---

Politics, timing, and social tension

• Some see the timing (late‑term rulemaking) as “regulatory theater” likely to be reversed by the next administration; others reply that rulemaking is inherently slow and has been in the works for years.
• Commenters expect differing futures depending on political control: anything from outright hostility to legal immigration to dramatically expanded H‑1B quotas.
• The thread contains visible tension around race, nationality, and class; several participants explicitly call out xenophobia and racism, while others focus on economic self‑interest and national labor priorities.

Phone calls, trust, and verification

• Many argue any unsolicited call/email demanding urgent action should be treated as hostile; you should hang up and call back via a number you independently look up (“hang up, look up, call back”).
• Others note banks, telcos, and healthcare providers routinely behave like scammers (calling from unknown numbers, asking for SSN/DOB, sending links), which normalizes risky patterns.
• Disagreement on how often banks legitimately block or freeze accounts after customers refuse to cooperate on such calls; some say it happens, others are skeptical.
• STIR/SHAKEN and carrier “scam likely” flags help somewhat, but caller ID can still be spoofed; SS7-level attacks and network compromises are mentioned as deeper risks.

Google Authenticator, cloud sync, and 2FA philosophy

• Strong criticism of Google Authenticator’s cloud backup: once TOTP seeds are in Google’s account backend, compromising Google yields all codes.
• Some report bugs where disabling sync corrupted codes; others confirm you can turn off sync but debate whether Google truly deletes seeds.
• Broader debate: backing up/syncing TOTP undermines “something you have,” turning 2FA into “phishing with extra steps,” but without it many users lose access and support becomes impossible.
• Alternatives discussed: other authenticator apps, password managers with TOTP, hardware tokens (WebAuthn/FIDO2, YubiKeys), and their usability vs. security tradeoffs.

Crypto custody and irreversibility

• Thread emphasizes that crypto’s irreversibility and lack of institutional recourse make these scams uniquely destructive compared to bank accounts.
• Storing seed phrases in cloud photos or screenshots is widely condemned; suggestions include offline physical storage, hardware wallets, multisig, and separating “hot” vs. “cold” wallets.
• Counterpoint: robust self-custody procedures (titanium plates, safes, multisig, inheritance planning) are complex and fragile for ordinary users; losing or damaging physical backups is also a risk.
• Several see crypto as effectively “speedrunning” why financial regulations and chargebacks exist; others argue banks and cash are still dominant tools for money laundering.

Google support, impersonation, and UX issues

• Many find it inherently implausible that “Google support” would proactively call a free-user, which itself is a useful red flag.
• Complaints about big-tech customer service: opaque processes, reliance on volunteer “product experts,” and lack of reliable, human recovery channels.
• Some suggest Google and similar firms should publish definitive “we never call you about X” messaging and SEO it, or simply provide real, paid support.

Prompts, MFA bombing, and security UX

• Concern that Google’s one-tap “Yes/No” device prompts are too easy to fat‑finger or approve under pressure; this enables MFA bombing.
• Comparison to systems that require entering or matching a code on the second device, which are slightly slower but more resistant to social engineering and accidents.

DMCA and abuse

• Example raised where a scammer allegedly used a bogus copyright claim to get an incriminating recording removed, illustrating how DMCA-style systems can be abused to erase evidence.

Aesthetic reactions to Boston City Hall

• Many commenters call the building “hideous,” “dystopian,” and intimidating, describing its message as “we will crush you.”
• Some see it as humorous or “absurdist,” like an elephant ballerina or a Quake level, and enjoy it as an extreme, memorable object compared to bland glass boxes.
• A smaller group argues it is beautiful or at least visually striking, especially in photos without the plaza, and appreciate it as a bold, expressive work of brutalism.
• Several say it feels like totalitarian or military architecture, evoking torture chambers, machine-gun nests, or civil defense bunkers.

Functionality and user experience

• Critics describe the interior as dark, confusing, soul-sucking, and uncomfortable (wild temperature swings, awkward columns, poor accessibility).
• Others say it is easy to navigate, has good light and air, and offers many gathering spaces inside and out, especially compared to the cramped, inaccessible old City Hall.
• Some argue the building serves its large-plaza role for protests, concerts, and TV events, even if unpleasant day-to-day.

Plaza, climate, and urban context

• The brick plaza is widely disliked as an empty, windy, winter “wasteland” and missed opportunity in an otherwise lively area full of shops and alleys.
• The recent (2022) renovation is seen as an improvement—playground, more activation—but many still find it harsh in cold months and underused for commerce.
• Several regret the demolition of Scollay Square and other neighborhoods for Government Center, seeing it as emblematic of damaging mid‑century urban renewal.

Materials, aging, and construction quality

• Commenters discuss post‑WWII shifts: loss of skilled labor, preference for cheap concrete and glass, and reduced use of durable brick or wood.
• There is concern that exposed concrete ages poorly in Boston’s polluted, salty, humid climate and may deteriorate faster than older stone or brick buildings; sealants or stucco are proposed but clash with brutalist aesthetics.

Architecture, taste, and ideology

• Debate over whether beauty is subjective vs. some forms (e.g., Gothic, classical) having near‑universal appeal.
• Some blame modern architects and clients for prioritizing “bold statements” and personal ego over usability and public preferences.
• Others defend challenging styles as legitimate art, arguing that public incomprehension does not alone make a design bad.

Whistleblower actions and retaliation

• Commenters praise the engineer for raising safety concerns despite retaliation and potential blacklisting.
• Some criticize his later Reddit disclosures as unprofessional or clout‑seeking; others argue tone is irrelevant compared to exposing safety risks.
• Debate over whether posting on Reddit years later is negligent vs. a valid form of “media” pressure.
• General advice: whistleblowers should stay anonymous where possible; institutions are seen as poor at protecting identities.

Safety culture vs. profit incentives

• Strong theme that many firms prioritize speed, cost, and quarterly results over safety.
• Examples raised: Tesla issues, “ship now, fix later” culture, aviation and hardware parallels.
• Counterargument: some companies and engineers genuinely care about safety, but often only after profitability is secured.
• Regulation is widely seen as the main reason safety features (e.g., seatbelts) exist; market rewards for extra safety beyond minimum standards are seen as weak.

EV design, weight, and suspension failures

• Discussion on whether “electric” is relevant to the failure: one side says the issue is suspension engineering, not powertrain.
• Others note EVs are generally heavier, increasing suspension loads; some counter‑examples show comparable ICE and EV weights, leading to dispute over how broad the “EVs are heavy” claim really is.

Legal and ethical issues: blacklists & GDPR

• Widespread concern about an industry‑wide recruitment blacklist and its legality, especially under GDPR and UK/EU law.
• Some argue such processing of personal data about whistleblowers likely conflicts with “legitimate interest” standards; details remain unclear.

Brand roles and reputations

• Confusion over the headline: comments clarify that VinFast hired JLR/Tata to design parts of VinFast cars, not vice versa; one comment states the opposite, creating some ambiguity.
• Several note this framing makes JLR look bad even though the alleged corner‑cutting is attributed to VinFast leadership.
• JLR and Land Rover are described as historically unreliable, especially electrically.
• Volvo and (to a lesser extent) Lucid are cited as brands that emphasize safety, though there is debate about how much that still holds under new ownership and platforms.

Engineering practice and experience

• Some blame inexperienced mechanical engineers and over‑reliance on first‑order metrics (weight, cost) without deep understanding of failure modes and long‑term durability.
• Others emphasize management pressure and impossible constraints as primary drivers of bad designs.

Access and Context

• Multiple commenters note the journal paywall; several link to the free arXiv preprint.
• Some urge others to read the full paper before judging, while others say the press coverage overstates what is actually done.

Headline Claim: 10 bits/s Conscious Throughput

• Central claim discussed: conscious “behavioral throughput” ≈ 10 bits/s vs ≈10⁹ bits/s sensory input.
• Many find 10 bits/s intuitively far too low, citing speech, reading, typing, gaming, or sports.
• Defenders stress this is about a narrow, compressed, high‑level cognitive bottleneck, not raw sensing or reflexes.

Information Theory and Language Rates

• Repeated reference to Shannon’s estimate that English has ~1 bit/character, leading to ~10 bps at ~120 WPM typing.
• Others point out extreme text compression (e.g., Wikipedia at <1 bit/char) and argue conscious semantic content is even sparser.
• Critics respond that this “compression framing” can always be tuned to hit 10 bps, making the number feel arbitrary or clickbaity.

Methodology and Examples

• 20 Questions: many argue it is a poor basis for a cognitive rate, being social, cooperative, task‑dependent, and highly compressed.
• Rubik’s cube, StarCraft, reaction tests: critics say mapping actions or APM to “bits” is reductive and misinterprets skill, pattern recognition, and motor learning.
• Some note complex problems can be stated in few bits (e.g., math integrals) but require huge computation, so “bits out” ≠ “processing done.”

Serial vs Parallel, Conscious vs Unconscious

• Paper’s use of dual‑task “psychological refractory period” to argue central serial processing is challenged; others cite multitasking and movement research suggesting more flexibility.
• Widespread agreement that most processing is unconscious and massively parallel; consciousness may be a narrow, serial “framebuffer” or attention stream.

Analogy Limits and Use of “Bits”

• Several object to treating humans as digital systems; argue continuous, embodied, biochemical processes don’t map cleanly to bits.
• Others counter that information‑theoretic bits (entropy) are substrate‑agnostic and legitimate for high‑level capacity estimates, if used carefully.
• Reductionism is defended as necessary but also blamed when it yields seemingly nonsensical numbers like “10 bits/s.”

Neural Interfaces and Practical Implications

• The paper’s jab that a Neuralink‑style BCI may be no better than a telephone (if cognition is 10 bps) is widely quoted; some find it funny and thought‑provoking.
• Others argue that shortening feedback loops and delegating to AI agents might still greatly boost productivity even with a slow human bottleneck.

Paper Quality and Media Hype

• Some praise it as a stimulating perspective that synthesizes data and poses useful questions about inner vs outer brain and routing/attention.
• Others call it “blog‑post level,” over‑reductive, and poorly grounded, criticizing back‑of‑envelope math and lack of new measurements.
• Media coverage using terms like “measure” and “quantifies” is seen as overstating what is, at best, a speculative, order‑of‑magnitude framing.

Artistic intent and commentary

• Many see the rat traders as satire of financial markets and trader “training,” highlighting how human traders are conditioned in similarly Pavlovian ways.
• Others argue it’s more than a joke: it exposes how simple pattern-recognition can be repackaged as “professional” trading, and implicitly challenges trader exceptionalism.
• A minority dismiss it as “shock art” or obscenity involving animals, finding the “brilliant” label overstated.

Ethics and treatment of animals

• Several commenters are disturbed by reports of electric shocks used in training; they object to causing suffering for art or commentary.
• Others contrast this with historical and current use of animals in labor and warfare (pigeons on assembly lines, bomb-guidance projects, Navy dolphins, a baboon signalman), noting society often considers such human work acceptable but balks at animals doing it.

Labor, consent, and class

• The project triggers debate about whether finance workers are mistreated “like rats” or actually privileged relative to other workers (e.g., logistics, factory jobs).
• A long subthread argues about what “consent” to work really means—ranging from “humans can choose jobs and retrain” to “consent is constrained by survival needs and geography.”
• One branch leans into GDPR’s strict definition of freely given consent to illustrate how often “choice” is coerced in tech and employment.

Finance, speculation, and value

• Some defend FX traders as providing real liquidity; others note FX volumes far exceed underlying trade and are mostly speculative.
• A strong critique targets public equity markets and complex instruments as little more than gambling that primarily benefits a few, versus simple debt financing.
• Counterarguments stress that shareholders are often pension funds and retirees, and that publicly traded companies fund genuinely productive activities.

Animals, AI, and performance

• Commenters reference other animal “traders” (goldfish, hamsters, dart-throwing chimps) and animal pattern-recognition feats (pigeons matching radiologists on mammography).
• This leads to speculation about whether rats could beat AI on prediction per unit of energy, and about existing or likely LLM-based trading systems.
• Some distinguish this rat project from pure randomness: here, rats are actually trained on market-derived signals, not just used as a gimmick.

Humor, language, and side debates

• Extensive wordplay on “rat race,” “rat as currency,” “ratcoin,” “ratchain,” and “vulture capitalists.”
• A mini-argument centers on the correct use of idioms like “pulling punches” vs. “selling short,” with no clear resolution.

Technological and Archaeological Aspects

• Commenters are struck by the “sci‑fi” feel of digitally unrolling fragile scrolls and reading nearly 1,800‑year‑old text.
• The Frankfurt project uses CT-like imaging; people compare it to similar efforts on Herculaneum papyri and even modern uses like scanning sealed trading-card packs.
• Some ask for the underlying academic paper; only press releases and museum pages are linked so far.

Language, Script, and Text Content

• The inscription is in Latin, but in very messy Roman cursive with inconsistent letter shapes and sizes; several call it “semi‑literate.”
• Others note that Roman cursive always looks hard to read to modern eyes, but agree this example is unusually sloppy.
• The text opens with the Trisagion “holy, holy, holy,” written as Greek “agios” in Latin letters; this links to Isaiah 6:3 and its Septuagint translation.
• Christograms like IHS and XP (chi‑rho) appear; a museum page provides a full Latin transcription and German translation.
• Discussion touches on translation conventions such as rendering the divine name as “Lord” (kyrios/Adonai) and how early Christians inherited this from Jewish and Septuagint practice.

Burial Practices and Christian Markers

• “Inhumation burial” is clarified as simple burial vs cremation.
• One commenter infers it may signal “here be Christians” in a context where cremation was more common; others push back that inhumation isn’t uniquely Christian, though Christianity did help displace cremation in parts of Europe.

Jewish–Christian Boundary and Messianic Judaism

• Long subthreads debate Messianic Judaism:
  • Mainstream Judaism and most scholars classify it as a Christian movement, despite its self‑identification.
  • Israel reportedly restricts citizenship for Messianic Jews, seeing them as evangelizing Christians in Jewish dress.
  • Participants distinguish ethnically Jewish Christians from non‑Jewish “Hebrew Roots” style groups who adopt Jewish forms.
  • Some view the latter as cultural appropriation; others defend their sincerity.

Early Christianity, Theology, and Polytheism

• The thread ranges widely into:
  • The Jewish roots of Christian belief and early disputes over how much of Jewish law to retain.
  • The Trisagion, Eucharistic theology, and continuity between Temple imagery and Christian liturgy.
  • The Trinity vs accusations of polytheism, the filioque controversy, and non‑Trinitarian groups.
  • Veneration of Mary and the saints, with debate over whether this functionally resembles polytheism or ancestor veneration.

Historicity, Dating, and “Common Era”

• Some discuss extra‑biblical references to Jesus (e.g., Josephus, Didache) and dating of the Gospels, with tension between traditional early dates and modern critical scholarship.
• A side thread critiques Luke’s census narrative as historically implausible, seeing it as harmonizing prophecy with known facts about Jesus’ origin.
• One commenter objects to using “CE” instead of “AD” in a clearly Christian context; others defend “CE” as standard and non‑religious.

Broader Reflections on Religion and Modern Practice

• Several explore how “religion” as a separate sphere is a modern concept; historically it was inseparable from worldview and daily life.
• Others critique contemporary churches for wealth, hierarchy, culture‑war politics, and distance from Jesus’ teachings on humility and care for the poor.
• Multiple book, podcast, and YouTube recommendations are shared for early church history and history of religions more generally.

Centralized error package proposal

• Many see the article’s “god error package” as over-centralizing domain knowledge and tightly coupling services.
• Critics argue errors are part of each service’s API; only very low-level, cross-cutting concerns (HTTP, protocols) should be global.
• Some feel it effectively reimplements an error “language” or exceptions inside Go, adding complexity and indirection.
• A few defend centralization for shared schemas/standards, but think the article’s concrete design is too heavy.

Go’s error model vs alternatives

• Strong sentiment that Go’s (T, error) style is clumsy and encourages boilerplate, especially for composing multiple calls.
• Calls for sum types / Result-like types and a ?-style operator; Rust is often cited as a better realization of “errors as values.”
• Others defend Go’s simplicity and explicitness, preferring visible error handling over “magic” monadic or exception-based flows.
• Debate over exceptions: some see them as better for default bubbling; others argue they’re harder to reason about, especially without checked exceptions or effect types.

HTTP status codes vs application errors

• Strong pushback against conflating internal errors with HTTP status codes or centrally mapping all errors to HTTP in a low level.
• Many argue HTTP should reflect transport/request handling (200/400/401/403/404/500 etc.), while application semantics live in the body.
• Some advocate extreme minimalism (always 200, errors in body); others highlight loss of monitoring, tooling, and infrastructure benefits.
• Consensus trend: use a small, pragmatic subset of HTTP codes plus structured JSON error payloads.

Error context, structure, and logging

• Broad agreement that plain strings without context are inadequate in large systems.
• Techniques mentioned: wrapping with %w, sentinel/custom error types, attaching structured metadata (key–value pairs), and stack traces via logging libraries.
• Some stress adding context mainly at subsystem boundaries rather than every helper function.

Fail-fast vs graceful degradation

• One camp: treat violated invariants as bugs, assert/fail fast, and avoid running in an unknown state.
• Opposing view: crashing entire processes (especially servers) for a single bad request is unacceptable; isolate failures per request/goroutine and recover.
• General recognition that distinguishing “bug” vs “user/input/environment error” is crucial to choosing between aborting, retrying, or degrading gracefully.

Idiomatic Go vs “imported patterns”

• Multiple comments warn against “writing Java/Scala/Rust in Go” with heavyweight frameworks and non-idiomatic abstractions.
• Others counter that Go’s minimalism sometimes forces people to reinvent missing features in ad hoc, inconsistent ways.

Self-hosting Ergo and Feature Set

• Several commenters run Ergo (formerly Oragono) for small private communities (friends/family, long-running small networks).
• Praised for: easy hosting, low resources, understandable Go codebase, built‑in websockets, and modern IRCv3 features.
• “Always-on” and multiclient support plus modern clients (e.g., Goguma, Gamja) make it feel like a contemporary chat system; many users don’t realize it’s IRC.
• Some are considering migrating from traditional IRC daemons (ngircd) to Ergo for better onboarding and server-side history.

IRC vs. Discord/Slack/Teams and “Walled Gardens”

• Strong dislike for Discord and Slack lock‑in: non-indexable history, repeated conversations, weak search, and risk of data loss or opaque reuse.
• Debate over whether IRC is a “walled garden”:
  • One side: not walled; open protocol, multiple clients/servers, easy logging, no enforced central platform.
  • Other side: in practice many networks lack public archives, so conversations can be as ephemeral as Discord.
• Some see lack of history as a feature that encourages moving durable knowledge to blogs/docs/forums.

Onboarding, App Fatigue, and Family Use

• Recurrent theme: people are tired of “yet another chat app.”
• Barriers: installing new clients, remembering server/credentials, and spreading conversations across many apps.
• Others report that moving a group chat is surprisingly feasible; people already juggle multiple platforms.
• WhatsApp’s phone-number login is seen as easier for non-technical users than usernames/passwords.

Matrix, XMPP, Signal, and Other Alternatives

• Mixed views on Matrix:
  • Critiques: complexity, Python Synapse resource usage, perceived single-company control, slow stabilization.
  • Defenses: large deployments exist; Matrix 2.0 and newer servers (e.g., Dendrite, Conduit) aim to improve performance.
• XMPP seen as mature, resource‑light, and suitable for self-hosting (Prosody, ejabberd, Snikket), but sometimes harder to deploy (especially on Kubernetes).
• Signal’s lack of multi-device history sync is viewed by some as a key privacy protection, by others as a usability limitation.
• P2P options like Jami/Briar are discussed as interesting but with tradeoffs (online-at-same-time requirements, mobile UX).

Protocol Design and Philosophy

• Some criticize IRC’s archaic, ad‑hoc text protocol; others argue it’s simple enough and battle‑tested.
• Broader wish for a “Gemini‑for-chat”: a very small, modern, federated messaging protocol—but recognition that full-featured, E2EE, async group chat inevitably brings complexity.