I’m not sure if it’s spelled out in the ToS, but there is no way to prevent pull requests on public repos, it’s a functional requirement.

You have to make a fork aka copy and modify to contribute via pull requests. The license is fundamentally broken.

Your proposal seems to target the same issues as with multi-community support https://github.com/LemmyNet/lemmy/issues/818, which just got 6000€ funding from NLnet. Which seems to be a cleaner way of achieving the same goal.

Some suggested points are also against ActivityPub standard.

No audit, no 2FA, no transparency report, limited servers, proprietary clients. There are better options.

Element X (Matrix client). Basically anything that offers F-Droid or open source release will have builds without built-in notifications. Play Store/App Store builds requires using native notification systems.

It was a conscious decision for them not to enforce E2EE by default. https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/

XMPP clients have like 10 different implementations because of that and are not always consistent with each other or even function universally across platforms.

But I’m not an author. That would be @[email protected].

In 2020 Google claimed it was supposed to be limited to a single region in partnership with a single carrier. And was never meant to be put up on Play Store.

A spokesperson from Google reached out to clarify some details about the Device Lock Controller app. To start with, Google says they launched this app in collaboration with a Kenyan carrier called Safaricom.

Google has confirmed that the Device Lock Controller app should not be listed on the Google Play Store for users in the U.S., and they will work to take down the listing.

Source: https://www.xda-developers.com/google-device-lock-controller-banks-payments/

Of course, it was a lie since it’s still on Play Store an of today and in use.