Testing base64 image

data:image/webp;base64,UklGRrIKAABXRUJQVlA4WAoAAAAgAAAAYwAAYAAASUNDUKACAAAAAAKgbGNtcwRAAABtbnRyUkdCIFhZWiAH6AAHABAAFgApADVhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1kZXNjAAABIAAAAEBjcHJ0AAABYAAAADZ3dHB0AAABmAAAABRjaGFkAAABrAAAACxyWFlaAAAB2AAAABRiWFlaAAAB7AAAABRnWFlaAAACAAAAABRyVFJDAAACFAAAACBnVFJDAAACFAAAACBiVFJDAAACFAAAACBjaHJtAAACNAAAACRkbW5kAAACWAAAACRkbWRkAAACfAAAACRtbHVjAAAAAAAAAAEAAAAMZW5VUwAAACQAAAAcAEcASQBNAFAAIABiAHUAaQBsAHQALQBpAG4AIABzAFIARwBCbWx1YwAAAAAAAAABAAAADGVuVVMAAAAaAAAAHABQAHUAYgBsAGkAYwAgAEQAbwBtAGEAaQBuAABYWVogAAAAAAAA9tYAAQAAAADTLXNmMzIAAAAAAAEMQgAABd7///MlAAAHkwAA/ZD///uh///9ogAAA9wAAMBuWFlaIAAAAAAAAG+gAAA49QAAA5BYWVogAAAAAAAAJJ8AAA+EAAC2xFhZWiAAAAAAAABilwAAt4cAABjZcGFyYQAAAAAAAwAAAAJmZgAA8qcAAA1ZAAAT0AAACltjaHJtAAAAAAADAAAAAKPXAABUfAAATM0AAJmaAAAmZwAAD1xtbHVjAAAAAAAAAAEAAAAMZW5VUwAAAAgAAAAcAEcASQBNAFBtbHVjAAAAAAAAAAEAAAAMZW5VUwAAAAgAAAAcAHMAUgBHAEJWUDgg7AcAABAqAJ0BKmQAYQA+MRSIQqIhIRjZzaAgAwSzAGYM4H8a/FXtVMm9J/LP8lfmuq/9U/FHF8oE63fxv3I+/3/Y+0nzBP1E6c3mc/Xr9c/eE/zP7Ae7H9k/1j/sHyEf0b/AdZP6AH7AemL+5Hwm/uh+4HtFf//OQ+x7/T15/+4gU25u5EGNzz+s+D1B/3fcL/mP9S/5nYj9HAi/qP61PKXLT6S7L5AqQ8t63tZmkFyt8QOo2QkSL2dOtHnDnPa6cVytPgjDOkizH8MnVsp2/xtFmHNDAcLoAUgX5GmfzwKXSwbAr+V3kIjm5/wp8GkbfW9kugAAUHVn34x7XmCbig2BF7mHhJYIJMZZTU2XAjcQyOHxXreTV9LMFt6ZrxWIcyP2NuYdwrIxl5PAe9UBKlLBBUqNnMAS5yOH9Ar1vpEpdl4x/ryWsi+CYsvtAU1ZPb/P5D2PVbQxN5YTAAD+53JlBWo0QRMxW5OTe0hA9WdS/+futOcx94DLD/Aihzqfpg5ZazKbWLNNjyRGh7p5bXEDwdfSGZGBBh0wa1al/35p5bSBAe2fSN8z5GNXt2G6TzfhOr8a8ZXrdXe/R+/MlZ/hxuQxwDcdFMpX6uHqktJLxNTGgb+Y+f4jKr9Bxyh+CaSWkNzVX9rjiCy/Mrxsvb7mkpWnxuzL0/BB0T5i+V+vts3OlIY/Ew1cgHiFNOjlXDV1scPBqukES0jEs6Kt9D1V+dhipRNNoVnr3sbZVoYVn9sKJmurjO10UTjhPSxZCYQ/ALf5SoYWHRcE7EP73IXfSvo1Ddw2rrPGg1K9tBhrSbyvRljx1+rtz8H/l47JbO6am1njT0Yn+mFDjFYJiySywJhtn6x5mhvBC5R91XoFr5HjHZ41D7r2xka9RsS5+iGvncH9GUsL3aSHMZmk4Ju9jTLGU75YEKmFA0dubTD/sCQCPRrlhOWdLKfylmvNTcGJcHGYb9I4CvtM+o/E4dFYJdXMZ2WscXq3mH3RGbPaXJKicLafxUBuu4pbXTCKYlfV3LSfCQ1PQn40jQs0DMbuqLr3NJwbOCeWY3Xnv96HtuNn+6AHkQ0ELdNC83cL0QLaxxHQaBWi9n+4XaRcrIygPpvGx1dsK2/a86+Th7rYw1yLVzGq4sgWCeIzrifU+6j2LxG4VE4q0wZ4MWsYTpQdn/woj/EqSGH6ZXv58+8RCnY4nyzmUwP/6eooI7S0Qix1j97cYUe7D4JCHe3+2YIuosHmV23CVhfDLzH228E+UNDQhBJuQ1pOJ/pKjAcW7R/reV7V1DU4EWS1TeEkNvWzXTGFx8KKSgUSfYCGQ61D4AygVNYR0deuHb/S9A38kAK8xbq5jnaN5o30/KUGbhBiz5MvpIQ07B9S546+Bp2A8ty/+HunE6KcdJxsNr+S/6gVQsfwt0dF8a75DaQT8ZWL3p/iasyPyVsiB1HLlYfurb3GQHlVhMlm5ELwG0DR3hhJuP22CR7TRv8GD9gC0PxHZR7ZOTY0KJF19MBjpKG0IqzKNLWoIEm/nbWfQ810ScPanNeyGl0M/FBFqS5egFKTUO2H6XrPkqdZBRUHksNlas91DgxnjBBtBVn/mv4Ne+aTN8xc/a09UyomKBJEisbVB/53+CK35ZjleHI/2LLXLL2yswhe4Q2iv96nTX7+yMHuYpwWX9JYDCoWKOnaf3//FMC8WP6yuAOrA/+0+1aRfd/3hNkN9Fx2Qb/8251biJNDS0O+xUTIMh/vmgAG/ZVqMfu9hnO6FWFwuJReM9mhzz9ocxm+lGIKJb/bbUwu4b6vIhJ8Q0CfrlhsrvOG+8hlXgvO0jaZrEbdQAUmr3xbsScDDVSMSTPGXFxE9FDyWeOd34J21kGKAk5OB/pNrrxjtHv+DqXsZXbkOFl7zVSXJCg/hXGcnJdSgobuzvd6DWSXSPIld3ht89Jgsmg0WbDZD8D/t0sjcjVcofj+Vfvb+sTXnb1jA4UW44A5Ohbz9zFpa1xG048ISPbLWutazbuY6eMvYPZd5Z9Yu6gWKEy8krSJak53XLY+T6ehOLgXtgUhJKxYhfU39J5U4jr9pQdvA4MeQdsrXdOuvine8B3Ddnb/olUV5ywwGM0FpVdhdNCy+w32zbingsgKGNBs1nQTcDYGrt/OlCrzBbep/EpFzE/Erwf5KGqm6xvWSNbplfNKiAuHpXQISMZGgD/7LnrRt5cV/mtwmVoIhy2yLBGua8ZjC1+L/rfpcH/YwUyExu2WzeMoSgiadEEqTStALHZEsw4S/K9Eby7MwmBGzELe45df7ZUZmrxIa7YOApcklb/cy+cDrNJ6+16RDJ5RrX/5QPZ+RZS1e11dVFuUIUFy1UwmoWzsGbx/oZfO5Ivs1SA1xEpfvwJ/kEGcvnCPxFJnUGr1WpB55dVNtdMJSa3ybDMyZnzn3cvXxX8kdNfscut/cNeEiErvzzn1jDtbr/goOQU5vvUplyjbu09cTjIjcLeLPseEDEEWyLDSRy3FhSUFfOuNeX8PfSL2HuQRYHfaiOHBq/In4YHDrnoEY38GeYjlF9m6bsrBCO93tbypK3ukwkAaYu36EwynJFn7N+SB/xopQ4dAnU23du5bHLO/NQPRtjsQD5AKk+7jCbOXqEr/sM8f+6ZM7vsGCCIYzQLUPVZQO4qkvparE84L3qwRFp5EgA3g9uAAxs6h9UjWN91RrT1kgC5bgAAALvAAAA==

Reply to this note

Please Login to reply.

Discussion

What exactly does that?

It’s just a binary encoding of the image. You should be able to reconstitute it manually with a command like this on Mac or Linux to see what it is:

base64 -D > image.webp

Oh. Well that makes sense. Any would would we want base64 images? What's the use case? To upload images to relays as base64 blobs?

Yea storing images directly on relays. I personally would block this on my relay. Or drastically limit the size of the data. I don’t want to serve images.

Feel free to block it. Just be sure to tell your users that you are doing so. People are free to move to other relays when they see missing data.

Only paid relays are required to report such things, while free ones operate as-is and are not obligated to do anything.

No one is obligated to do anything. But if they want to build a health relationship with their users, they better do. There is nothing worse then figuring out the relay you like is misleading you with hidden policies, regardless if its free or paid.

Healthy relationships mean not embedding base64 blobs into text notes. Users do not notify some relay owner that they will do this, so he may not notify them either. We don't have a system of contracts and obligations here.

Correct. But users can still hate you if you are hiding posts form them. This has happened many times in Nostr in the past and it is never good for the reputation of the relay operator.

All relay implementations have event kind filtering, and max event sizes with reasonable defaults, 65k for strfry or 128k nostr-rs for example. Those are there to stop misuses just such as this. If this data gets truncated or rejected because you're (IMO irresponsibly) shoving data into a kind 1.... That's not on me.

I don't see how this experience isn't janky in the best case for users.

Error messages are enough. If the user doesn't read them, well... 🙄

Error messages are not hidden. Many of these policies are never communicated, not even in error messages. That's when people get angry and the operator's reputation goes to the trash.

Communication goes a LONG way towards user experience. If you're running a service, tell your users what they can and can't do. Relying on non technical people to figure out what they're able to do is a bad user experience. Nostr benefits as a whole when users have better experiences.

I have a lot of respect for you and what you’ve done for Nostr, and I also don’t need your permission to do whatever I want on my relay. So don’t tell me what to do.

Sure. People are free to shoot their own foot by hiding things from their own users. I couldn't care less.

これになりました

A Pikachu, but it doesn't appear in the album on the homepage.

are you trying to put relays out of business?

If this will take them out of business, they are already dead.

you know what i'm asking, why send all the image data, esp. in a protocol that basically requires duplication

It's the user's choice. They can add a link or add the image itself. It's not for me to decide.

i think its kinda irresponsible to do it under kind 1

If it is then people will reach the same conclusion that you did and stop using the feature. In the end, it's their choice.

Users themselves do even worse things in kind 1. In any case, the relay can effectively reject or filter it. I don't see a problem with this.

apps enable users

aww, what a cute lil pokemon. or whatever.

I see something when I squeeze my eyes

Looking good after latest update from Obtainium.

But why though

If people are using them, we will render. The why is the user's problem. If they think it is bad, they should not use it. If they think there is a reason to use it, it's available.

b64 images violates the "human readable" principle. I don't think rendering them is the right approach.

By that standard, every long link violates the principle, including nprofile and nevent links, cashu tokens and ln invoices/withdraws

Yes, but there are two differences:

- Those entities are often provided by the user directly, and are therefore meaningful to users. Clients are imitating natural end-user actions by generating them.

- Entities are references (links, npubs), or content that has no reference (cashu tokens, invoices). b64 images are content that can otherwise be included by reference.

In other words, I've never seen a user paste a base64 encoded image into a note instead of uploading it to a host and referencing it.

Every content can be included by reference. I don't need to type the message, I can just add a link to where the text message is in my server and sign that.

You can search for base64 images on NIP-50 relays. There are 1000s of posts with images before our release went out and those were breaking Amethyst's UX. So, it's a no brainer for me.

The user void has spoken

So if I start publishing notes from Coracle in rot13'd LaTeX you'll render that too?

if people use it, I would be forced to support it.

Ok, serious question, who is publishing content base64'd images in it? I vaguely remember hearing about a new client doing this but can't remember who.

Seriously? Why?

nice :O

The advantages of this are obvious.

It's good for decentralization (an image host is no more resilient than any other web host) and it's good for a privacy-centric experience (the client can communicate only with selected relays, without sending any information to an image host).

The disadvantages are quite as obvious.

It's bad for relay operators, because it makes events bigger.

It breaks Nostr's fundamental property that kind0 events are meant to be just text. Not text with markup, not text with images, not text with formatting, not text with anything else. Text, just text.

It should be noted that if this is coupled with allowed modifications of events, the client will receive the whole event, including the image, multiple times, because it has no way of knowing ahead of time which relay has the latest version of the event and the order in which relays respond is irrelevant.

The implementation, also, isn't good, in my view. I see there is no tag signaling the presence of an image. I think there should be.

Overall, I think it's important to decentralize storage of images and make it censorship-resistant, but I don't think placing base64 encodings in Nostr events is a good way to do it.