feat: iroh-next server-side connectivity and iroh server side migration#8400
Draft
dpc wants to merge 6 commits intofedimint:masterfrom
Draft
feat: iroh-next server-side connectivity and iroh server side migration#8400dpc wants to merge 6 commits intofedimint:masterfrom
dpc wants to merge 6 commits intofedimint:masterfrom
Conversation
dpc
force-pushed
the
dpc/jj-uxtvnmvykwxl
branch
from
61821d7 to
ed71cde
Compare
…h-next fields
- Rename insert_signed_guardian_metadata_if_not_present to
update_signed_guardian_metadata: always rebuild metadata from config,
compare tagged_hash with existing, and only write+return true when
changed. Ensures metadata stays current across restarts.
- Add optional iroh_next_version and iroh_next_endpoint fields to
GuardianMetadata (serde default + skip_serializing_if for backward
compat). Populated from broadcast key derivation when iroh-next is
enabled at runtime.
- Add IROH_NEXT_VERSION constant ("0.90") to broadcast_keys module.
- Disable iroh-next in ConnectorRegistry when running in test/devimint
environments (no iroh-next server endpoints available).
When a guardian publishes iroh_next_version and iroh_next_endpoint in its metadata, and the client supports the same iroh-next version, rewrite iroh:// URLs to use the iroh-next node ID directly. This avoids dual-stack racing and connects via the preferred iroh-next stack. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Aligns the server-side env var naming with the client-side convention (FM_IROH_<thing>_<action>). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dpc
force-pushed
the
dpc/jj-uxtvnmvykwxl
branch
from
ed71cde to
1f466c9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
slop warning: straight of out slop machine, I need to think a bit more about it and review it properly. Don't waste your time just yet.
I don't think we really thought through server side iroh migration. Once iroh 1.0 is available, how are we going to coordinate upgrading to it? We are going to need the server side to run dual stack somehow, and clients to know when and how to connect.
Also we are lagging behind already using semi-stable Iroh 0.35 which is missing a lot of improvements.
It occurred to me that with recently GuardianMetadata we have a freedom of announcing whatever we want, and we can update it easily too.
So why wouldn't we put the exact version of iroh-next that the server side is using, along with a endpoint to connect to, and make the client use it instead of old-Iroh if they have the same version?
TODO: