A "keysend" is a special kind of payment in lightning that lets you send a payment without an invoice.

Normally, a receiver must generate a bolt11 invoice prior to receiving a payment.

Keysend payments allow senders to "spontaneously" pay over lightning (to a receiver's identity pubkey) without an invoice.

Here's a more detailed explanation... courtesy of https://chat.bitcoinsearch.xyz/?author=holocat&question=What%27s%2520a%2520keysend%2520payment%2520in%2520lightning%253F:

A keysend payment in the Lightning Network is a type of transaction that allows for spontaneous payments without needing an invoice from the recipient. In traditional HTLC (Hash Time-Locked Contract) transactions, the receiver generates an invoice with a payment hash, and upon payment by the sender, the receiver reveals a secret preimage to claim the funds. With keysend, this process is inverted—the sender generates the preimage and includes it within the onion payload sent to the receiver. The receiver then uses this preimage, which must match the payment hash of the HTLC, to settle the payment.

Keysend payments use a custom record type (5482373484) to encode a 32-byte preimage value. This means that payments can be made directly to a recipient identified by their public key without the need for an invoice. This feature enables new use cases such as tipping or donations where obtaining an invoice might not be practical or possible.

However, there are drawbacks to keysend payments. For example, the payee cannot specify their preferred minimum CLTV expiry, which may lead to security issues or payment failures. Moreover, since no invoice is issued, there is a loss of proof-of-payment capability, which is typically provided by the invoice signature and preimage in regular Lightning payments.

Furthermore, keysend is expected to be deprecated in favor of newer spontaneous payment solutions like Offers or AMP (Atomic Multi-Path Payments) because these provide better security features and user experience.

In summary, keysend enables spontaneous, invoice-less payments on the Lightning Network, but it comes with certain limitations and is likely to be replaced by more advanced protocols in the future.

What is Keysend?
To make a Lightning payment, the payee needs to generate a BOLT 11 invoice and then send it to the payer by email, displaying it as a QR code or other means. You can think of this invoice as a Bitcoin address in the Bitcoin network, even though it works substantially differently. The main difficulty is when the receiver can’t interact with the payer (e.g., because he doesn’t know who/when he’s getting paid, like anonymous donations, or when the receiver doesn’t have a channel to speak with the payer). Another is if the payee needs to accept reoccurring payments with varying amounts. This is where Lightning Keysend shines. Keysend removes the need for invoices when making payments. Instead, the receiver of the funds shares their node ID (a public key) once, and then the payer can pay any amount at any time in the future. Keysend doesn’t require changes to the network, but the receiving node needs to have Keysend support enabled.

Basically this link will show you how to send sats across the Lightning Network without an invoice using Keysend!

Keysend (no invoice)Keysend (no invoice)

https://guide.bolt.fun/guide/invoices/keysend

Key Sending on Lightning with Alex BosworthKey Sending on Lightning with Alex Bosworth

Key Send is a proposed feature for the Lightning Network which would allow payers to pay receivers over the Lightning Network, without needing an invoice from the receiver.

Interestingly, the original client for Bitcoin had a Pay to IP feature — the client would connect to an IP and ask for a pubkey to send funds to.

This feature was removed quite early as Satoshi did not want to implement network protocol encryption to protect against mitm at the time. It also went against the “not online to receive” pattern of PayToPubkey(hash).
The feature wasn’t missed.

This is similar to IPIP transfers done internally by banks. I suspect this is where the idea came from.

Keysends in LN behave similarly to Pay to IP. Instead they contact the node directly and exchanges material to facilitate the payment. As LN is always online, this pattern suits spontaneous payments where the peer is alive and can negotiate cryptographic material.