@wmd It won't negative impact GrapheneOS users since the Advanced Protection feature largely won't be available in GrapheneOS due to not having privileged Google Play services integration. We can provide any of the future useful features tied to it as standalone features. Some of the features will likely be possible to use. It's possible to use their theft protection features automatically locking the device by giving Google Play services basic admin access but we should provide our own.

@GrapheneOS @wmd hi, i am blind, does your OS have a screenreader i can turn on during setup to setup and use the OS? Androids screenreader is Talkback

@wmd @GrapheneOS @J3317 it’s there, but there’s no TTS engine installed out of the box since the Google services don’t come packaged with.

@J3317 @GrapheneOS @wmd they could yes, but there’s the issue of finding a version that has direct boot support. If it doesn’t have direct boot support, it’s kind of useless in this scenario anyway. Honestly, I am very strongly pushing for that. I installed it once on my old phone, but sadly had to remove it because play integrity was screwing up my reading app. Now that I don’t need the reading app, I really want it back, but I’m not prepared to handover my phone to someone. I don’t trust to set it up.

@J3317 @evilcookies98 @GrapheneOS @wmd Direct boot aware apps can run in the time between system boot and first unlock. The app needs to be able to run without an access to (most) of its files, since these are encrypted and need unlocking.

I am not sure what exact implication this has for the usability of screen readers, since I haven't needed one.

@darkyen @evilcookies98 @GrapheneOS oh, thanks for explaining that, so if a tts can't run at boot like most cant, it switches to google TTS, or if you have a Samsung phone Samsung tts when you power on your phone

@J3317 @darkyen @GrapheneOS still though, you're working under the assumption that all of us have someone trustworthy on command to help us set up our phones. Spoiler alerts, we don't. Since there's no way to push an app to the phone at the same time. Things are flashed, we're screwed. I love what you're doing but that is really putting me off of using it. If I can't set up my phone independently, that's a barrier. I don't always have trustworthy people on hand. I would venture a guess that a lot of us don't. I live with at least one Snoop. We're talking someone who would immediately start going through my messages.

@evilcookies98 @darkyen @GrapheneOS same, i just like being able to turn on a screenreader and go

@J3317 @evilcookies98 @darkyen We're not aware of a TTS app we could include right now due to the need for licensing acceptable for inclusion in GrapheneOS and the need for direct boot support. That means either permissive licensing or GPLv2 for both the code AND the language models. We won't use something with non-commercial usage licensing for the language models, etc. We also won't include GPLv3 software in the base OS, although we're fine with redistributing it in our App Store.

@J3317 @evilcookies98 @darkyen We have our open source fork of TalkBack included so all we need is a permissively licensed text-to-speech implementation including the language models (GPLv2 is permissive enough, GPLv3 is not, but we'd prefer MIT / BSD / Apache 2). We'd then need to integrate it so that it's functional by default and add a way to enable TalkBack in our Setup Wizard. We cannot make a TTS implementation ourselves right now, so unless there's a good one we can use, this is blocked.

@GrapheneOS @evilcookies98 @darkyen oh, well as for a way to enable talkback the android shortcut is hold both volume buttons for 3 seconds, as for tts can't you just use espeak? i remember hearing there was a version that supports direct boot but don't know where to get it

@J3317 @evilcookies98 @darkyen No, since it's GPLv3, and we don't include GPLv3 software in GrapheneOS due to overly strict licensing terms. We don't want GrapheneOS to have stricter licensing terms than the Android Open Source Project. We want GrapheneOS to be usable where AOSP is used as a direct replacement for it.

@GrapheneOS @J3317 @evilcookies98 @darkyen ... so then include espeak and distribute a separate build that omits GPLv3 components like espeak for the AOSP drop-in usecase?

@joepie91 @J3317 @evilcookies98 @darkyen There are better options than eSpeak NG with the permissive licensing we neeed. Regardless of the choice of the app to fork, there's work involved in forking it and integrating it to work seamlessly out-of-the-box without requiring any setup. There's further work to add TalkBack integration into Setup Wizard.

We're not to blame for a project choosing licensing which is broadly known to be something many companies want to avoid. That choice limits usage.

@GrapheneOS @J3317 @evilcookies98 @darkyen Better options such as? And didn't you say two posts ago in this thread that "unless there's a good one we can use, this is blocked", implying that there isn't one?

@joepie91 @J3317 @evilcookies98 @darkyen Better options for a starting point existing doesn't mean we can simply drop it into GrapheneOS as a bundled app right now. That also wouldn't solve any problem without changing the app to have everything required built-in and already configured to work from the moment a fresh install is booted. We could then add a shortcut to the setup wizard for enabling TalkBack. It doesn't do any good if the app doesn't have a seamless auto-configured experience.

@joepie91 @J3317 @evilcookies98 @darkyen github.com/k2-fsa/sherpa-onnx is an example of a permissively licensed and more modern implementation. We have not reviewed it in depth and far away from being able to bundle a fork of it into the OS. All we know is that it's what many of our users recommend we use when this is brought up.

It also supports speech-to-text in addition to text-to-speech and various other functionality. It's more like Google's speech services app. Doesn't mean it's ready to ship.

@joepie91 @J3317 @evilcookies98 @darkyen If we include this, there are other people who are going to be very angry about it because it's based on neural networks.

bsky.app/profile/stopgenai.com

bsky.app/profile/stopgenai.com

This is how modern speech-to-text, text-to-speech, translation, automatic captions, etc. are all implemented. If we tied our hands and refused to use anything using neural networks, we wouldn't be realistically ever able to include speech-to-text, translation, captions, etc.

@GrapheneOS @J3317 @evilcookies98 @darkyen There are, to my knowledge, exactly *zero* models in the LLM/GenAI space that are actually open-source by any reasonable definition, and there's good reason to believe that they can't ever be (because this amount of training data is virtually impossible to ethically source), so the idea of this kind of model as an open-source solution is essentially vaporware.

There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.

@joepie91 @J3317 @evilcookies98 @darkyen

> There is already a viable system which can be implemented today, as has been presented to you by someone *who actually uses these accessibility tools*, which is espeak.

No, a dozen people who depend on text-to-speech to use their devices have told us they cannot possibly get by with eSpeak NG as their text-to-speech implementation. They would use it to get from the start of the setup wizard to installing a proper TTS app. We want a decent feature.

@joepie91 @J3317 @evilcookies98 @darkyen eSpeak NG does not use a license we can use in GrapheneOS. Unless you convince every contributor to the eSpeak NG code to relicense their code as GPLv2 or a more permissive license, we can't use it. GrapheneOS is not going to become more restrictively licensed from AOSP. There are people who actually support our project and help us keep it going who care about this. We're not throwing away a large set of use cases and support for us by including GPLv3.

@GrapheneOS @J3317 @evilcookies98 @darkyen I have literally suggested a solution for this several posts up, that would absolutely work.

"Do not want to do this" is a very different thing from "cannot do this".

@joepie91 @J3317 @evilcookies98 @darkyen We currently support 16 devices. Building for each device takes around 45 minutes. More importantly, testing each build including the future upgrade path takes a long time. It is not feasible to start making multiple builds of the OS. This is also not the only case where people are suggesting making multiple builds. People also want that for multiple other things. It is not actually a realistic solution. It would take an extreme increase in resources.

@GrapheneOS @J3317 @evilcookies98 @darkyen That is just a lot of words to say "we do not want to do this, we do not think that accessibility is worth doing this".

@joepie91 @J3317 @evilcookies98 @darkyen You should check back on the article you spread and attacked us over. The person who published it retracted it and apologized to us for approaching it that way. They want to help us integrate and test something that is acceptable for us to ship instead.

The app which multiple people have recommended to us is github.com/k2-fsa/sherpa-onnx. We would still need to review it, fork it and integrate it to have a seamless out-of-the-box auto-configured experience.

@GrapheneOS @J3317 @evilcookies98 @darkyen As I have brought up before, that system appears to be based on LLM/GenAI tech and models, which means it cannot ever be open-source.

And what the author of the article decides to do frankly has no bearing on my arguments here. You are still presenting "do not want to do" as "cannot do", which are two very different things.

@joepie91 @J3317 @evilcookies98 @darkyen

Proposing building and testing twice as many releases as the solution to anything where we cannot do both things at once in the same builds is something we regularly see about multiple topics including root access. It's not something realistic. It would require an enormous amount of resources.

16 separate 45 minute OS builds followed by a long release signing process and then delta generation from previous releases is already a huge amount to be doing.

@GrapheneOS @J3317 @evilcookies98 @darkyen Once again, this is still just "we do not want to do it", regardless of how justified you feel your reasons for that decision are. But it is not that you *cannot* do it, so don't present it as if it is.

· · Web · 1 · 0 · 0

@GrapheneOS @J3317 @joepie91 @darkyen it boils down to this. Either you or User first or your idealism first. User first would be getting this thing rushed because it’s locking people out, not oh that’s not our priority right now. This is not just something you can say we’ll get too later. If you can’t develop for everyone, don’t develop for anyone.

Sign in to participate in the conversation
Pixietown

Small server part of the pixie.town infrastructure. Registration is closed.