there are LOTS AND LOTS of people using proxy, judging by support tickets, don't ask me why.
when I said technology, I meant a chip in the router that we only have one right now. Nobody knows if this gets popular in the future, so container is least risk. You want bigger NPKs again?
Support tickets will mostly tell you how many users have problems when using a particular feature ... it doesn't tell much (if anything at all) about how many users are using that feature without any problems.
And when talking about proxy in particular ... do you have any estimate about how many people are having issues with proxy related to what @pe1chl wrote a few posts back? And how many people are trying to (ab)use proxy for reverse-proxy?
Unless you have some accounting/stats app running on all routers sold phoning home with their metrics. And I certainly hope that's not the case with MT 
that’s not true, there are often just consultation questions, about how to better set up something, or what some parameter does. It does not mean those people have problems to use it.
No, what I am actually suggesting is to make things more modular again. So niche functionality can be installed by those who need it, and does not burden everyone else.
Make containers for that (or RouterOS packages where relevant). E.g. a container for a full-featured and well debugged DNS resolver. Preferably provide some integration between the RouterOS configuration interface and configuration information required inside a container. E.g. a container can pull some config info from the host similar to what is used on cloud virtual machines (cloud-init).
Yes, it’s the general idea. Containers will be more seemless to run and use, nearly like packages. Theoretically we could even have new RouterOS menus or settings become available if a certain container is installed
It would be very nice if you add all the containers required to run Home Assistant with Thread support to /app
I think there needs to be two additional containers:
... and it would also be nice for those using 3rd party Thread radios.
that’s the plan yes
I am really not excited about internet-connected IOT devices (Thread) running on the wild west of control protocols (Matter); we've seen some crazy stories like this Reddit thread.
Personally, I am in favor of Zigbee, which is mature, stable, and can continue working without any Internet- or WiFi connectivity. It's a great option for rentals, too, and much less effort to install than KNX.
The point of this is exactly the opposite. If you have your own IoT hub like in this case, nothing is internet connected. the hub is in your house. Use Home Assistant. That’s the whole idea. Get rid of the cloud
I guess the kind people at MikroTik could allow the user the select which protocol the radio runs, like the Home Assistant ZBT-1 and ZBT-2 which can be setup as either Zigbee or Thread.
In general, Matter (over Thread or WiFi) devices connect to the Internet - this was in fact the point of introducing an IP-based network for IOT devices.
Of course that can be blocked with configuration.
When using Home Assistant with Zigbee (or Z-Wave if you're into paying licensing fees) isolates devices from the Internet by design. Control (including remote control over zero trust or a VPN) is facilitated by Home Assistant (or Hubitat if you prefer), so there is no functional downside compared to Matter. A cynic might say Matter was only developed so the big tech (Amazon, Apple, Google, Samsung) companies can collect personal information about your usage.
but PLEASE not IN the home assistent only!
I run KNX with another solution since 10 years.
My cable backbone is KNX and Dali (for many lights) and just started to add DMX a bit.
My data backbone beside KNX is MQTT
Like to to enhance with Matter/Thread and love to see this coming. Because yes, KNX is expensive. But both protocols must be able to be used with other backends beside Home Assistent. HA ist good, but definitly not the only one!
Everything should be in open standards. Hence, I like to run Thread/Matter via MQTT. So, any backend can use and control, any consumer like InfluxDB/grafana can consume it, etc.
And with a neutral protocoll, like MQTT you are free to move to Open HAB or Node-Red or edomi or whatever is good in future for backend, frontend/visu, logic, etc.
Anyway: Defintly 1000% true what you said: Home Automation should never be run in a cloud, it must be run locally
and @TTT : WIth the MT solution for Matter/Thread I'd like to see a solution without the big techs. If it would be not avoidable I wouldn't install it and stick to other solutions. They will never get this data from me. But zigbee seems for me beyond the peak; I assume it will run out slowly and I don't want to start with it anymore.
That is absolutely not true. There is no technical reason for Matter or Thread devices to connect to any internet server or cloud. You are mixing up IP and “Internet”. I have lots of Matter accessories, they all work in the LAN only, and out of the box. None of them have attempted to connect anywhere else. Many of these devices do have special apps you can use if you want to, they sometimes offer some kind of cloud proxy. That is all optional, and you are free to never use their apps. The accessories themselves do not connect anywhere. Please don’t present speculation as a protocol requirement, this is a technical forum.
Well I would argue against this to a degree. Matter and Thread a local to you network and do not need any “cloud” services to work at all and are all local but in the matter specification there is a requirement for OTA and this is done by the device where it connects to internet via a matter bridge. I have starting to have more matter with thread devices at home now then Zigbee and I connect most to Homey Pro that currently do not allow for OTA, for this reason I also connect them all to Google Home that allows for OTA to work and now also my Ikea Dirigera could do the same.
So I would claim that matter and thread runs locally, if your matter bridge support this, but for OTA to work you need to have internet connectivity where the device will collect the files from a URL the manufacturer publish and control.
Yes, Matter does require OTA support, but it does not require cloud or Internet access. OTA in Matter is controller driven, not device driven. The device does not need to fetch firmware from a public URL or vendor server.
A Matter controller (or OTA provider) can host the firmware locally, and the device downloads it over the LAN. Home Assistant can provide these upgrades.
IMHO, Matter makes sense to harmonize control patterns for devices that naturally connect to the Internet, like smart TVs.
I suspect that typical IOT devices (e.g. light switches or presence sensors) will quite happily continue to evolve on Zigbee, particularly now that Zigbee is no longer limited to 2.4GHz, but allows a range of alternatives frequencies.
After watching https://m.youtube.com/watch?v=59g2IT5ZuNc few times is it sate to assume that:
In defense of the container-approach for Thread BR... MikroTik has been making a lot of improvement in their container support, see 7.22beta. It's not the complex ~12-step process shown for Pi-Hole container in docs anymore.
So imagine it be command like /app set thread-router disabled=no ... to enable a Thread border router. The benefit of this approach is it can be updated separate from RouterOS, or could use an alternative solution (in another container). Or, imporantly, if you don't care about Thread, there be no software loaded for it. So a lot of pluses in this approach.
My question is what device-mode settings will be used on the hAPbe3? In the "features-as-containers" scheme dealing with the annoying /system/device-mode update container=yes really makes provisioning hard, and adds extra step for end-users.
And as suggestion for a YouTube video, TikCribs: Normis' house: