That "garbage" often includes meta data that should be signed by an nsec. The issue is that most people rush through that first step on Amber when adding a connection; if you spend an extra 10 seconds reviewing permissions, then this issue doesn't occur (until the app adds more permissions that weren't approved during setup)
Discussion
its not tho, its a bunch of app data that is meaningless to any user, like machine encoded last clicked this page timestamps and unread/read notifications .. it is not standardized at all and it all pops up under "nip44 encrypt/decrypt"
and if you reject any of them, the apps just spam the requests and break, they require you to blanket approve all of it.
there needs to be some API to tell amber what permission set the app needs, with reason texts for each of them, so you can approve them in one go. this should be a client side thing, also, but if amber had a batching API call to set permissions in one hit that would help a lot too. and app devs should think carefully before they add new ones.
actions it does are both signing events and as well for some, encrypting.
there is small things that would improve on amber side, but really, most of it is client devs responsibility.
its an area of no nips.. just encrypt/decrypt gobbltygook 10,000 times a second. 🦖 i only use this statistic cause thats what vitor said amethyst does.
yeah, there's a lot of areas that the nips are lagging way behind what is actually being used. the "gobbledygook" is regular JSON data. it should be simple to define a thing where there is an app identifier as the keys in the object and then that contains arbitrary json. then the apps wouldn't be clobbering each other's format.
it really needs a nip to at least explain this. but client devs are a bit dim and none of them have even thought for a moment about cross-client interop with this feature.
probably it would be a lot better if the events were addressable and the label was the app name.
i'm not gonna waste my time trying to explain this to either teh nip guardians or the app devs tho. when i make a client, i will define a protocol that is interoperable and then just sorta subtly POINT IT OUT a few times. ideally, i make several clients and then i make it so they interop to demonstrate the principle.
also, what is up with freaking out about signers signing and encrypting events anyway? a) nobody else can read it and b) outside the timing of the signals it leaks no information except maybe the app being used. the combined single event encrypted with object with multiple tags for different apps avoids that metadata leak.
i don't get what the paranoia is about encrypted events. sure, non-encrypted events being signed willy nilly ok, but if the event is encrypted, it's already one step lower on the risk level.