

In the worst case it will just be Motorola shipping their base android version with verification and then just flashing grapheme over it. Just the way it currently works with pixels.


In the worst case it will just be Motorola shipping their base android version with verification and then just flashing grapheme over it. Just the way it currently works with pixels.
Didnt know abput that.
They store where to deliver the message, but not from who that message came.


I should have been more clear.
I meant for self hosting.
Though realistically, even if the service is provided for the public, you could just use an instance of keycloak or something similar with open registration. That’s what an association I’m close to is doing already.


By default, the Credentials provider does not persist data in the database. However, you can still create and save any data in your database, you just have to provide the necessary logic, eg. to encrypt passwords, add rate-limiting, add password reset functionality, etc.
That is exactly the complexity I wouldn’t want. With just SSO it is enough to send a redirect URL to the browser and on the callback set a cookie. No js needed. If your service gets compromised and someone leeks the credentials, just log everyone out.


If i created a service I would go in the opposit direction. Only offer SSO and no other option.
You loose quite a bit of complexity that way.


If anyone ist surprised by that they should look up why niantic was ever founded.
It was always about data collection in the real world.
You say you are on a budget. Yet you talk about 128 Gigs of ram.
Maybe you should clarify what your budget is.


Its timing based. When piped a script, bash executes each line completly before taking the next line from the input. Curl has a limited output buffer.


They can even serve a different file for curl vs curl|bash
They can just sell their normal phone. As long as the user is able to run the installer it doesn’t really matter.