-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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.
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
feat: Addresses.AppendAnnounce #8177
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @Jorropo for tackling this!
I spent some time trying to empathize with a novice user and think that an explicit list feels better than a boolean flag.
Compare below example:
"Announce": [],
"AppendAnnounce": ["/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"],
"NoAnnounce": [],
"Announce": ["/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"],
"AppendAnnounce": [],
"NoAnnounce": [],
vs
"Announce": ["/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"],
"AppendAnnounce": false,
"NoAnnounce": [],
"Announce": ["/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ"],
"AppendAnnounce": true,
"NoAnnounce": [],
Second one is really confusing without reading the docs.
Easy to imagine user thinking "is Annouce setting disabled?" "Do I need to flip it to true?"
I suggest switching to an explicit string[]
, as it is both less ambiguous and takes less space visually when empty.
(cc @aschmahmann @Stebalien in case they feel otherwise)
@lidel I agree that my current proposal is bad. Your solution doesn't make obvious that adding anything to Instead create a |
I like the idea of self-describing flag The only concern I have is that if we set it to @aschmahmann do we have ability to do config migrations as part of usual repo migrations? If so, we could do one time 9-to-10 migration where |
I love this, very explicit and intuitive. Personally I think if the empty fields are included in the config, it will be quite obvious what these do (though tbh it'd be nice if we could add comments to the config).
I like this idea in spirit, but idk how I feel about changing the behaviour of |
We can do config migrations as part of a repo migration (or even just have two back-to-back migrations). Writing migrations should be much easier given the recent refactoring, but there are still tradeoffs around deployment/when we do the migrations. I don't have particularly strong feelings here about whether it's more intuitive for users if we change the option names to make them clearer (and make users relearn the names) vs just adding fields. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Jorropo we discussed this during triage and:
- Changing the default behavior of
Announce
array is not acceptable: too many unknowns.
I could introduce silent bugs in automated deployments where empty repo is initialized using some predefined template etc. But there are most likely unknown unknowns as well. - Without changing the default behavior of
Annouce
proposed config is more confusing than separate array. - Due to this, we can accept this PR if it is refactored to add separate
AppendAnnounce
array (as suggested in my original comment).
This is the best way, as it is additive and easy to document.
@lidel I still think a bool flag is clearer but I get the point of automated systems. I'll let to the one merging the PR cleaning up the replace rule in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
- nat.go needs to use OptionalDuration - libp2p config no longer use relay v1 setting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @Jorropo and apologies for keeping this out in cold for so long.
Did a quick pass and finished remaining work and checks:
- rebased
- docs
- tests
@aschmahmann fysa this LGTM, but needs two things before merge:
- go-ipfs-config with feat: add Addresses.AppendAnnounce go-ipfs-config#135
- WIP: update go-libp2p to v0.16.0 #8522 to land first, to avoid the headache of dealing with go-ipfs-config changes.
core/node/groups.go
Outdated
fx.Provide(libp2p.SmuxTransport(cfg.Swarm.Transports)), | ||
fx.Provide(libp2p.Relay(enableRelay, cfg.Swarm.EnableRelayHop)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ℹ️ this is ok because EnableRelayHop
was removed in ipfs/go-ipfs-config#146 and won't be used when #8522 lands
Waiting for #8563 to land first. |
core/node/libp2p/addrs.go
Outdated
|
||
appendAnnAddrs := make([]ma.Multiaddr, len(appendAnnouce)) | ||
for i, addr := range appendAnnouce { | ||
appendAnnAddrs[i], err = ma.NewMultiaddr(addr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the intended behavior if both announce and appendannounce are set? Do we just need to quietly ensure that we don't duplicate addresses, but that otherwise it's fine to set both fields?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe deduplicating should be enough (if libp2p does not do that already?)
My mental model is:
Announce
is "ignore infered ones, use these"AppendAnnounce
is "add these to the final list, no matter if static or inferred"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the same thing as @lidel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added deduplication in 9673571
@Jorropo it is happening 🥳 |
Fixes: #7791
This needs: ipfs/go-ipfs-config#135 too (and the
replace
rule to be removed)