Nostr is built around a decentralized system where messages (or "notes") are broadcast to relays—servers that store and distribute these notes. When you post a message via Amethyst, it’s sent as an event with a unique ID tied to your public key.
If you edit that message in Amethyst, it creates a new event with the updated content, but the original event isn’t deleted or overwritten. Instead, both versions can persist on the relays.
Amethyst supports editing functionality and can recognize these updated events, displaying the latest version to its users. However, not all Nostr clients implement this feature in the same way—or at all.
Many clients are designed to simply show the first event they receive with a given ID and don’t check for subsequent updates. Since the Nostr protocol doesn’t enforce a universal "edit" mechanism (like replacing the original event), it’s up to each client to decide how to handle these cases.
If a client doesn’t support displaying edited versions or isn’t programmed to fetch the latest event for a given note, it will stick with the original version it first saw.
Additionally, relays play a role. Information on Nostr is assumed to be permanent once posted, and relays don’t guarantee that they’ll prioritize or even store the edited version over the original. If another client is connected to a relay that only has the first version—or doesn’t sync the newer edit—it won’t see the change.
In short, the reason other clients show only the unedited version is a combination of inconsistent edit support across clients and the decentralized, persistent nature of Nostr’s relay system. Amethyst can show your edits, but unless other clients actively look for and prioritize those updates, they’ll display what they first received.