Skip to content

feat: add generate-ticket command #86

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 25, 2025
Merged

feat: add generate-ticket command #86

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions src/main.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,13 @@ pub struct Args {

#[derive(Subcommand, Debug)]
pub enum Commands {
/// Generate a short endpoint ticket. This ticket can be used to later connect to a
/// listener that is using the same secret key again.
///
/// This command only really makes sense when you are providing dumbpipe with a
/// secret key.
GenerateTicket(GenerateTicketArgs),

/// Listen on an endpoint and forward stdin/stdout to the first incoming
/// bidi stream.
///
Expand Down Expand Up @@ -148,6 +155,12 @@ fn parse_alpn(alpn: &str) -> Result<Vec<u8>> {
})
}

#[derive(Parser, Debug)]
pub struct GenerateTicketArgs {
#[clap(flatten)]
pub common: CommonArgs,
}

#[derive(Parser, Debug)]
pub struct ListenArgs {
/// Immediately close our sending side, indicating that we will not transmit any data
Expand Down Expand Up @@ -823,11 +836,23 @@ async fn connect_unix(args: ConnectUnixArgs) -> Result<()> {
Ok(())
}

async fn generate_ticket(args: GenerateTicketArgs) -> Result<()> {
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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

let addr = endpoint.addr();
let short = create_short_ticket(&addr);
println!("{}", short);
Ok(())
}

#[tokio::main]
async fn main() -> Result<()> {
tracing_subscriber::fmt::init();
let args = Args::parse();
let res = match args.command {
Commands::GenerateTicket(args) => generate_ticket(args).await,
Commands::Listen(args) => listen_stdio(args).await,
Commands::ListenTcp(args) => listen_tcp(args).await,
Commands::Connect(args) => connect_stdio(args).await,
Expand Down
Loading