I'd go with a more reputable vendor unless you're on a really tight budget because Aliexpress isn't even that cheap, all things considered. There are fake chips and really low quality parts out there that will waste your time.
You can get a range of ESP32 boards from Digikey for $5-$8 and you'd have to scrape the bottom of the barrel to get them much cheaper than that on Aliexpress.
Eh. This isn’t a finished project. Designing and writing marketing content requires a completely different headspace to when you’re working the product, and isn’t something you can context switch easily.
I only have a problem with obvious AI marketing pages when it’s a finished product that’s on sale.
It's marketing for the origin site. The line of thought is that the author sees significant traffic from xyz.com in the ref query string, and considers advertising or partnering with the origin site.
Honestly, it is quite useful for niche/startup sites. I have been on both ends of conversations that began from seeing these in web analytics (as someone that saw incoming traffic from a site and reached out, and as someone that received contact from a site I linked to) - and both times it ended in a mutually beneficial partnership.
I can understand the privacy argument to some degree, but it provides no more information than the standard Referer header (and if you use analytics like Simple Analytics/Plausible, it is a lot more visible).
You never ran a website for profit, have you? Knowing who is sending you traffic lets you decide whether your marketing is working, where you should write your blog posts to get more views, etc. This has been the way the web works for decades.
FWIW I've been experimenting with Three.js and AI for the last ~3 years, and noticed a significant improvement in 5.4 - the biggest single generation leap for Three.js specifically. It was most evident in shaders (GLSL), but also apparent in structuring of Three.js scenes across multiple pages/components.
It still struggles to create shaders from scratch, but is now pretty adequate at editing existing shaders.
In 5.2 and below, GPT really struggled with "one canvas, multiple page" experiences, where a single background canvas is kept rendered over routes. In 5.4, it still takes a bit of hand-holding and frequent refactor/optimisation prompts, but is a lot more capable.
Excited to test 5.5 and see how it is in practice.
Unfortunately you've now made an incredibly niche browser, and the lack of those metrics is a good fingerprint by itself. How browsers render SVGs can be used for fingerprinting (even the underlying OS affects this, and I assume you'll want to see those), combine with ISP from IP address, and unless theres hundreds users in every city you're now pretty easily trackable.
There's no problem with having a unique fingerprint. The problem is having a consistent one. Randomize the fingerprint every time and you're fine. The IP address problem applies to everyone, including anyone using tor browser. The only solution to that is not using your own IP address (VPN/proxy). If I were going to make a secure privacy focused browser it either wouldn't allow things like rendering SVGs (which have introduced vulnerabilities beyond tracking) and wouldn't allow much (if any) JS and only a sane subset of CSS.
> Unfortunately you've now made an incredibly niche browser, and the lack of those metrics is a good fingerprint by itself.
If 100 people are using that browser, how will they know which one is me?
> How browsers render SVGs can be used for fingerprinting (even the underlying OS affects this, and I assume you'll want to see those)
Can you provide details on this? And how will they know which OS I'm using (through SVG rendering...)? The UserAgent definitely should not send the OS.
> combine with ISP from IP address
That's already provided whether I use Private mode or not, correct? I can always use a VPN.
You're the only one out of 100 that visits HN, or who's use matches a particular timezone, or who has the use pattern that [anti-]correlates with your work pattern, or ...
So the HN operator sees someone using this browser, with this timezone. Then I go to some other site. Let's pretend that site's operator and HN's are identical. How will they know that I'm the same guy who went to HN? How does he know there aren't two people who use the browser in the same timezone (and the other one doesn't go to HN)?
I think the point is that it takes very few data points to effectively deanonymize someone. And the less common a data point is, the greater the information gain. "User is male" eliminates ~half of users. "User actively reads HackerNews" eliminates >99%. "User uses this niche browser that only 1000 people have ever been seen using" eliminates 99.999%.
This is how surveillance operates at scale. You don't need a stable identifier linking a specific person's identity, you just need a few data points to narrow it down to even a few thousand people. Then you apply more focus on those people, gathering data points that eliminate people until you're left with your target. And thanks to decades of global iteration on surveillance infrastructure, and AI to glue data sets together, it's all automated.
Signal does not send any sensitive information in push notifications sent via APNs [0]. This story concerns the local OS cache of push notifications, which are triggered after E2E decryption has occurred.
This already exists in a limited form as Signed HTTP Exchanges. It's intended primarily for caching and serving content from CDNs, but associating with the origin host.
Huge fan of Reticulum, fixes some of my biggest gripes with Meshtastic. Shame it hasn't got as much adoption yet. For those looking for Meshtastic-equivalent things in the Reticulum ecosystem:
Didn't got adoption because the code base is awful to work with and there is a trauma against bluetooth being used as a network path.
Plus: encryption is heavy when bandwidth is limited and over radio waves we aren't even permitted to encrypt data most of the times.
Please don't read my comment as bringing down the project. I'm a fan, used everything it was produced but ultimately is unusable for serious applications on the current state. I really tried hard to adopt it.
If the reticulum code is worse than the meshtastic one, then it is truly atrocious. Been trying to get a specific board to simply "sleep" its radio using meshtastic, and nobody seems to know WHY it doesnt do it. The code is horrible spaghetti with lots of ifdefs. And nobody seems to know why things are the way they are in the code re: power handling. ChatGPT wrote me a brute force method that works, but its ugly and I dont want to maintain patches.
But it is fairly easy to hack on. I have no idea how to debug things without USB serial connected, though.
Sorry, can't really compare because I've never had to suffer looking at meshtastic source code. Quite tempted at this point to just throw the python implementation of reticulum at Claude and see if a validated port to C++ is possible.
Maybe a bit offtopic and not LoRa, but I've been looking at ESP32 and they include an ESPMesh for the WiFi radio with a promise of about 500 to 1000 meters range from what I read. It isn't the same range as LoRa, but it is "larger" bandwidth and for the price of 3 dollars per unit seems promising on urban areas to connect people. I'm trying it out now.
What are those gripes? If I don't have anyone else who would use it, but would hang out in a public chat room, it didn't seem like reticulum was the right choice for that? You need destinations on things?
It seems like big cities get congested, on marginal systems the chances of only getting half the messages is very high. It really dosnt integrate with much else, the mqtt stuff seems unreliable.
It does seem like the RNode radios are a lot less mature but they seem to be aiming to be less of a toy.
Nomadnet it's really bad; it doesn't properly work with a 80x24 terminal and 16 colors.
Also, it uses tons of CPU on legacy machines. It needs some rework.
Not everyone it's a hipster with 256 or 32 bit colour terminals, shitty NerdFonts (nonstandards) and big displays.
And being written in Python3 makes it dog slow. Being rewritten in Go would get a few performance tweaks, (networking and GC there it's ideal), security and portability. But, please, no BubbleTea unless you can be sure it can work on a plain XTerm with 16 colors (I use Tango for readability, but 16 colors FFS). Keep 256 colours as an option.
https://news.ycombinator.com/newsguidelines.html
reply