[guardian-dev] Bazaar/F-Droid: Two-tap vs One-tap provisioning

[D Black]

The repository details now get put in  res/values/default_repo.xml since Monday. In the merge request, the Guardian Project repo was actually in the file, as a second repo and off by default, but it was taken out later as it is a 'third-party repo'.

 I'd like if the official F-Droid client were treated independently from the repos it connects to and a bunch of FOSS repos offered to the user on startup. That way, everybody gets some exposure. On the other hand, maybe it's better that every APK repo issues it's own client; changing package names and branding is much easier now with Gradle. After all, it's one less person to trust. It should be noted that the UI for handling many repos is still very rudimentary and full support will surely mean more complexity.
Now there's an Android.mk we are going to see ROMs include the client with the original package name, but possibly with different default repos and signed with a different key. You could do it this way: I don't see a problem as long as you keep it updated via your repo and basically unmodified. (Let's note that the GP repo doesn't currently include the F-Droid client itself, so people who don't use f-droid.org don't get updates for the client). As HC, noted there's already a menu item since 0.58 to listen for local device-based repos and having your own build will cater to people who arrive at your website without the client, so that seems to cover most scenarios.

There's an effort that will surely grapple with this matter when it lands: http://www.uhuru-mobile.com. They aim to let each shop have its own APK repo. 


Message: 4
Date: Thu, 20 Mar 2014 09:22:48 -0400
From: Nathan of Guardian <nathan at guardianproject.info>
To: Guardian Dev <guardian-dev at lists.mayfirst.org>
Subject: [guardian-dev] Bazaar/F-Droid: Two-tap vs One-tap
	provisioning
Message-ID: <532AEBA8.9060901 at guardianproject.info>
Content-Type: text/plain; charset=ISO-8859-1


Currently, with an app management system like F-Droid, it would require
users two taps to setup our repo. Imagine a new user with nothing
installed, visiting a page with two big "download" buttons:

1) Tap to install F-Droid (one time bootstrap)
or 1a) receive F-Droid via bluetooth/NFC or other peer share mechanism

2) Tap to add Guardian Project repo (URI which F-Droid handles, auto
sets up fetches and display available apps).

or 2a) Scan a QR code or NFC/Beam to receive the second URI

This isn't terrible, but it is twice as much work, and don't forget the
#1 setup process is already quite annoying as an APK download due to
finding the download notification, ensuring "trust unknown APK" is
enabled, etc.

A question came up yesterday regarding how to in one download both
provide a stock version of F-Droid, but then also somehow append or
attach to that download the custom repo URI or other bootstrap config data.

We had a few ideas, including:

1) Injecting data into the APK in a way that doesn't cause problems with
the built-in signature (which isn't a signature of the whole APK/JAR
file, just the relevant android bits).

2) Use some sort of bonjour/zeroconf service if you are sharing this APK
on a wifi LAN between peers to broadcast a peer repo

3) Generate a one-time use meta APK of some sort that contains both
F-Droid APK and the config data.

Any other ideas? Thoughts on these approaches?

The goal is to support simple bootstrapping of dynamically addressed
peer repos, as well as allow organizations to have their repo in F-droid
by "default" with out requiring forks or white labeling.

+n