__sy__

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!

Early in the Seam journey, Dawn and I got a chance to speak with Jeff Lawson at Twilio. Jeff mentioned that exact dynamic, "the dev who's hacking on the weekend with Twilio and brings into work Monday morning" was a pretty powerful GTM force for them. But I don't think anyone would describe Twilio as open source. So being open-source doesn't appear to be a necessary condition for this dynamic to take place. What Jeff insisted on was the need for solid overlap between "i'm hacking with this API" and "i could use this for a business use case." That is, make the API product dead simple to get started with, and make sure it's easy to grasp how you could use this in a business context.

With respect to having an off-ramp by being open-source, I definitely agree that it does the psychological trick to convince a buyer. But in practically, most corporate-led open source projects are pretty hard to run end-to-end on your own infra. They also have limited outside contributors that really know how the stuff works.

With respect to Seam, I'd say being open-source wouldn't really move the needle for us in conversations with large enterprise customers. They're generally more interested in how much funding we have, how much runway that buys us, and how we're trending as far as building a sustainable business on which they will depend. Their tolerance for risk related to these questions is inversely proportional to their size. I suppose this is also why, in infrastructure sales, your next customer won't be significantly larger than the last one you closed.

Thanks! btw I don't know if you recall this, but very early on in Seam, you took the time to give us some advice. That was really kind and thoughtful. Thank You!

Thank You!

That's a pretty accurate take.

Amazon/Azure's IoT solutions are intended for device manufacturers who need to move data back-and-forth between devices and cloud infra. We don't play at all in this space, but a friend of ours, Jonathan Berry, has a company doing exactly that (https://golioth.io/). Many hardware manufacturers need help/tools to connect their devices and some very interesting companies will be built in that part of the stack.

Tuya is trickier to explain. It's... a lot of different things, really. It can be just a firmware + cloud if that's what you want (see countless devices on Alibaba with Tuya built-in). It can also be an entire white-labeled device that you can brand to whatever you'd like. They'll even give you a mobile app to go with it.

Seam is much higher up the stack for now. We mostly focus on device cloud integrations and occasionally a few on-prem systems.

She's pretty cool! She's former math teacher, then PhD in stats, reconverted to scientific computing programmer (CERN, Astronomy Labs...etc), and then eventually moved over to large system / mainframe stuff. She also spent a lot of time writing docs (she wrote some of the Seam API docs!) and has a knack for going deep on technical stuff. Lately she's been translating Aurélien Geron (https://github.com/ageron) Hands-On Machine Learning books into French.

Tbh, probably not. I'll give you a few thoughts for consideration.

Matter is a device-to-device protocol within a local Thread network. It's solid for getting one device to tell another device on the same Thread network to perform an action, retrieve data...etc. Since Matter is pretty consumer-centric, those devices are generally all contained within a home.

To remotely control those devices (i.e. what our API customers want to do), you sort of need a Thread border router to serve as an internet gateway. You can think of Google Home or Amazon Alexa as one of those. So in theory, you could get a reasonably standardized API to speak to devices via those smart home platforms, but you'll still have to deal with the fragmentation of various smart home platforms.

More problematic, you're still constrained by whatever APIs Google Home / Alexa...etc decide to make available and whatever device operations the Matter protocol also exposes. You could bypass the first problem by installing your own Matter-compatible device hub, but the goal of many of our API customers is to NOT have to deploy any new hardware.

Lastly, a lot of Seam customers need to integrate devices that are not covered by the Matter standard and probably never will (e.g. Access Control Systems).

context: I sat next to Grant Erickson and the Nest team that initially worked on Weave, which eventually became Thread. I still have close friends working on Matter implementation at Google/Amazon/Apple.

oh! I have many, many thoughts on the W3C WoT :)

At the start of Seam, we spent a lot of time reading those specs and absorbing some of the key ideas expressing in its core documents. As a result, you'll see a lot of W3C WoT terminology throughout our API and its docs ("capabilities", "events, properties, actions", "affordances"...etc). My mom (of all people!) is the one who pushed us to really spend time in those docs and understand where the designs were coming from.

I think ultimately we began diverging a bit from those specs when it came time to solve customer needs, such as device-category standardization, async handling of access codes...etc. But I have fond memories of going over those docs with my mom, highlighting certain passages of their docs on paper printouts, and debating the merits of different approaches.

Also feel free to ping me sy@seam.co if you guys need help with various integrations.

What if I told you that before Thread, the original comm protocol layer at Nest was called—wait for it—WEAVE!