Please describe the problem.
The new "tor onion server" setup function uses magic-wormhole to transfer the necessary keys and addresses (yay!). However it should really be using a distinct "app id". Magic-wormhole codes are scoped to a specific APPID, which means that someone using the normal CLI client (wormhole send foo.jpg) can get a wormhole code like "1-purple-kumquat", and someone doing a git-annex setup process can get a code like "1-green-mushroom", and they won't be competing with each other for the numeric channel-id.
If magic-wormhole's file-transfer application got really popular, and there were thousands of simultaneous users, the file-transfer wormhole codes would grow to require three or four digits (e.g. "9134-purple-kumquat"), making them harder to type. But if git-annex uses a different APPID, then git-annex codes could continue to be short and easy, independent of contention for channel-ids on other applications.
To tell magic-wormhole to use a different APPID, just do wormhole --appid=$APPID send ... or wormhole --appid=$APPID receive .... APPIDs should be unique and scoped to an owner of some sort, so I'd recommend a DNS name or URL-shaped identifier, something like "git-annex.branchable.com/onion-setup". If you add a new distinct mode, one which doesn't interoperate with the current onion-setup mode, you can allocate a new APPID for that mode too (e.g. "git-annex.branchable.com/new-thing-setup").
You'll have a compatibility hit when you land this: two applications using different APPIDs won't communicate, so e.g. git-annex before the patch won't do wormhole setups with git-annex after the patch.
The --appid= feature was added in magic-wormhole 0.9.0, released 24-Dec-2016.
What steps will reproduce the problem?
What version of git-annex are you using? On what operating system?
I haven't run git-annex's onion setup feature directly, but I'm reading through the source code from current git, cd8d905f3418b9c6a6c658a0c7256ae6f5066310, Utility/MagicWormhole.hs, and I don't see anything that adds an --appid argument. (I don't know Haskell at all, so I apologize if it's already doing --appid and I'm just not looking in the right place).
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
It looks pretty amazing! Looking forward to using it in a Dropbox-like synchronization context soon.
I've gone with the 2021-12-31 flag day approach. done --Joey
Werner, I appreciate you filing this bug report. And I see magic-wormhole 0.9.1 is now available in testing so it will be in the next debian stable release probably.
If I'm going to make this change, I need to do it ASAP. If git-annex ships in Debian stable not using a wormhole app-id, then it pretty much is going to need to continue not using an app-id forever. (Which might not be a total disaster really; I don't know that a ton of users are using this feature..)
The timeline for this is very tight now, unfortunately. (Pity that I have been traveling and missed this until now.) I'm not sure if, I released a git-annex today with this change, it would reach testing in time for the freeze. I've pinged Richih to try to figure that out.
https://lists.debian.org/debian-devel-announce/2017/01/msg00002.html based on this, we may have missed the window; there are 5 days until Debian freezes, and it takes 10 days to get a change into testing.
It's still probably possible to get a change in, but it would need manual approval. Guess it would come down to whether I could get the change pre-approved for migration into Debian before releasing a git-annex with that change.
(AFAIK Debian is the only distribution containing git-annex that's getting ready to freeze it.)
After talking it over with the Debian maintainer, conclusion is we unfortunately missed the window to make this change.
One way to still make the change would be to modify git-annex now to use an appid, but only once the date is after 31 Dec 2021 or so. So the change then has plenty of time to get into the subseqent Debian stable release (assuming the current release happens sometime in the next 1.5 years, and the one after that takes around the current average of 2 years), and also plenty of time to get into other faster moving distributions.
That leaves a few years in which there's a risk that popularity of tor wormhole pairing snowballs. Currently I do think that's a low risk. Most users of git-annex with tor will likely only pair with well under 10 other repositories (it's too tedious to pair with more, and it starts not scaling well to have links to too many repositories). Pairing takes maybe 10 minutes max to do. So, each user will run wormhole for 100 minutes max. For there to be a constant load of 100 users running wormhole, needs 3600 new users every day, or 1.3 million per year.