It's a relay network where you make lightning micropayments for small prepaid balances creating sessions with many relays, then your client uses these sessions to create multi-hop paths to reach services, which are advertised exit protocols that relays advertise.

If your message is just a broadcast, such as a bitcoin transaction, you can watch to confirm it got to the Bitcoin p2p network via other channels, but to enable privacy for clients, while the server is public, you send special types of messages that carry requests to these services, which I call "reply headers" and they contain a secret path to return, and the ciphers to encode the message on its way back to you.

The payload is already known to the exit anyway, and it knows how many hops the path back will be, but it does not know the keys that combine to create the set of symmetric encryption keys, or who will be receiving them and unwrapping their layer of the message beyond the first hop, and because the path is selected by the client, it is unlikely that an evil exit will also be in cahoots with more than one of the intermediary hops.

This creates "client side anonymity", which is to say, the exit is public, but the client is hidden. The relay operator can indeed be running the service themselves, on the same machine, or elsewhere, through the use of a firewall forward or similar.

Then, hidden services can advertise their existence via these client side private routes, and deliver a reply packet and intro to their chosen introducer, clients can request an introduction after receiving the ad for the introduction on the p2p gossip network, and deliver a request containing the client reply headers, to the introducer, and then back to the hidden service, who then can send a new reply header to the client using the client's routing header, and so on and so forth, as the server and the client can now negotiate their reply paths to each other independently of the introducer.

The hidden service will accept reuse of some prior reply headers in case of a transmission failure, when one of the hops in the reply header fails for some reason, but worst case the client uses another introducer to get a new connection established.

This is "bidirectional anonymity" or hidden services.

The last piece of it, is that it requires a connectionless p2p network transport, in order to minimise latency. I already have a protocol that uses libp2p and tcp, but this protocol adds tcp handshake delays every time a client constructs a path that the hops along the way are not "connected" to - whereas with a connectionless transport, it just delivers it and the next point in the path expects random messages from everywhere, and it doesn't maintain any state aside from the sessions that clients paid for.

This all will enable not just privacy, both client, and client AND server anonymity, it also allows relays to put a price on delivering messages to other network locations, such as their own stash of content, which can potentially be monetised to distribute the content, using Prisms or potentially even special redistribution licence fees, or other possible schemes that use cryptography to guarantee the payments are divvied up, and it would enable things like wifi internet access, while getting paid for it, and without becoming a man in the middle for malicious actors who won't profit if they have to pay for the traffic (eg spammers).

In other words, it could help the spam problem on nostr as well, protect bitcoin users from doxxing their location and where the private keys are located, and likewise for LN operators, whose location is a vulnerability for attacks for the same reason.

It's difficult to explain it any shorter than that, and I'm very very welcoming of anyone who can boil that down so it's understandable. I know that LN was completely opaque to me at first, and even after reading the WP, and many further articles, I only started to grasp it a bit.

Feel free to feed it to an AI, make a short version, join in and help bring funding to it.

It should be obvious that I'm not the person to write such marketing, I'm the one engineering it!

you asked me, what you get what you get

Microwaves resonate with metallic materials and water. When an object with capacitance, like a tree, is radiated, it discharges the electrons to earth. Just like how you see arcing from metallic objects inside a regular microwave (which is in the 500-1ghz range, somewhere about there), this is from the electrons escaping to get into the earthed body of the microwave.

If you fully encapsulate a metallic object in water, such as an egg wrapped in aluminium foil, it is safe to irradiate the water and the egg will not be directly heated, which causes some nasty reactions that smell really bad, and probably are not healthy.a I mean really bad... but the water soaks the radiation and cooks the egg via regular conduction. Any metallic object inside the body of water will be effectively shielded, as the water absorbs the thermal effect of the microwaves on the metal.

The most microwave-thermal metals are magnetic, ie, iron, cobalt, nickel. The heating effect of microwaves is from the magnetic induction in the material, which flips polarity in phase with the microwave frequencies involved.

Since there is small amounts of iron in most plants, large plants like trees would have enough magnetic induction to heat substantially above the temperature of water and catch fire.

Think of what happens when lightning hits a tree. The core of the tree explodes from heat and this builds up steam which then expands like an explosive.

There has been recorded cases of pressure cookers jamming and causing very substantial, non-fiery explosions that killed people and did a lot of damage. I think in some movie, tv shows and stories this has also appeared, and I know from when I was a kid putting cans of drink in microwaves was pretty messy.