It does mean base64 images anywhere in the app. If they show up it will render.
Discussion
What are the use cases?
This encourages incorporation, hence the creation of really heavy events; I doubt if this is a good thing.
It's better than just showing a bunch of characters.
Maybe a healthier solution could be to hide the bunch of characters and write "not compliant data blob". This would discourage this practice, if you agree that it is dangerous.
I don't agree it's dangerous. Lots of little stickers, icons and many low res images can, and probably should, be transmitted through relays.
Also, we support a ton of other formats and variations. For instance, we render markdown on any event. It's the same renderer for all event types. Base64 is just one more feature of the renderer.
If it's being used, we will support it.
The problem is that it is hard to put a size limit after-facts, and the burden that heavy events could create is quite obvious.
This sort of possibility encourage developers to embed images instead of using NIP-96 or Blossom, because it is easier.
And a important and widely used client like Amethyst has a huge network effects in this respect, so with great power should come great responsibility.
I think it's bad supporting markdown in standard note for the same reason, in fact this violates NIP-01 that says:
> Content that must be parsed, such as Markdown and HTML, should not be used.
Please, consider this point of view.
All relays already have size limits. That shouldn't be any problem. We already transmit NIP-95 and other very heavy binary events, like GiftWraps and NIP-04 DMs as well as 2000+ key follow lists, text files, blogs, spreadsheets and wikifreedia entries (5-10Kb for a good article). Relays and clients can reject on the size and that's their choice. But big events will always be there.
On the formatting, we just don't have the flexibility on the parser to decide what to parse per event kind. We just use one for everything. So, if people use markdown or ascii doc, like fiatjaf is requesting, we will have just one parser/renderer for all these types.
> All relays already have size limits. That shouldn't be any problem.
I am not talking about 10 KB non-image blobs. Considering that we have people with profile pictures of about 1MB, let's imagine that they start adding one or more pictures taken by a modern mobile phone (~3MB).
The relay limit is not an argument or a solution, because users cannot easily know if/what relays have rejected events, and especially for what reason, so they simply get a reduced (or none) visibility.
I definitely see problems, and frankly I don't see much real benefit.
Btw, this also violates the kind:01 spec.
> On the formatting, we just don't have the flexibility
Add it to fully adhere to NIP-01, please.
Base64 images will be there regarless of our support or not. Many profiles have had base64 images on kind0 for over a year now.
If people are using and happy with the way base64 image works, they will keep using it, regarless of what the spec says. In that case the spec is wrong and must change.
Let's not forget that the beauty of Nostr is that people can do whatever they want. Clients and relays can choose to support or not the user's payload and Amethyst will always support what's being used, regarless if I think it's a good idea or not.
How much is my life worth
Binary 01100101 00100000 00110010 00110000 00100000 01101101 01101001 01101100 01101100 01101001 01101111 01101110 00100000 01100100 01101111 01101100 01101100 01100001 01110010 01110011 00101100 00100000 01110100 01101000 01101001 01110011 00100000 01101001 01110011 00100000 01101101 01111001 00100000 01110111 01100001 01101100 01101100 01100101 01110100 00101100 00100000 01001001 00100111 01101101 00100000 01110100 01101001 01110010 01100101 01100100 00101100 00100000 01001001 00100111 01101101 00100000 01110110 01100101 01110010 01111001 00100000 01101001 01101110 01110100 01100101 01101100 01101100 01101001 01100111 01100101 01101110 01110100 00100000 01100001 01101110 01100100 00100000 01101000 01101111 01101110 01100101 01110011 01110100 00101100 00100000 01001001 00100000 01100011 01100001 01101110 00100111 01110100 00100000 01100011 01101111 01101110 01110100 01101001 01101110 01110101 01100101 00100000 01101100 01101001 01110110 01101001 01101110 01100111 00100000 01101100 01101001 01101011 01100101 00100000 01110100 01101000 01101001 01110011 00101100 00100000 01111001 01101111 01110101 00100000 01100011 01100001 01101110 00100000 01100100 01101111 01101110 01100001 01110100 01100101 00100000 00110101 00100000 01110100 01101111 00100000 00110010 00110000 00100000 01101101 01101001 01101100 01101100 01101001 01101111 01101110 00100000 01100100 01101111 01101100 01101100 01100001 01110010 01110011 00101100 00100000 01110100 01101000 01101001 01110011 00100000 01110111 01100001 01101100 01101100 01100101 01110100 00100000 01101111 01100110 00100000 00100000