If you are using NIP 1090 (kind 1010) edits, then most people are only seeing the very first event... they are not seeing these edits that you think you have made.

In order for the rest of us to implement this (if we do a local database) we have to

1) Fetch kind 1010 events
2) Build relationships between them and kind 1 events they refer to
3) When rendering a kind 1 event that has 1010 version data, render the latest of the 1010 versions (maybe indicate the note was edited)
4) When someone replies, the reply needs to 'e' tag the 1010 version event, not the original kind-1 event, making them harder to find/associate (now 2 levels of indirection from the original note).  Otherwise if they 'e' tag the original note, people can pull off "edit scams" where they make someone reply to one thing, but people think they replied to something else.
5) Show replies that are not to the latest 1010 as having a hidden ancestory
6) Make some way of rendering the hidden previous-version that was actually replied to (this is actually a very difficult UI/UX problem).

This is complex enough that the original problem (people aren't seeing your edits) will plague us all for at least a year, maybe 3, while clients "upgrade" to the more complex protocol.

It is reasonable for reasonable intelligent people to have different opinions about this state of affairs.  Some want to forge ahead with this.  Others think the disruption and complexity may be a net negative for the nostr protocol.