XSF Discussion - 2020-11-22

Zash, https://github.com/xsf/xeps/pull/1010

ohhh

intriguing

I probably missed some elements, and the examples are too bright in order to not have to modify the other CSS, but it’s a starting point.

doesn’t seem to work with my fennec

even though fennec itself is dark

oh wait

I only tested with my laptop’s Firefox, not my phone’s.

my laptop firefox doesn’t know about dark mode at all -.-

only via about:config methinks

I configure mine from GTK’s settings.

no GTK here

echo '[Settings] gtk-application-prefer-dark-theme = true' >> ~/.config/gtk-3.0/settings.ini

works on my laptop’s firefox if I force it to dark

Oh, do you build it with Qt support?

Link Mauve, no, but I don’t have any gtk tooling

I didn’t know it still supported that.

I use whatever debian does

Debian most likely builds Firefox with GTK.

sooo... on the platform which most natively supports dark mode (android), firefox (fennec) fails to respect it for websites, while it does for its own ui?

hm, I find the syntax highlighting hard to read

not sure this is an improvement

I could make it fully white if you prefer.

yes, that or fixing the stylesheet of the syntax highlighter

Or figure out XML colours which go better on a dark background.

jonas’, there.

now they’re dark

https://share.dreckshal.de/dpm/ZiGcUDzS8UZ3iGfpV-LiMoZHjhIvWmfvkGRZU8nyyAk.png

Wut, did I forget to commit the prettify.css?

oh

sorry

No I didn’t.

I was under the impression you only changed xmpp.css

I didn’t update prettify.css on my webserver

much better

this is great, thanks!

:)

pushed

need to poke the docker stuff once it’s done, but lunch first

I should have done that years ago…

no, that would’ve been with the old CSS ;)

huh

the change didn’t make it into the docker image

not sure why, need to look at it later, lunch first

Enjoy. :)

Ooooh

jonas’, I am not a big fan of Blurhash. I think it's not really well documented. https://github.com/woltapp/blurhash/blob/master/Algorithm.md is all you get. It uses custom, digit-based base 83 encoding, doesn't support alpha channel. And as far as I can see, it's not even heavily popular. Mastodon and Signal use it, and that's basically it. It just happen to be circulated within XMPP people for some reason and the word Blurhash is even used here as a synonym for "very small image scaled up in a blurry way" by some.

larma, no, I specifically talk about blurhash

by that I mean the entire package, because I looked at it and I consider it a reasonable and smart solution to the problem

in contrast to taking an 8x8 JPEG/PNG and scaling that up with a bilinear filter

I’m not sure how alpha channels would even work with such a technology, that needs more thought

why do you think it's smart comparing to a simple bitmap? I wouldn't take jpeg or png because they have huge overhead for small size images

classic pc bitmap, you now this old .bmp, is much better for very small images

4x3 = 12 32-bit colors are just 48 byte, encode them using base64 and you get 64 ascii chars. Yes a 4x3 blurhash is "just" 28 ascii chars. But given the overall overhead we have in XMPP that's not a huge thing. Also as quality of blurhash isn't exactly comparable with 32-bit color, we can easily reduce this by half (using 16-bit colors) and reach a size that is pretty close.

Link Mauve, there, it’s live (cc @ Zash)

Shiny, thanks Link Mauve

Woohoo!

jonas’, test image: http://larma.de/blur_sample_base.jpg 4x3 blurhash: http://larma.de/blur_sample_blurhash_4x3.jpg image scaled to 4x3, reduced color depth to 12-bit (no alpha) and then scaled up again, both scaling used cubic interpolation: http://larma.de/blur_sample_cubic_scaled_4x3.jpg

Tbh I don’t recognise any feature of the original image in either of the 4×3.

larma, can you use cubic in browsers?

well, you can see a rough estimate of the color

jonas’, you can use any algorithm with the <canvas> API.

Point is to have something to show until you download the actual image

Link Mauve, sure

The problem is that if you don't have alpha in the preview you can't correctly display it if the final image has alpha and you want to display it on background of varying color (which we need to consider in a heterogenous environment like public XMPP network). You certainly could add an alpha component to blurhash, but then you couldn't reuse existing implementations, making it probably harder to use (and not smaller in size) than just using bitmap data.

larma, not wrong, but I wonder how that cubic interpolation of yours would look like with alpha

I guess cubic interpolation isn't that good for images that typically have alpha. It works good for photos, not necessarily for graphics

yep

downscaling alpha also doesn’t work well ✏

but blurhash also doesn't work well for anything that is not photos, so that's a general issue for these kinds of things

exactly

but I guess one could pick a blurhash-y thing for JPEG input and a simple downscaled bitmap for non-JPEG input

with alpha: http://larma.de/blur_cat_base.png image scaled to 4x4 (32-bit with alpha) and scaled up to original: http://larma.de/blur_cat_cubic_scaled_4x4.png

hm, probably OK on a uniformly coloured background ✏

would probably have more effect on images where more than just a few pixels on the edges have transparency

http://larma.de/blur_xmpp_base.png, http://larma.de/blur_xmpp_cubic_scaled_4x4.png

in any case scaling down to very small images and reducing color depth and then scaling up again gives decent enough results, at least on the same level of blurhash, if you use some more advanced interpolation. If for some reason your platform does not allow you to do this, but you can do gaussian blur, an alternative would be to use no interpolation when scaling up and then apply gaussian blur (with radius set to scaling factor) on the few "very large pixels". Results should be similar.

especially implementation work for everyone who can't use any of the existing encoder and decoders is going to be much less when being based on simple rgb bitmaps instead of complex encodings.

sure

makes sense

MattJ, jcbrand, either of you happen to have an updated XEP-0317: Hats somewhere in your TODOs?

Yes

edhelas also expressed an interest in it recently, maybe he'll beat me to it

I think a lot of distros (maybe Debian?) enable Firefox's anti-fingerprinting protections by default (which disables dark mode entirely)

For whomever was saying it wasn't working in Firefox.

Wasn't that Firefox mobile? Worksforme with Firefox on Debian

oh, fair, I just saw "doesn't work in Firefox" in the history and was taking a wild-ass guess. So grain of salt.

Zash: https://addons.mozilla.org/en-US/firefox/addon/darkreader/ actually seems to work great on almost all sites

moparisthebest, yes but is quite heavy

(I mean if you don’t have a recent multicore machine you will struggle on anything but simple pages like linkmauve.fr)

linkmauve.fr once again > *

I haven't noticed any problems, I even use it on my android firefox

Good thing I broke my new laptop and only use a 9 year old thinkpad.

(stationary thinkpad, grown stuck to my desk)

moparisthebest, I noticed on an i7-7700k with 16GB of ram

:o

Link Mauve, oh, you don't do port 80

No, only port 443.

It should be part of hsts preload though.

huh, so it is

(checking hstspreload.org)

that reminds me, I need to fix HSTS on theta.eu.org

HSTS preload. Whoever had that idea needs to be punished in horrible ways. I mean, yes, it works for something like the top 1000, but how are you supposed to bundle all the crypto nerds' homepages into all the browsers?

seems to be working no?

So I need to submit all my websites to make it break?

submit them all, it'll be fine

inb4 Ge0rG submits <every uuid>.example

Aren't browsers also shipping CRLs embedded? And all sorts of stuff

Ge0rG: Looks like it's only 12MB uncompressed JSON https://github.com/chromium/chromium/blob/master/net/http/transport_security_state_static.json

Zash: well yes, that's *before* I submitted all my domain names! 😁

SamWhited, I have the issue on android, and it’s officially not supported according to MDN

that there is a execute action and an execute attribute and both have defaults if absent

is beyond confusin in 0050

yeah

The action "execute" is equivalent to the action specified in the "execute" attribute. If the "execute" attribute is absent, it defaults to "next".

that sentence is a real treat

what default to next here

the action or the attribute

You're telling me it's still confusing after this went trough council? :/

actually no

the way this is written, it must be the attribute that is meant

It was even more confusing, and then there was a long discussion how to remove the confusion without changing any normative text

it would be so much clearer if the execute action simply did not exist

I was thinking that execute = start

execute = everything

wait, is the execute action a real action element?

its not in any of the examples

Isn't it the first step?

https://xmpp.org/extensions/xep-0050.html#execute-simple

yes

the question was, will i see in real life ever a <execute/> element

no

no

yeah, ok starts to make more sense slowly

would be useless

action=execute → status=executing → { action=next|prev|complete } → status=completed

ah so i can simply never send action=execute

except for the first command

you MAY, or not. it's the only option at that point, so redundant

ok that makes it simpler

because from a gui standpoint, if i draw buttons next, prev, etc

but when clicking on them i send "execute" suddenly

Link Mauve, p.box (Note: ...) has black text

you can send action=execute any time. but it's the "idk what i want, you decide for me" option. so the responder decides what actually happens

Zash, do you want to fix it, or should I do it?

Link Mauve: Do *you* want to? I can, but not now.

i'd wouldn't send action=execute if a user actually clicked on a prev/next/complete button, just the explicit action the user chose

Zash, I’m working on Jingle stuff.

I can do it at some point too.

yeah Lance thats what i also think

only time id consider using action=execute would for some automated exchange, where i just want to fast track though the default happy path the responder wants

but even then, ehhh

oh wow just found this

If the <actions/> possesses the "execute" attribute, that value is the default button or option. If the <actions/> does not possess the "execute" attribute, there is no default button or option.

thats what i was actually searching

so i just pick whatever the execute attr tells me and color my button

and i never have to actually send execute or even care what it "defaults" to if its not htere

yeah, the whole execute attribute thing is entirely for UI guidance/hinting on the submitter side. if you're the responder and receive action=execute it just means you get to choose what happens instead of the submitter choosing

the ambiguity in the model comes from when the responder provides (or doesn't provide any) UI hints that match what it would choose

Ought to have been called "default", but oh well

err, UI hints that _do not match_ what it would choose

i think the problem is that i trys to fill 2 jobs

first provide a UI hint

2. for this rare usecase where i just want to send "execute"

i wonder how a xmpp lib fullfills both things

because the xep says, execute defaults to "next"

but obviously a xmpp lib should not fill the var with "next" otherwise the UI doesnt know that there was no default action and no UI hint should be given

either way, after working this out now, i treat it only as UI hint client side

and i dont default it to "next", because not set means no hint should be given