sandwich on Nostr: I generally agree with your sentiment, there's a ton of protocol issues, too many to ...

I generally agree with your sentiment, there's a ton of protocol issues, too many to list. Many of them require breaking nostr to solve or require a "hard fork," however, I don't think this particular change would.

! WARNING: long response

I disagree that users are not impacted by kind 1. Mobile users are affected. I just ran an outbox req and for every root kind 1 note i received, there were 3.2 kind 1 replies. It affects consumption of limited data plans, battery life, websocket management efficiency and consequently usability.

For clients, building a feed is complicated by kind 1 replies. Negentropy helps but only a little bit. Using arbitrary numbers here's an example: You want 1000 kind 1 notes and you have to increment a cursor until you hit 1000 kind 1 notes. The client has to pull 4200 (using number cited above) notes to get 1000 of them. This adds so many layers of complexity to an already complex problem. If there's a hell-thread a client might find 1 root note every 500 replies per incremented cursor. The only real solution to this is a cache server.

If the client supports many kinds, they may also be supporting kind 1111 already. Depending on client architecture, this could double the number of execution paths for every path that deals with replies, and since kind 1 have technical hurdles and caveats, there might be monkey-patches applied to each path.

We can't quantify the developer hours wasted on this issue, but I feel confident in saying it's not negligible, and likely a pretty large number.

Could there not be a progressive rollout?

0. n Clients flag support for a clean break, "NIP-22 day" (or something more catchy) is scheduled one month after a threshold is crossed.
1. n Clients implement publishing and aggregating 1111 kinds as replies, no longer publish kind 1's.
2. They continue to support aggregating kind 1 replies for say, a year so stragglers can catch up.
3. Someone makes a dashboard that shows the numbers; ideally we see kind 1 replies go away (a NIP language change would result in people's agents implementing things according to new patterns)
4. Clients decide to drop support on their own schedule based on the stats.

Does it produce some UX issues? Yes. Yes it does.

1. During transition, kind 1111 clients that interact with kind 1 replies could cause fragmented threads
2. Something else I am missing?

Could it also not be possible to "migrate?" Competent relay operators like yourself or clients could offer "reply migration" to their users who care about this. The bots won't care, we'll even reduce spam for a week, and I doubt the 95% of users that left won't remember their old replies or threads.

1. Transpose npub kind 1 replies to kind 22
2. Republish the original kind 1 note with a reference to the new kind 22 note, retaining original timestamp.

That would provide an escape hatch for the original kind 1 conversation chain/

The net benefit moving forward is substantial, the negative impact is tiny comparatively, especially since the user stats are presently very low. The data still exists, it's not deleted. There is already a form of "bit rot" most users as their old notes are truncated, particularly those of public relays (the vast majority). In a year or so most of conversations start to degrade as relay hints rot and NIP-65s drift.