Prior art: Eisenfunk - Pong (https://www.youtube.com/watch?v=cNAdtkSjSps)

Great idea - I ended up experimenting to improve the ocr accuracy:

    #!/bin/bash

    screenshot=$(mktemp)
    decoded_data=$(mktemp)
    processed_data=$(mktemp)

    cleanup() {
        rm "$screenshot" "$decoded_data" "$processed_data"
    }

    trap cleanup EXIT

    flameshot gui -s -r > "$screenshot"

    convert "$screenshot" \
        -colorspace Gray \
        -scale 1191x2000 \
        -unsharp 6.8x2.69+0 \
            -resize 500% \
        "$screenshot"

    tesseract \
        --dpi 300 \
        --oem 1 "$screenshot" - > "$decoded_data"

    grep -v '^\s*$' "$decoded_data" > "$processed_data"

    cat "$processed_data" | \
        xclip -selection clipboard

    yad --text-info --title="Decoded Data" \
        --width=940 \
        --height=580 \
        --wrap \
        --fontname="Iosevka 14" \
        --editable \
        --filename="$processed_data"

I use Flameshot combined with Tesseract and zbarimg to quickly clip areas of the screen and either OCR them or decode barcodes, which I then map to hotkey combinations.

For example, I have `bash -c 'flameshot gui -s -r | tesseract - - | gxmessage -title "Decoded Data" -fn "Consolas 12" -wrap -geometry 640x480 -file -'` mapped to Super+O, so I can just press the key combo, select a region of the screen, and have the OCRed text immediately displayed in a dialog box from gxmessage (which accounts for most of the command line). Replace 'tesseract' with 'zbarimg' and you have a barcode scanner.

You can do something like:

    printssh() {
        tte --input-file YOUR_FILE --frame-rate=500 $(echo "beams binarypath blackhole bouncyballs bubbles burn colorshift crumble decrypt errorcorrect expand fireworks middleout     orbittingvolley overflow pour print rain randomsequence rings scattered slice slide spotlights spray swarm synthgrid unstable vhstape waves wipe" | tr ' ' '\n' | shuf -n 1)
        ssh "$@"
    }
    alias ssh="printssh"

I believe you can treat it as if it were an image by putting it an element with attributes role="img" aria-label="description of the diagram goes here"

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Ah, in that case you might want:

    text-size-adjust: none;
    -webkit-text-size-adjust: none;

(it's infuriating that these options need to exist!)

> Offer a comparable alternative, then

Here's a few:

  - https://meet.jit.si/ which you can also self host https://github.com/jitsi
  - https://bigbluebutton.org/ which you can also self host https://github.com/bigbluebutton

I've found that they're especially useful, when integrated with Rocket.Chat https://rocket.chat/ which you can also self host https://github.com/RocketChat

That way you have an experience that's a lot like Slack/Teams, with pretty good support for chat, reactions, file uploads, discussions, making quotes etc., while also being able to start video/audio calls with the press of a single button.

Of course, if that's too many platforms, Rocket.Chat also supports WebRTC, albeit the UX was a bit less stellar when i last tried it.

Alternatively, there is also Nextcloud Talk, which can integrate with your instance of Nextcloud and allow for file sharing, chatting etc., though personally i found Rocket.Chat to be more usable: https://nextcloud.com/talk/

Regardless, those are some very competent options which allow all the data to remain on your own servers.

Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds.

In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons.

----

Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course).

If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX.

Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider.

Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.