there’s little reason to depend on external services when the data is flowing through your own gateway
The idea behind the community network is that you share your gateway with other users and other users share their gateways with you. Recommending people to implement their own ‘network’ is not in the spirit of TTN and takes resources away from the community network.
That’s not actually what I recommended; I suggested extracting and decoding your own data directly, without relying on TTN - I did not mention disconnecting the gateway from TTN.
However, as long as the architecture doesn’t make it easy to do this in parallel, flakiness in the TTN infrastructure does indeed point people who have real needs towards entirely private setups.
Long range, it makes a lot of sense to handle (at least in the sense of having backup decoding for) your own data locally, while still exchanging data with the servers to support other’s sensors in your coverage area and your sensors in others’ coverage areas.
For the decoding side this is fairly straightforward, what is missing is a way to arbitrate a gateway’s single transmitter between distinct network servers - ie, your gateway might be in the best position to respond to someone else’s TTN node, but if it were busy transmitting to a node TTN didn’t know about, then someone else’s gateway that was 2nd best for received signal would actually be the best choice for that particular transmission.
But ideally, a node should be designed to keep feeding data even if they don’t receive any downlink for a day or two, so a decode-only scheme (which causes no transmitter usage contention) is a viable fallback compared to having complete outages.