Skip to content
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

Merged
merged 7 commits into from
Nov 30, 2021
Merged

feat: Addresses.AppendAnnounce #8177

merged 7 commits into from
Nov 30, 2021

Conversation

Jorropo
Copy link
Contributor

@Jorropo Jorropo commented Jun 6, 2021

Fixes: #7791
This needs: ipfs/go-ipfs-config#135 too (and the replace rule to be removed)

Copy link
Member

@lidel lidel left a 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)

@Jorropo
Copy link
Contributor Author

Jorropo commented Jun 26, 2021

@lidel I agree that my current proposal is bad.
But I don't like yours either, imagining myself as I noob I think : "wtf why is there 2 Announce ?"

Your solution doesn't make obvious that adding anything to Announce will remove auto detected addresses.
This could be solved by renaming Announce to OverwritingAnnounce but I have a better solution in mind.

Instead create a bool flag AnnounceAutodetectedAddresses, defaults to true, if true then append announces and auto detected addresses. (this is pretty much the same PR but with a rename)

@lidel
Copy link
Member

lidel commented Jul 6, 2021

I like the idea of self-describing flag AnnounceAutodetectedAddresses, pretty intuitive.

The only concern I have is that if we set it to true by default, then we effectively change the behavior of Announce for people who are already using it and expect it to only announce explicitly stated entries.

@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 AnnounceAutodetectedAddresses is set to false if Announce is not empty.

@lidel lidel mentioned this pull request Jul 6, 2021
@TheDiscordian
Copy link
Member

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":     [],

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).

Instead create a bool flag AnnounceAutodetectedAddresses, defaults to true, if true then append announces and auto detected addresses. (this is pretty much the same PR but with a rename)

I like this idea in spirit, but idk how I feel about changing the behaviour of Announce, I feel like that might introduce more confusion than the other proposal, and I'm not sure on how much benefit it'd bring.

@aschmahmann
Copy link
Contributor

@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 AnnounceAutodetectedAddresses is set to false if Announce is not empty.

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.

Copy link
Member

@lidel lidel left a 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.

@aschmahmann aschmahmann added the need/author-input Needs input from the original author label Jul 16, 2021
@Jorropo Jorropo requested a review from lidel July 19, 2021 02:18
@Jorropo
Copy link
Contributor Author

Jorropo commented Jul 19, 2021

@lidel I still think a bool flag is clearer but I get the point of automated systems.
I've made the changes as in the end having the option is what matter, not really how it's done.

I'll let to the one merging the PR cleaning up the replace rule in the go.mod (you have push access on that PR) when ipfs/go-ipfs-config#135 is merged.

Copy link

@texfu texfu left a comment

Choose a reason for hiding this comment

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

Thanks

@aschmahmann aschmahmann added need/maintainer-input Needs input from the current maintainer(s) and removed need/author-input Needs input from the original author labels Jul 30, 2021
@Jorropo Jorropo mentioned this pull request Aug 31, 2021
62 tasks
Jorropo and others added 2 commits November 15, 2021 14:56
- nat.go needs to use OptionalDuration
- libp2p config no longer use relay v1 setting
Copy link
Member

@lidel lidel left a 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:

fx.Provide(libp2p.SmuxTransport(cfg.Swarm.Transports)),
fx.Provide(libp2p.Relay(enableRelay, cfg.Swarm.EnableRelayHop)),
Copy link
Member

@lidel lidel Nov 15, 2021

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

@aschmahmann aschmahmann added the status/blocked Unable to be worked further until needs are met label Nov 19, 2021
@lidel lidel mentioned this pull request Nov 23, 2021
80 tasks
@lidel lidel changed the title feat: append annouces feat: Addresses.AppendAnnounce Nov 23, 2021
@lidel lidel added this to the go-ipfs 0.11 milestone Nov 23, 2021
@lidel lidel removed the status/blocked Unable to be worked further until needs are met label Nov 23, 2021
@lidel lidel removed the need/maintainer-input Needs input from the current maintainer(s) label Nov 23, 2021
@lidel
Copy link
Member

lidel commented Nov 23, 2021

Waiting for #8563 to land first.

core/node/libp2p/addrs.go Show resolved Hide resolved

appendAnnAddrs := make([]ma.Multiaddr, len(appendAnnouce))
for i, addr := range appendAnnouce {
appendAnnAddrs[i], err = ma.NewMultiaddr(addr)
Copy link
Contributor

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?

Copy link
Member

@lidel lidel Nov 30, 2021

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"

Copy link
Contributor Author

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

Copy link
Member

@lidel lidel Nov 30, 2021

Choose a reason for hiding this comment

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

Added deduplication in 9673571

@lidel lidel merged commit c2953ab into ipfs:master Nov 30, 2021
@lidel
Copy link
Member

lidel commented Nov 30, 2021

@Jorropo it is happening 🥳

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Append Announces
5 participants