d0ntpan1c

Forgejo is already working on federation https://forgefed.org/

https://addons.thunderbird.net/en-US/thunderbird/addon/filelink-provider-for-send/ this add on can be pointed at any send instance, so long as the instance isn't too diverged from the popular fork or Mozilla's original project.

The Thunderbird team has talked in the past about bringing Mozilla Send back as more of a feature for Thunderbird files embedded in emails, hence some of the work that's happening off and on by Mozilla themselves in the original project, some of which has been merged into the project this post is about.

Its been in testing for a bit. It got bumped from the last major desktop Thunderbird release and since Thunderbird releases used to be synced to firefox ESR releases its been a slow turnaround to get their schedule moving faster.

Its an f-droid metadata issue that the team is already aware of https://github.com/thunderbird/thunderbird-android/issues/8478

Most of the time its the fault of the developer if a page only works in chrome.

Mull and Fennec are way more obvious android browsers to switch to if Firefox doesnt meet your privacy needs/concerns.

Been using deno 1.x for edge functions use cases at work and its been pretty solid. The standard library is excellent and it leans into web standards rather than node.js, while usually still supporting the node.js standard lib (I'm assuming through some polyfilling to the web standard but idk for sure)

It feels a lot more like working in python where you can probably get the job done with the standard library rather than needing to reach for packages for every task.

I'm looking forward to 2.x, it'll feel a lot less like a WIP runtime.

The space example is extremely apt. Its possible we could have had tons of space stations, a moon colony, maybe even some other stuff going on around the solar system, asteroid mining, etc. But thay would have at least required the space race to continue longer and for spending to grow to create a big enoigh industry to ensure thay outcome, assuming no capacity or time issue. Alas, we took another path.

Something that seems important to us might not matter in even 10 years, or at least, not have a monetary and/or societal incentive to keep advancing.

They've tried, notice how many of their products and services with a cost get shut down?

Their power users are too picky for what they offer, and the normie users wouldn't want a product the power users demand.

Even so, google being forced this way will make app installation/updates much more convenient for non-root and oem-rom users. And ensure rhe aurora store or a future iteration of it aren't going to flag peoples accounts for google to take action against them.

FWIW some of the problems are on website/app developers. Not sure on specifics on the app side, but with websites if the dev doesn't use semantic html input elements with the correct type attribute to denote the password form, autofill won't work (since neither android or the password manager know its time to do stuff)

Nothing wrong with username/password on different screens (one at a time is good for several accessibility-minded reasons) but again, there are some best practices to follow which allow screen readers and password managers to still act as you would expect.

I'd assume android app dev is similar.

That said... I do think it's gotten a bit clunkier at times in ways I dont recall being problematic in the past. I use 1password and heliboard or floris board and while those keyboards seem to bug out a bit, sometimes the bigger problem seems to be that android isn't always telling 1password enough info to find the right account. Idk how apps "inform" the password manager (maybe via url's in a metadata file or maybe passwors managers have ro keep theor own internal db?), but apps that use web wrappers (specifically the old and/or shitty ones) report their url as http://localhost since the wrapper just renders a local page in a web view. that'll wreck a password managers day real quick.

Idk if Android is worse than iOS here, not that it is a reason for google to punt on improving it. iOS has its own autofill quirks thay can be just as annoying. Esp constantly asking if you want to use your app or apple keychain without a way to just pick a default...

Very unlikely. They will support new extension API's (they are already 90%+ compatible with manifest v3) bit Mozilla has committed to maintaining compatibility for the manifest v2 API's that don't exist in v3.

Claims otherwise are FUD.