I am personally convinced that a flat traffic shape will only dare attackers to cut links between parts of the network, effectively making an even larger traffic shape to corrilate with.
Today if play the cut links game, eventually a toggled link will expose the traffic you seek, because there's no fill between nodes that automatically takes its place. Your global monitor sees a respective signal slump among the nodes making up the subject path, each node distinguishable by time deltas. Such signal the adversary was probably clocking into it themselves for easier recognition anyway... fetch 1MB, fetch 1MB, fetch 1MB, fetch 1MB... oh noes. Tor's hidden services are total sitting ducks because of this. Same for likely all current overlay networks in production regardless of whatever service they provide... from traffic, messaging, storage, cryptocurrency, and so on. There are surely better links from the bib space, yet here are some concepts on generated buckets, retiming, how they can contain full time "empty" fill that yields to wheat demand on the line, traffic contracts, etc therein... https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm If all the nodes are independantly maintaining independant traffic contracts between their physical and/or logical peers, cut links won't do hardly as much impact if anything at all... A \ B + -----> M -----> { U V W X Y Z } C + D / If nodes ABCD on the left are trafficing through M cloud fanning out to the right mesh towards UVWXYZ, then adversary cutout of D is not visible beyond M if M makes up for D's packet slack on its left contract by continuing to emit the same amount as fill to fulfill its right contract. M could variously blackball A for non contractual suspect misbehaviour... weird rates, timing anomalies, uptimes, etc. M could signal BC that they can now renegotiate upwards with M since M now has more rate free on its left. If M is cut out, the left renegotiates with some L or N nodes via new northern or southern arc routes. The "shape" or "bitrate" of the contracts could be negotiated as need be, "flat" might not be necessary, so long as the contract is upheld and policed by all participants to it. Contracts could be one to one, one to many, many to many, physical next IP hop to hop, logical overlay address to address, multiplex, simplex, tunneled, shared, etc. And pertain to bitrates, timing, uptime, any sort of constraints, metadata, etc. This also makes Sybil's life more difficult... it must now own the full path or it will lose sight due to contracts with non Sybil nodes in the path who are also meshed and contracted out to other non Sybils around ot. Sybil must also uphold all its own contracts or get dropped by other nodes.
I am not convinced low latency systems can be immune to traffic shape corrilation and hence that being said
Copper, Fiber, Radio, etc.. so long as it's quality line rate hardware that can keep up with its advertised rate, their time to transfer data is dependant only on distance, not on how full the line is. Such network hardware is agnostic... fill, wheat... it all gets there in the same time. When people say "X latency network overlay", they're really referring to the cost of software processing their overlay design on their crappy stack of PC / Phone CPU hardware. And in their transport protocols running on the same... TCP, UDP, etc... all the way down the stack until it hits the real network hardware, which will either happily accept and ship the packet, or drop it. When people cry about "bandwidth", all they need to do in a fill model is allocate whatever bitrate to it they like and forget it. They're not going to get more bitrate from their ISP than they paid for, and they'll probably contract to the overlay under that so they can do other things with their line. And they're not going to get more wheat bytes across the overlay than a 100% wheat ratio (fill yields to wheat demand) within their contract to the overlay, even if they do disconnect from their byte transfer based ISP / Phone afterwards. Research would need done into routing models needed to transit traffic across the overlay. ie: TCP can readily jam more yet slower circuits through a full pipe, UDP mix gets dropped routed or reserved for. Raw IP becomes interesting. As a network HW project for defense in depth... If hardware makers would add line rate encryption and fill silicon to every physical port on every switch, router, and NIC... mandatory on by default per physical link... that would kill off a lot of vampires. An open IETF RFC spec for that would cost under $1 per port to integrate into existing silicon port fab worldwide, plus electricity to drive the port which would be estimated as part of the RFC process. Modular agility would not cost much more at scale. Assuming line rate hardware, there's no latency impact here either.
I think state actors are out of scope of the current threat model of llarp.
If any network application involves free speech, politics, money aka cryptocurrency, business, journalism, industry, messaging, personal affairs, data storage and transfer, basically anything at all... you can be absolutely certain that many State and Other Actors have a serious continuum of interest in it. Is it the responsibility of each application to develop their own solutions to the threat? No... probably not when many such apps ride on, aggregate muddily over, and depend on networks. All apps can contribute to the development of a diversity sound number of strongly resistant networks that they can then utilize and endorse as they would their own. Be they overlays on top of the internet, enhancements to the internet, or new guerrilla physical plant... That process of people contributing to original and ongoing development of new strong networks that are not susceptible to such Basic Bitch Adversaries as Global Vampires, is something more should consider. Same for likely figuring out how to get the deployment Social aspects right so you can circle the network wagons against Sybil.
This may or may not change.
Pity the fool who changes even one satoshi based on the worthless drivel herein :)