feat: add generate-ticket command #86
Conversation
This is at least useful to git-annex p2p which requires to know about the connection string on the p2p network before it serves connections on it.
|
@flub this came out of the Distribits hackathon, other than this change dumbpipe is basically plug-and-play as a transport for git-annex p2p AFAIU, which is awesome! |
|
Here is what uses this on the git-annex side: https://git-annex.branchable.com/special_remotes/p2p/git-annex-p2p-iroh |
| let secret_key = get_or_create_secret()?; | ||
| let endpoint = create_endpoint(secret_key, &args.common, vec![args.common.alpn()?]).await?; | ||
| // wait for the endpoint to figure out its home relay and addresses before making a ticket | ||
| endpoint.online().await; |
There was a problem hiding this comment.
I understand your aim is to generate a ticket containing the RelayUrl, and that's why you need to have an endpoint. That's not unreasonable, and probably works fine with the current number and geographical distribution of relays. But in theory there's no guarantee that by the time you really run the dumbpipe the same relay will be used.
You could instead not require this, in which case you can generate a ticket from just the EndpointId. It would mean you need discovery available when you actually connect, so you can use dial-by-endpointid. Though you probably need to wait slightly longer for that because the accepting process has to have time to publish its discovery information. And then you have to deal with DNS caches possibly.
The other way to fix this is to decide on a single Relay server. You can either select one and create a ticket exactly like is done here. Then the 2nd time you invoke it with the same secret key you also want to tell it to only use that one relay server. And then your ticket is valid too and you don't have to deal with discovery delays.
There was a problem hiding this comment.
But in theory there's no guarantee that by the time you really run the dumbpipe the same relay will be used.
That's not good. I am a bit fuzzy on the details, but I was thinking that I just want to use the N0 presets for discovery and relaying. If this were to just generate the ticket from endpoint id only, how would discovery work? I think git-annex would have to agree on a discovery mechanism on both sides out-of-band then, right?
There was a problem hiding this comment.
If this were to just generate the ticket from endpoint id only, how would discovery work? I think git-annex would have to agree on a discovery mechanism on both sides out-of-band then, right?
dumpipe uses the n0 presets I guess, so it would use DNS discovery. I think this might just work with creating your ticket from an EndpointId only and relying on discovery. You'd have to try it out to know if the publishing timing would be an issue.
There was a problem hiding this comment.
Ah, I think I get it now. I'll send another PR making it dial-by-id. Having to change the connection string in git-annex after the fact should be possible, but very annoying, so should be avoided.
# avoid display of the iroh secret to stderr
dumbpipe generate-ticket 2>/dev/null😓 perhaps dumbpipe should not be printing this at all and should only print the public key it is using. |
Or it could print it only in verbose mode. |
Agree on not printing sensitive information like that. But AFAICT it is the only way to get at the dumbpipe-created secret, so for the use-case of reusing a secret it is needed right now. But maybe this will become obsolete with #84 anyway. |
3 participants
This is at least useful to git-annex p2p which requires to know about the connection string on the p2p network before it serves connections on it.
It would be even better if this was possible without fully building and binding the Endpoint, but I couldn't find a way to apply the presets otherwise, and I didn't want to duplicate those either.