Adam Skye Jones

From linkApple says it is rolling back an earlier plan to move iCloud+ Hide My Email aliases onto a new domain, keeping them on `icloud.com` after community feedback. The actual change now applies to Sign in with Apple relay addresses, where new aliases will be issued on `private.icloud.com` while older `privaterelay.appleid.com` addresses keep working. In practical terms the post is a narrow but important compatibility notice for developers: account systems, validation rules, and allowlists now need to accept both the legacy relay domain and the new one without breaking mail flows.

From commentsThe HN thread treated the reversal as a meaningful win for privacy tooling that does not instantly self-identify as disposable relay mail. Commenters argued that masked addresses only remain useful if sites cannot trivially block them, so keeping Hide My Email on a mainstream `icloud.com` domain preserves the product’s social and technical camouflage. The discussion also drifted into the usual vendor-lock-in tradeoff, but the dominant mood was that Apple had corrected a bad move and preserved one of the more practical everyday privacy features normal users actually adopt.

From linkXusheng Li’s reverse-engineering write-up argues that Microsoft’s local image generation path in Paint and Photos is not purely local in the privacy sense users might assume. The analysis shows `AIServices.dll` sending prompts through a moderation endpoint, receiving back identifiers including a `watermarkId`, and then embedding a 16-byte GUID as an invisible watermark in the generated image. The most unsettling detail is not watermarking by itself, but the fact that the watermark is server-issued and specific enough to suggest a traceable provenance chain rather than a generic “AI made this” label.

From commentsThe HN discussion quickly separated two ideas that often get blurred together: generic provenance marks versus user-level tracking tokens. A lot of commenters said they could live with an anonymous AI-origin watermark, but saw a unique GUID tied to a server interaction as a much more serious privacy problem, especially if regulators never asked for that level of granularity. The thread also turned into a broader complaint session about Microsoft’s recent habit of stuffing intelligence features into formerly simple apps, with many readers treating this investigation as another example of product teams crossing the line between disclosure and surveillance.

From linkPaul Graham’s argument is that universities do not need a new “entrepreneurship” curriculum to produce better founders; they need to get better at their existing job of teaching people to build difficult things. He frames startup preparation as a product problem, not a finance or management problem, and says the best academic training therefore comes from disciplines like computer science, engineering, and biology where students acquire technical depth and making habits. The prescription is intentionally narrow: teach hard subjects well, make students believe starting a company is plausible, and encourage them to spend real time on their own projects.

From commentsThe HN thread did not dispute that building skills matter, but it pushed back on the implied picture of higher education as a startup feeder system. A lot of commenters wanted more room in the conversation for ethics, philosophy, and human development, and argued that the healthiest universities should create capable builders without reorganizing themselves around incubator logic. The result was a useful split-screen discussion: one side agreed with Graham’s practical recipe for future founders, while the other worried about what gets lost when elite schools begin to optimize too directly for venture-backed outcomes.

From linkThe project itself is closer to an explorable city simulation than a conventional game, turning San Francisco into a browser-based, low-poly navigable world with teleporting, walking, driving, coordinates, and lightweight multiplayer hooks. What makes it compelling is not dense mechanics but spatial fidelity: the hills, blocks, landmarks, and street textures are just detailed enough to trigger recognition while still feeling dreamlike and computationally stylized. It reads as a strong demo of how map, terrain, and urban context data can be remixed into a playful interface that sits somewhere between Google Earth, a nostalgia machine, and a prototype open-world engine.

From commentsThe HN thread was full of former residents describing an unexpectedly emotional reaction to wandering through a rough-edged but recognizable version of the city. People kept saying the low-resolution, slightly broken look actually enhanced the experience because it felt like walking through a remembered place rather than browsing a sterile map product. Alongside the nostalgia, commenters immediately started speculating about the larger pipeline: higher-resolution meshes, Street View texture reconstruction, MMO layers, and tools that could turn real geodata into game worlds for any city, not just San Francisco.

From linkBartosz Ciechanowski’s interactive essay does what his best work always does: it takes something familiar, in this case the Moon, and rebuilds understanding from first principles with layered visuals, precise narration, and just enough mathematics to stay grounded. The piece moves from relative size and mass through orbital distance, ellipses, phases, eclipses, and observational geometry, continually using live diagrams to connect abstract celestial mechanics to what people actually see in the sky. Rather than feeling like a textbook chapter dumped onto the web, it feels like a carefully staged instrument for intuition, where every animation is there to collapse one more common misconception.

From commentsThe HN comments were less about astronomy corrections than about admiration for the author’s communication style and what it means to borrow from it. One of the more active subthreads asked whether prompting an LLM to make “something in the style of Ciechanowski” crosses an ethical line, and the most thoughtful replies treated imitation as acceptable scaffolding if it helps people identify the underlying design principles instead of shipping derivative clones. So the thread became a small meta-discussion about authorship, influence, and how unusually complete interactive explanation work now functions as both inspiration and benchmark.

From linkMickey Petersen’s walkthrough presents Emacs 31.1 as a release defined less by one marquee feature than by accumulated quality-of-life improvements across the editor. He highlights the retirement of the old `unexec` dumper, continued maturation of tree-sitter support including easier grammar installation, and a long list of smaller changes that polish completion, startup behavior, editing ergonomics, and built-in subsystems. The underlying message is that Emacs remains healthy not by copying trend-driven product launches, but by slowly tightening the bolts on a huge, strange, deeply composable machine.

From commentsThe HN thread felt like a classic Emacs conversation: half release-note appreciation, half reflection on the eccentric powers that make the editor durable. Readers surfaced side paths like the “antinews” downgrade notes, lamented the disappearance of older platform quirks such as `unexec`, and used the post as an excuse to reminisce about features that only make sense once you have lived inside Emacs for years. Even when specific changes were niche, the tone was affectionate rather than defensive, with commenters treating 31.1 as another sign that the project can still evolve without losing its weird identity.