If they were to put a few GB of memory on these terminal dish things, and (say) a few PB on each satellite, they could have satellites broadcast a cache of what a lot of people in the service area are watching, saving a lot of up-and-down traffic. Broadcast, so all the terminals are listening to identically the same packets arriving.
The flagship use for such a capability would be for World Cup games, where not much actual storage would be involved, because almost everybody is interested only in the latest few seconds of the game.
It looks like launches of Starlink satellites are volume-limited, not mass-limited, so adding a few kg to each for the PB or so of SSDs would be cheap (albeit x17k for that many satellites). But they are going to be bandwidth-limited pretty soon, and eliminating a whole bunch of high-traffic up-and-down streams will be worth a lot.
I think right now the on-board lasers in the last one (or two?) launches just point to the satellite immediately in front and behind in the same orbit. (Please correct me if I am mistaken.) Probably soon they will have extra lasers on board that can track satellites in other orbits, with galvanomically controlled mirrors, to be able to route traffic and, usefully, share content of on-board SSDs, multiplying the available cache capability by splitting it among subsets of the satellites.
Of course it will need app-level adaptations to be able to take advantage of this sort of caching, but it needn't be complex, mostly like a redirect to a proxy running in the dish. Strictly speaking, RAM on the dish hardware is not strictly necessary, given custom software running in the clients, but everything gets a lot easier if the client software is maximally simple.
The flagship use for such a capability would be for World Cup games, where not much actual storage would be involved, because almost everybody is interested only in the latest few seconds of the game.
It looks like launches of Starlink satellites are volume-limited, not mass-limited, so adding a few kg to each for the PB or so of SSDs would be cheap (albeit x17k for that many satellites). But they are going to be bandwidth-limited pretty soon, and eliminating a whole bunch of high-traffic up-and-down streams will be worth a lot.
I think right now the on-board lasers in the last one (or two?) launches just point to the satellite immediately in front and behind in the same orbit. (Please correct me if I am mistaken.) Probably soon they will have extra lasers on board that can track satellites in other orbits, with galvanomically controlled mirrors, to be able to route traffic and, usefully, share content of on-board SSDs, multiplying the available cache capability by splitting it among subsets of the satellites.
Of course it will need app-level adaptations to be able to take advantage of this sort of caching, but it needn't be complex, mostly like a redirect to a proxy running in the dish. Strictly speaking, RAM on the dish hardware is not strictly necessary, given custom software running in the clients, but everything gets a lot easier if the client software is maximally simple.