It wouldn't if you own the full chain, i.e. have knowledge of both the on-device salt and hash AND the server salt and hash. However, in the scenario of using a third party like TelemetryDeck you as the developer would not be able to link the device hash to the server hash because you never see the latter.
So, my reading is: if there would be some mechanism (or a third party) which obfuscates the server hash so that you cannot tie it back to the device hash and only tells you "we've seen this device already" it could be anonymous. Of course, it also heavily depends on what other data you associate with that.
Nice writeup and I really like the minimal aesthetic of your site!
On unique users: I wonder if there is a way to set this up to work similar to TelemetryDeck's double-hashing anonymization[1]. Did you look into that before deciding to go purely session-based?
We are giving our dog Fluralaner/Bravecto[1] against ticks which paralyzes and kills them when they bite, drastically reducing potential exposure to Lyme disease. Unfortunately not approved for humans and therefore an interesting inverse: humans can get vaccinated against TBEV but not against Lyme disease whereas dogs can get vaccinated against Lyme disease but not TBEV.
This is exactly what I am working on for my city (Berlin). Right now it gives you sun/shade times for outside areas of cafes and restaurants as well as heatmaps for public parks and playgrounds.
The idea is to eventually offer a sun or shadow mode and the app will then surface areas, squares, and streets with more sun or shade and eventually offer walking and biking routes with more or less sun.
While the author explicitly wanted Claude to be in the creative lead here, I recently also thought about how LLMs could mirror their coding abilities in music production workflows, leaving the human as the composer and the LLM as the tool-caller.
Especially with Ableton and something like ableton-mcp-extended[1] this can go quite far. After adapting it a bit to use less tokens for tool call outputs I could get decent performance on a local model to tell me what the current device settings on a given track were. Imagine this with a more powerful machine and things like "make the lead less harsh" or "make the bass bounce" set off a chain of automatically added devices with new and interesting parameter combinations to adjust to your taste.
In a way this becomes a bit like the inspiration-inducing setting of listening to a song which is playing in another room with closed doors: by being muffled, certain aspects of the track get highlighted which normally wouldn’t be perceived as prominently.
And, to add to that, how to know when to slow down. Also, having worked at a big company myself, I think the question shifts towards "how to get fast" without compromising security, compliance etc.
They may not understand it but they may very well be able to reproduce aspects of feedback and comments on similar pieces of software.
I agree that the approach shouldn’t be done unsupervised but I can imagine it being useful to gain valuable insights for improving the product before real users even interact with it.
Looks like a really nice project! Would love the ability to „subscribe“ to a place or area and get a mail or notification once there is a new book added for that location. Another nice addition would be a heatmap layer for the lower zoom levels.
Working on updating my Your-Age-in-Days app[1] for iOS 26. The main motivation was to have the days I've lived always available on the lock screen with a more native feel than the workaround I had before (nightly Shortcut which updates the background image and adds the current number as an overlay to it).
Does this happen at a specific time of day (e.g., start/end of shift) or randomly? The quickest way would be to wear ANC headphones during the most noisy times. Then, if possible and allowed, you could look into soundproofing your windows. Maybe reach out to the garage owner as well and tell them about your situation.
Quick heads-up: I clicked through several links on your blog and website (Integrations, Guide, API) and they don’t seem to go anywhere specific yet, or just link back to the top of the page. This makes it harder to evaluate and find out more about your product.
Are you referring to the outside seating polygons? Wouldn’t these stereo images still have a lot of noise (trees, cars, trucks, smaller non-building structures) obstructing the target areas?
I have circled back to using the apps that are already on my phone, especially the Apple Reminders app which I am currently trying out as my main notes and ideas system.
I have placed it as one of the two bottom widgets on the lock screen which gives me immediate access to everything I need to capture a thought: a main note, the list where I want to store it (e.g., work or personal), the notes field if more context is needed, and I can flag it or schedule a reminder. The app then also has an optional auto-categorize feature which works quite well. Add to that reliable sync across devices and except for a good way to bulk export lists, this has everything I want from a quick draft and capture system.
Currently building something like this for my city. One major challenge I've come across so far is that most APIs will give you coordinates for an address of a place within a building but none of the free, paid or crowdsourced options have reliable information on outside seating polygons. Of course, you could always display the places around you with live shadow data on a map, leaving it up to the user to zoom in and decide based on the satellite image whether the restaurant or café offers outside seating. But to plot the route and then suggest nearby sun/shadow seating options to the user, you would need this information.
It’s likely a mix of availability bias and pattern-seeking/apophenia: a few recent outages stand out and the rise of LLMs in recent years is also ever present. This increases the chance to assume a link between both even without evidence that outage frequency actually changed.
Also, I don’t think the switch is as binary: these industry shifts tend to be more gradual where more experienced programmers adopt LLM tools to suit their workflow and newer developers still learn fundamentals because real-world engineering of complex systems quickly exposes a lack of understanding.
This seems to be the article's author's own language Bauble[1], "a toy for composing signed distance functions in a high-level language (Janet), compiling them to GLSL, and rendering them via WebGL"[2].
While the article makes several implicit references to studies, it doesn’t actually cite any. After some quick research I found what seems to be the "6 A.M. to eat old rice" study[1].
Abstract:
"Background: Globally, hot cooked refined rice is consumed in large quantities and is a major contributor to dietary glycaemic load. This study aimed to compare the glycaemic potency of hot- and cold-stored parboiled rice to widely available medium-grain white rice.
Method: Twenty-eight healthy volunteers participated in a three-treatment experiment where postprandial blood glucose was measured over 120 min after consumption of 140 g of rice. The three rice samples were freshly cooked medium-grain white rice, freshly cooked parboiled rice, and parboiled rice stored overnight at 4 °C. All rice was served warm at 65 °C. Chewing time was recorded.
Results: incremental area under the curve (iAUC) of the control rice, freshly cooked medium-grain white rice, was the highest: 1.7-fold higher (1.2, 2.6) than reheated parboiled rice (p < 0.001) and 1.5-fold higher (1.0, 2.2) than freshly cooked parboiled rice (p = 0.001). No significant difference in postprandial glycaemic response was observed between freshly cooked and reheated parboiled rice samples (p = 0.445). Chewing time for 10 g cold-stored parboiled rice was 6 s (25%) longer and was considered more palatable, visually appealing and better tasting than freshly cooked medium-grain (all p < 0.05).
Conclusions: For regular consumers of rice, reheating cooked rice after cold storage would lower the dietary glycaemic load and, in the long term, may reduce the risk for type 2 and gestational diabetes. More trials are needed to identify the significance."
So, my reading is: if there would be some mechanism (or a third party) which obfuscates the server hash so that you cannot tie it back to the device hash and only tells you "we've seen this device already" it could be anonymous. Of course, it also heavily depends on what other data you associate with that.