New app: null-pointer

Abstract for new app inclusion

Please introduce the functions and usage of your app in summary, and also attach some screenshots.

null-pointer is a native Android (and iOS) client for devnull, a social network for developers that reads like a git log: posts are commits, replies are branches, and the timeline is drawn as a graph. The app lets you read the log (Following, Latest, Trending), post commits and replies, star and follow, read notifications, and manage your profile, with light and dark themes.

There are no passwords or tokens: on first launch the app generates an ed25519 key in the Android Keystore and signs every request with it. Sign in with GitHub happens on dev-null.sh in the system browser. The app talks only to devnull (or an instance you point it at), sends no analytics or crash reports and contains no tracking SDKs or Google services. Licence: MPL-2.0.

Screenshots are in metadata/com.siddarthkay.nullpointer/en-US/images/phoneScreenshots/ and in the README.

Please elaborate why you wrote this app. Please highlight the unique functions it provides over other similar apps in F-Droid.

devnull only has a web app and a NativePHP prototype that is not on F-Droid. I wanted a fast, native, tracker-free client for it and there is no other devnull client in F-Droid. It is built with Expo / React Native and the build recipe generates the android/ project with expo prebuild on the build server, with all Expo modules compiled from source.

Checklist

Policy

  • The app complies with the inclusion criteria.
  • The original app author has been notified (and does not oppose the inclusion). I am the author.
  • The upstream app source code repo contains the app metadata in a Fastlane or Triple-T folder structure.

Docs

Merge Request Setup

  • The title of this merge request should follow "New app: app name" format.
  • Please make sure your fdroiddata fork is public and your branch is not protected.
  • Please read our Git guide if you don't know how to rebase your branch. Don't rebase your branch if there is no conflict.
  • All related fdroiddata and RFP issues have been referenced in this merge request. There are none.
  • Please only submit one app in one MR.

Metadata

  • Metadata must be put in metadata/<applicationId>.yml.
  • Metadata must be a valid YAML file.
  • Metadata must use LF as line ending.
  • Don't add summary/description/changelog/images or anything that should be provided in upstream repo. See the Fastlane note above.
  • Releases are tagged and auto update is enabled (UpdateCheckMode: Tags, version and version code read from app.json).
  • There is an issue tracker and contact info of the author so that we can report bugs and contact the author.
  • An AuthorName must be added.
  • External repos are added as git submodules instead of srclibs. None are needed.
  • Enable Reproducible Builds. Not for this first version: the APK is built with Expo prebuild and release signing happens in GitHub Actions, and I have not yet verified that the F-Droid build is byte-identical. Please sign with the F-Droid key.
  • Setup abi split if the APK is large and the splitted ones can be much smaller. Universal APK for now (Hermes plus the React Native runtime for four ABIs); I can add per-ABI builds in a follow-up if you prefer.
  • Only the latest versions should be kept in the metadata before it's merged.
  • Don't add any disabled versions in the metadata.
  • The commit field should be the full hash.

Pipeline

  • All pipelines should pass.
  • All warnings and errors in the Reports tab should be fixed or explained.
  • F-Droid CI runners are under GitLab's FOSS program, so there's no need for you to pay for any CI time.
Edited by Siddarth Kumar

Merge request reports

Loading
Loading