FerdSlav

As someone that is just attempting to get a better understanding of this aspect of a tech stack, when you say many apps don’t need Auth0 what is the actual alternative for the whole user authentication story?

I ended up going down the rabbit hole looking into this practice and discovered companies exist advertising the ability to get any US citizens employment/compensation history for a nominal fee. An example of one such company: https://www.truework.com/

> Matter/thread is nothing like zigbee, except the MAC layer is the same.

Matter actually uses an iteration of the Zigbee device model - from an application level they are actually somewhat similar

> I don't know why you think your zigbee devices will be upgradeable to thread - that strikes me as quite unlikely

Most Zigbee radios are dual Zigbee/Thread since both protocols are build on 802.15.4. I suspect that the limitation is going to be on manufacturers rather than hardware limitations

The official Matter SDK has examples targeting the ESP32, along with other low-cost chipsets: https://github.com/project-chip/connectedhomeip/tree/master/...

Thread and Zigbee are entirely distinct protocols; Matter does not use Zigbee in any way, at any layer of the stack, with the exception of some influence on the high-layer device/data modeling

Thread is an IPv6 bearing mesh network; and if you have a border router that has the appropriate IP routing rules, and your firewall allows it, your Nanoleaf bulbs can most certainly reach out to the internet (granted, they only have the concept of IPv6, so a majority of the internet is inaccessible if only because it is IPv4)

Stating that Thread is a rebranding of Zigbee is incorrect. Both are based on 802.15.4 for their physical layer but the two are entirely separate and managed by different standards bodies (Zigbee under the Zigbee Alliance, now CSA - Thread under the Thread Group). Where some confusion may come is that Matter is now also under the CSA (just like Zigbee).

I have been at a few companies now that seem to have drank the "server-driven UI" punch and were actively architecting their mobile applications to be entirely dependent upon a stable connection to their backend to display anything beyond a splash screen. The argument for the architecture always falls along the lines of "enabling rapid deployment" and have had systems architects directly convey that they did not cache any data as it could result in displaying outdated or undesired content.

Personally, I have come to despise this architecture as, in my experience, it provides marginal gains in process for a developer while increasing technical complexity, backend scale/dependence, and a sub-optimal user experience.

A few years back I got frustrated with the unreliability and cost of my home printer and a friend suggested I pick up an HP LaserJet 4000N - a printer that came out in the late 90’s. After a bit of convincing I found one that was being thrown out and lugged the 50lb+ piece of yellowed 90’s plastic home. My friend provided a large jug of official HP toner, showed me how to fill the reservoir, and since that day I have not had to refill the toner or do any other maintenance - it has honestly been one of the most reliable and carefree pieces of my home network for 5+ years at this point.

The 4000N is also a modular design with the ability to add attachments for things such as extra paper trays, auto-staplers, auto-folders, or networking cards; if that is your thing. I’ve have mine connected to my home network and have never needed an explicit driver or had issues using the printer from any of the major operating systems.

If you are someone that only needs to print in black and white, and has the space, it may be worth checking out - I assume they can still be found for cheap/free as well

I’ve read through the GitHub repo and your message here and was surprised to see this is an 802.15.4 IPv6 mesh yet I see no mention or comparison to Thread - for which this project appears to be heavily influenced by or copy of.

I also have significant knowledge and experience of the current IoT space (specifically focused on the consumer market) and while standardizing these lower layers of the OSI stack is important it will not solve your interoperability concerns. Secure IP based IoT device connectivity is largely a solved problem - the currently _unsolved_ problem blocking interoperability is mass standardization and adoption of an interaction, device, and data model. Zigbee, Z-Wave, HomeKit, Weave, etc. all provide different and unique ways to describe the ontology and capabilities of a “thing” and it is at that layer that mass adoption is needed. Imagine if every PC manufacturer used a different variant of HTTP, REST, and JSON - that is the state of the consumer IoT market today.

The new hot thing in this space is Matter, which does appear to have commitment from the major consumer players for mass adoption. Obviously it is too early to say if this will drive the mass standardization and interoperability you mention, but personally speaking I am very optimistic and excited :)

Curious how something such as this is actually implemented. Is there a feed that you are subscribing to? Are you consistently polling posts looking for changes? Or is it some third option?

Have a couple LightSail instances that all went offline around the time that the homepage did and still cannot connect. Everything in the dashboard says they are healthy and online but all attempts to access them (either just access the webpage or SSH) timeout.

Edit: SSH access has been restored if using their web client, everything else still times out

an async runtime inherently requires knowledge of the underlying system which Rust remains agnostic to. Rust can be written to target bare-metal (where no OS exists) to WASM and everything in between. If a runtime was added to the language itself you would inherently limit the flexibility of the platforms by which it could target.

I've done 400km in a single day (19hr with stops), all gravel, single track, and forest trails. This ride always ends up being almost more mentally challenging than physically challenging. Even with the differing route conditions, I can't imaging having to do this ride but averaging over 2x as fast of a pace.

PAF can be thought of as basically a broadcast message to any and all WiFi devices in the area, regardless of if they are connected to the same access point or IP network. In the case of someone like Amazon, a device when it is first powered on can broadcast out looking for other Amazon WiFi devices in the home and receive the credentials from them.

It's a bit of an open secret at this point that Amazon is also using 802.11 PAF (Public Action Frames) to aid in the magic "unbox an amazon device and it immediately is online". Would admittedly be interesting to have this side of the Echo devices also look at as the paper seems to not mention this portion of the OOB experience

This appears to just be an attempt to masquerade the benefits of significant figures without considerations for the downsides https://en.wikipedia.org/wiki/Significant_figures

I personally have found that one of Discords major shortcomings is the lack of support for threaded message chains. For those times when you may have 2+ parallel conversations in a channel you end up dramatically reducing the ability to effectively communicate.

If this really worked and made such a drastic improvement why not get one of the plethora of bike power meters available on the market and show the needed effort to maintain a set speed with this wheel and without?

Also, if this really worked as described it shouldn't matter if it's on the front, back, or both wheels. So why not show that?

I think personally this is one of the biggest details that is being entirely overlooked. In past keynotes Apple has mentioned they are actively working with other companies on the new Project Connected Home Over IP working group[1], which according to the limited marketing material available, seems to indicate will at least partially operate over Thread.

[1]: https://www.connectedhomeip.com/