This is apropos of nothing really, but: do you remember that phrase "reply guy" that was popular on twitter a while ago? The idea of that phrase as an insult is so revealing about the dynamic of that type of social media.
Going back 20 years, discussion on the internet was on fora like IRC (not much even then), usenet (already mostly died out by then), mailing lists, and especially, web forums (like bitcointalk). Everything had the commonality that there was just a linear flow of messages (chatrooms) or a linear flow of threads, with threads existing so you could keep track of a particular conversation; but in that conversation, time ordering was still preserved (except for the batshit insane people who came up with the idea of time-reversed conversations in fora, but they were not common thankfully).
The whole idea of *quote*-tweeting (or quote-noting here) is kind of dodgy from the point of view of polite social interaction. Even so, it's very tempting, for very reasonable reasons: conversations here on amethyst and perhaps on other clients, are quite, quite hard to read properly, and replies are somehow "lower status" - I think? - in terms of discoverability. On Twitter as far as I know (I stopped using it many years ago, but continued reading often), it became a big habit for people with more clout to "overwrite" a message from the less cloutful by quote-tweeting them to give their own version of the story. Using replies is I guess an indicator of lower social status ("reply guy").
If this ramble has a point, it's this: can our nostr clients make replies (a) readable in nested threads better and (b) have the same "status" somehow as quotes so that people don't gravitate to this mode of conversation?.
waxwing
npub1vadc...nuu7
Bitcoin, cryptography, Joinmarket etc.
What if the next big war in bitcoin is not *exactly* op_return or inscriptions or even just "spam", but, related: the "confiscation war" which will be about whether we can ever make outputs unspendable: sub 1000 sat outputs that bloated the utxo set so much at one extreme, and above 10btc outputs with exposed pubkeys from 10++ years ago, at the other end. There are a lot of influential voices advocating for things like this.
Credit to Robin Linus in that in this thread:
his second message imagines an ingenious way to *not* confiscate. Thread is most definitely worth a detailed read.

Delving Bitcoin
Dust Expiry: Clean the UTXO set from spam
Age-Based Expiration For Dust Outputs Dust Expiry is a soft-fork proposal which effectively cleans the UTXO set of any spammer’s spam who is not ...
As early as 2016-17 I remember having this rather fantastical "vision" of Bitcoin as just a kind of "beacon" - just 32 bytes every 10 minutes, and some unimaginably huge number of financial systems "hooking" off that, principally using zero knowledge proof techniques to make it so that, magically, just that one 32 byte string every short while would be enough to ensure correctness of everyone's transactions.
This fantastical way of looking at things is a cousin of Todd's "client side validation" idea. What remains on chain is just essentially random junk, to an outside observer, but to those engaged in financial transactions using it, it ensures fairness. This addresses scalability (because all the bulk of computation, storage and interactive bandwidth usage remains "offside"), addresses privacy.
Recent handwringing about data-on-chain illustrates one side of this vision is really, really important: the idea that *somehow* we won't need to store megabytes and megabytes of data per 10 minutes in order to have fully trustless validation on our own sovereign node, that we have the "right" Bitcoin sitting on it. Recent work on zkSTARK based initial-block-download (see: zeroSync) is a push in that direction. Imagine you started from scratch, were given the genesis block from Jan -09 and then the latest chainstate (admittedly this is currently in the GBs but, anyway!), and then a proof - and what it proves is that the entire set of state transitions from the start to the end, followed the correct consensus rules all the way.
If that gets properly cleaned up and actually works, it will eliminate the idea of storing data *in the blockchain*, but not eliminate the idea of storing data *in the utxo set* (or "chainstate") - unless zk techniques take another leap forward into the fantasy i mentioned at the start - that you need no more than 32 bytes to represent global state somehow (merkle trees, especially sparse ones, gives a flavor).
To put it in much shorter terms, we already *kinda* know how to compress out all the history (it's developing science). What's left is to compress out all the present. Then all the issues of scalability, privacy and "pollution" (I reject even the concept, but if it goes away, who cares) of the state of Bitcoin.
To reiterate: 90% fantasy, for today - but I think this fantasy should maybe inform your thinking around what Bitcoin will become.
I haven't finished, but, recommended read (the pdf) for those interested in the details of the response to the quantum potential threat to bitcoin:

Delving Bitcoin
Bitcoin and Quantum Computing
We’ve just released a new report in collaboration with @deadmanoz on the potential impact of quantum computing on Bitcoin and possible paths forw...