__sy__

tbh im not sure what the value of this comment is here; also not a fan of talking down on other people's work (irrespective of how much you might dislike them). the most charitable explanation is that this was sarcasm?

the pursuit of perfection should not always require justification :)

i know it's maybe an unpopular thing to say to OEMs, but i do think some should adopt an open firmware stack to prevent post-discontinuation bricking and flex that somehow in their marketing. I'd buy that, especially for a larger appliance.

I had the exact same thing happen to me. Took CS107 at Stanford; cap stone project was a heap allocator. I ended up expanding it post course completion and published what I thought was a more clever approach. A few months later, I got a pretty stern email from our professor (shoutout to Julie Zelenski who was amazing) asking me to take it down :( Luckily i didn't get in trouble for this. kinda dumb on my part in retrospect.

i loved playing ShenzhenIO! So much so that i ended up buying and registering the domain of the fictitious company you were hired by in the game. That domain redirects to Seam now

This was my exact intuition. At 450 metric ton, we're three orders of magnitude away from what large container ships can do. It's a nice PoC but this is clearly just PR from DHL.

Air freight is also an odd comparison since it's usually time-sensitive and/or pricey ($100+ per pound).

i don't get all the hate in this thread. I literally was about to build this today, using my home server, tailscale, and some kind of web frontend. thanks for saving me time :)

So? I can make the exact same point about Google and other tech companies that endured years—decades sometimes—of eye-watering losses, only to eventually build enormously valuable businesses.

eh... I'm pretty sure I mentioned net income (which i think is pretty close to profit in some circles) but if we care about debt servicing, buybacks...etc, let's just look at cash flow. And there too, in Q3, they posted $1B+ for quarter.

I'm not sure I understand the point of your analogy with respect to wining/losing at a casino. If I follow it, you are effectively saying something akin to, when Google first became profitable, its achievements should have been completely dismissed because of a decade of prior losses. That's not how tech companies work. Most of the value creation is 5-10-20 years out. You bear enormous losses with the knowledge that returns compound and eventually render irrelevant prior years' losses.

FYI Uber reported a net income of $2.6B in Q3-2024 and $1.9B for 2023. That's no Google but that's also no "barely makes any money" territory, no?

Source: https://www.google.com/finance/quote/UBER:NYSE?hl=en

yeah but even then, it's still just a contract. The legal math behind Cisco's decision might just be to extend support just long enough to meet obligations and tolerate the risk that the remaining customers might sue.

Anyone here know customers affected? I'm wondering if Seam could build a LoRaWAN gateway and get these guys out of this mess.

yes at Seam we've seen a number of large deployment in multi-family buildings where you need to deploy devices (locks, thermostats, water leak sensors) but wiring the whole building with wifi isn't an option.

I don't know if it will count as DIY, but take a look at LEGIC and their devkit for this. We (seam) work with them and I recall seeing a couple of startups doing demo's of their UWB solution at their LEGIC Connect conference.

Sounds like a really interesting technical challenge.

Couple of issues I can see: (1) most devices out there would probably be mobile, so no NVIDIA/CUDA for you; (2) even with binding to, say, Apple Silicon, you might still be memory limited, i.e. can you fit the entire net on a single mobile GPU; (3) network latency?

might makes right

Nathan -- thanks for your work on this issue. I'm the ceo/co-founder at Seam (YC S20). We're building an API for IoT devices. I have many, many thoughts for you.

For Seam, we purchase, set up, and test many individual devices and systems in our lab in San Francisco. During the course of this work, we discover quite a few interesting things. When possible, we work directly with manufacturers on addressing the more concerning problems we find. We maintain an internal device database (partially available here https://www.seam.co/supported-devices-and-systems) where we keep track of our findings on devices we test & integrate. One area that I haven't seen addressed here is data-storage jurisdiction. imho, that might be one of the more concerning aspect.

happy to have a chat; my seam email is in my hn profile.

For the wetter sciences, the answer is somewhere in between. We usually have somewhat of an understanding of the prior theory. We then throw a lot of stuff at the wall…. Oh, this sticks? Eh, why? And then usually some more clever person will come up with reasons for why X works beyond what we already knew. A few years later, the field reaches some sort of consensus around one of the hypothesis.

Yeah pdf of report says that blocking is instant as of 2021. Also completely agree with the need for an active connection to do work. A lot of the software/hacker devs I knew have left China all together in the last 3-4 years. Inability to look up stuff reliably (even on working VPN providers) was one of the reasons cited by a few.

I’ve done so much experimentation with GFW pre pandemic while staying in China for extended period of times. I was always amazed at how quickly they would catch up on my shadowsocks, random ssh tunnels…etc. 48 hours top before I had to rotate IPs. This report seems to indicate this is now instant?

Fwiw My most reliable trick ended up piggie-backing off of a physical line going into Hong Kong from Shenzhen, and when roaming around China, using a vpn to get to that shenzhen gateway. As far as I can recall, that always worked. This led me to believe that most of the vpn traffic analysis (and blocking)was done at the edge of the GFW and not inside of it. Again, this could be outdated by now.

Happy to help. Have you tried Home Assistant as well? It's pretty good for personal use cases and such.

Thank You!

Many, yes. We have a page (https://www.seam.co/security-and-privacy) detailing this. One of the area of collaboration with manufacturers is helping them implement proper OAuth so that we never have to do this.

QIDI X-MAXⅡ. We mostly use it to print device test fixtures. For example, we have a fixture for thermostats, ie before you can test a smart thermostat, you have to trick it into thinking it is connected to an actual HVAC system. So we have a shape that we print out; it takes about 12 hours. We are not printing thousands of them, but we print often enough that PrintNanny would be useful. I sent it internally to our team. I will most likely email you directly.

Ohhh, this is such a great question! Also, it's quite clear you’ve seen these systems & their APIs up close, and can appreciate the mess… :)

So I’d say there are two approaches to doing these abstractions. We sort of support both and let the API client decide which way they want to roll.

The first approach consists of stripping away all the “stuff” that stands in the way of controlling a device. We basically just boil everything down to atomic operations on a single device. For example on SaltoKS locks, we let you create access codes directly on a door devices without having to worry about creating users, access groups, schedules…etc. Of course, we have to create these behind the scenes, but we don’t expose them to the API client. Instead we give you simple methods such seam.access_code.create(device_id…etc) that you can use against either an August device or one that’s part of a larger system such as SaltoKS.

The second approach consists of reintroducing the concept of users, access groups, and assigned credentials…etc and to lift the abstraction to entire systems vs just individual devices/nodes. You frankly need to do this if the site owner wants to continue to use their system in a sensible manner (e.g. see list of employees who badged in) or if you want to support more complex forms of credentials (e.g. Google/Apple Wallet).

I think the important thing to recognize is that, at the end of the day, whether you choose abstraction 1 or abstraction 2, these devices/systems all more or less do the same thing. The manufacturer may use slightly different terminology but you can create abstractions from that.

ps: btw for a long-time we made the mistake of spending too much time trying to nail the abstraction on every dimension imaginable. This included features of certain systems that no developers were asking us about. Now we just focus on solving what devs are asking for. That reduces the surface area of how much "stuff" we have to deal with when creating these API interfaces. This is a textbook example of going back to the YC basics of "talk to users" and "build something people want".

it's messy! but we've got all sorts of fun stuff + a 3D printer. We also have all these shelves around the office for storing devices. Here's one: https://imgur.com/a/UGhCIxg

We're in the SF Mission. You're more than welcome to swing by for lunch/coffee to check it out.

ps: PrintNanny looks awesome!