The Aerial Framework has been designed from the ground up to meet the needs of 3GPP Radio Access Networks — signal processing workloads with microsecond latency requirements. It is a single platform that unites research, testbeds, and production deployments to solve development challenges for real-time applications.
Use cases: Signal processing applications with strict latency requirements
Audience: RAN system engineers, signal processing specialists, AI researchers
Built with: DOCA, DPDK, TensorRT, Python, JAX, PyTorch, C++, CUDA, and more
Doesn‘t tailscale force you to bring your own SSO / IdP already?
So it‘s not part of what Tailscale brings, it just adds another layer of indirection between the SSO / IdP you have already and the app, plus requires some custom library integration work, further enhancing lock-in.
Do you have any information about the privacy achievable by Meshtastic?
From a quick glance it looks like it‘s using static NodeIDs derived from the Bluetooth MAC address in the always unencrypted Packet Header.
So not only can you sniff these messages from far away at greatly simplified complexity when comparing to cellular communication, but also tie it to the hardware that you carry with you.
Mesh networks sure have its uses, but I‘d be wary of their offered privacy in the presence of adversaries you could be facing at protests!
For the next few years it's fine. Functionally the feds just don't have the infrastructure to care about Meshtastic. In a decade maybe that'll change but two decades in the best they can do against drones is receive the ID DJI manufactured ones voluntarily broadcast and lookup the owner if they registered it correctly.
They're far dumber than most people give them credit, unless you off a rich guy they just don't have the resources to even think about penetrating anything but cell networks.
The encryption is pretty good, they're not likely to break it any time soon. The device MACs are whatever, unless you go to protests then go wandering around an urban area with the same radios for an extended period of time they're not going to do shit about it. They would have to geolocate from the RF emission and that's difficult to do to an accuracy necessary to uniquely identify you. Further, LoRa is still a bit of a pain to work with outside of using vendor chips which don't have non-cooperative DF capability so we're in the realm of expensive custom solutions from an RF shop which is far more money than the feds are willing to spend to dragnet a couple people.
Often they rely heavily on GPS for time and frequency synchronization (think 5G TDD, where all operators need to be aligned in time or they jam eatch other‘s uplink). The GPS antenna is also often quite visible from the outside of a base station.
Still, what‘s also possible is to use PTP as backup (e.g., over eCPRI) and use the fiber / microwave backhaul to some master clock with, say, a ribidium time source as a backup, so I think it‘s not entirely unreasonable to assume that cell phone signals will remain available in the presence of a GPS outage.
> But one overlooked use case of the technology is (talking head) video compression.
> On a spectrum of model architectures, it achieves higher compression efficiency at the cost of model complexity. Indeed, the full LivePortrait model has 130m parameters compared to DCVC’s 20 million. While that’s tiny compared to LLMs, it currently requires an Nvidia RTX 4090 to run it in real time (in addition to parameters, a large culprit is using expensive warping operations). That means deploying to edge runtimes such as Apple Neural Engine is still quite a ways ahead.
It’s very cool that this is possible, but the compression use case is indeed .. a bit far fetched. A insanely large model requiring the most expensive consumer GPU to run on both ends and at the same time being limited in bandwidth so much (22kbps) is a _very_ limited scenario.
One cool use would be communication in space - where it's feasible that both sides would have access to high-end compute units but have a very limited bandwidth between each other.
Increasingly mobile networks are like this. There are all kinds of bandwidth issues, especially when customers are subject to metered pricing for data.
Staying in contact with someone for hours on metered mobile internet connection comes to mind. Low bandwidth translates to low total data volume over time. If I could be video chatting on one of those free internet SIM cards that's a breakthrough.
One use case might be if you have limited bandwidth, perhaps only a voice call, and want to join a video conference. I could imagine dialling in to a conference with a virtual face as an improvement over no video at all.
130m parameters isn’t insanely large, even for smartphone memory. The high GPU usage is a barrier at the moment, but I wouldn’t put it past Apple to have 4090-level GPU performance in an iPhone before 2030.
The trade-off may not be worth it today, but the processing power we can expect in the coming years will make this accessible to ordinary consumers. When your laptop or phone or AR headset has the processing power to run these models, it will make more efficient use of limited bandwidth, even if more bandwidth is available. I don't think available bandwidth will scale at the same rate as processing power, but even if it does, the picture be that much more realistic.
I feel like there are so many pitfalls when designing this - is there something standard and trusted (would TLS work?) that you could build your application on top of?
I assume there's TLS in the server connection already, but the encryption here is to make the communication unavailable to the server for decryption, so "bare" TLS does not solve the problem.
With TLS you need pubkeys you can trust (the certificate authority hierarchy provides that trust for the open Internet) or you're vulnerable to MITM. You could potentially share pubkeys using a similar out-of-band mechanism to that currently used for symmetric key distriubtion, and tunnel that TLS connection through the server's shared comms channel. That would work OK for two parties, but it becomes significantly more cumbersome if you want three or more, since each TLS session is a pairwise key exchange. Notably, however, this would not transit secret keys through server-controlled web pages where they could be available to Javascript. Something like Noise [0] might also be useful for a similar pubkey model.
Unfortunately, this kind of cryptography engineering is hard. Key distribution and exchange is hard. There isn't much of a way around learning the underlying material well enough to find this sort of issue yourself, but misuse-resistant libraries can help. Google's Tink [1] is misuse-resistant and provides a handful of blessed ways to do things such as key generation, but I'm not sure if it's suitable outside of cloud deployments with KMS solutions. nacl/secretbox handles straight encryption/decryption with sound primitives, but it still requires a correct means of key generation [2] and distribution.
Agree. When people hear the adage "don't roll your own crypto", they often think it refers to crypto primitives only. In reality, it's also hard to design a secure crypto protocol, even if the underlying crypto primitives are secure.
I guess TLS has a dependency on the public key infrastructure (eg Let's Encrypt, or whoever issues wifey accepted certs). Which makes end to end encryption between users harder (most of this stuff is intended for server auth and encryption)?
But otherwise big +1 not to reimplement crypto when the are alternatives. Another option for secret key stuff might be ssh?
There is no requirement to use TLS with webPKI if you are making your own application (not the browser), you can use TLS with custom certificate mangement.
You still need to figure out how you handle trust and key authentication somehow, but that is true of all cryptographic protocols.
It would be hard to do end-to-end TLS (where the server proxies the raw connection) because
(a) you can't share one TLS connection to the host between multiple clients; if you wanted multi-client support while preserving end-to-end TLS, the host would need to maintain a TLS connection with each client and waste bandwidth re-uploading the same image
(b) there is no client software requirement, so you would have to do the TLS decryption clientside in the browser (maybe via WASM) unless you're OK with having viewers download software
You need to install the XDNA and XRT drivers, then install the Vitis AI compiler (needs a free license) and then you can compile your own custom kernels using mlir-aie using plain old C++. They give you an easy to use API for vectorization. The hardest part is organizing the data transfer through the tiles.
In principle this can accelerate anything you can run on a normal CPU as long as it is a streaming workload i.e. single pass or your entire data fits in the memory tiles.
The vector registers are at least 1024 bit wide and you get 32 tiles/cores.
But that‘s not what happened according to the article.
> The problem is, there were no empty seats on the flight. So when he emerged from the lavatory and the plane began taxiing, flight attendants realized something was wrong, and the plane returned to the gate.
Use cases: Signal processing applications with strict latency requirements Audience: RAN system engineers, signal processing specialists, AI researchers Built with: DOCA, DPDK, TensorRT, Python, JAX, PyTorch, C++, CUDA, and more