Skip to content

feat(iroh)!: introduce online method#3467

Merged
dignifiedquire merged 10 commits intomainfrom
feat-online
Oct 6, 2025
Merged

feat(iroh)!: introduce online method#3467
dignifiedquire merged 10 commits intomainfrom
feat-online

Conversation

@dignifiedquire
Copy link
Copy Markdown
Contributor

Description

A new attempt to start improving the address and boot up situation.

There is a new online method, which simply waits for the NodeAddr to be filled, usage is easiest to see by looking at how the examples have changed.

Breaking Changes

  • removed
    • iroh::Endpoint::direct_addresses
    • iroh::Endpoint::home_relay
  • changed
    • iroh::Endpoint::node_addr now returns synchronously the current addressing information
  • added
    • iroh::Endpoint::online
    • iroh::Endpoint::watch_node_addr

Copy link
Copy Markdown
Contributor

@flub flub left a comment

Choose a reason for hiding this comment

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

I like this approach! It's a good breakthrough on this problem.

pub fn direct_addresses(&self) -> n0_watcher::Direct<Option<BTreeSet<DirectAddr>>> {
self.msock.direct_addresses()
/// This has no timeout, so if that is needed, you need to wrap it in a timeout.
pub async fn online(&self) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Should this handle going offline again? Like when the home relay is no longer reachable it should be pending again until there's another home relay?

The docs should probably also elaborate on when and how you might want to use the endpoint without being online, like mDNS or more manual scenarios.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Should this handle going offline again?

No, that would be very complex to do, will make it clear in the docs.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is it that complex? You only need a watcher on the home relay to implement this I think. If it's None: block. If it's Some(): return.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I would need to store boxed futures, and make a new type, and stuff and manually poll things..

@n0bot n0bot bot added this to iroh Sep 26, 2025
@github-project-automation github-project-automation bot moved this to 🏗 In progress in iroh Sep 26, 2025
@dignifiedquire dignifiedquire added this to the v0.99.0 milestone Sep 29, 2025
@github-actions
Copy link
Copy Markdown

github-actions bot commented Sep 29, 2025

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3467/docs/iroh/

Last updated: 2025-10-06T09:28:42Z

@github-actions
Copy link
Copy Markdown

github-actions bot commented Sep 30, 2025

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 2bf5ee7

@ramfox
Copy link
Copy Markdown
Member

ramfox commented Oct 3, 2025

Personal opinion - I think the online function only makes sense in the context of knowing you are accessible to the outside internet, and so should only return when we have a home relay available.

So my preference would be that this hangs forever if there is no relay available, even if there is no relay in the relay map. This will also make sense when we allow users to allow adding a relay dynamically (after the endpoint is created). We hang until a relay is added and we make a connection to that relay, and then online would return.

The question of whether this should be more like a watchable, that indicates going back offline...I can see someone wanting this or expecting this in the future, but I don't want to get farther away from what this method is supposed to be, which is porcelain for waiting for both the home_relay and direct_addresses. I'd rather solve this by documentation now (eg, "watch the watch_node_addr stream for any changes in conductivity"), and wait for someone to ask us for this.

@ramfox ramfox self-assigned this Oct 3, 2025
@ramfox ramfox modified the milestones: v1.0.0, v0.93.0 Oct 3, 2025
@dignifiedquire dignifiedquire added this pull request to the merge queue Oct 6, 2025
Merged via the queue into main with commit d815cae Oct 6, 2025
28 of 29 checks passed
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in iroh Oct 6, 2025
@dignifiedquire dignifiedquire deleted the feat-online branch October 6, 2025 10:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

5 participants