Outdated Version Notice

[Stebalien]

It would be great to print a notice to users when they're running an outdated version of go-ipfs. Luckily, we should be able to do this without deploying any new services or making any additional requests.

Instead, can just use the bootstrappers (i.e., "trusted nodes") to determine if we're out of date, no extra network communication required.

1. On start, register for connection events.
2. When we connect to a bootstrapper, check it's version.
3. If it's running a newer (non-RC) version, print a message.

Caveats:

• This won't work if we stop connecting to bootstrappers. However, we're likely to continue to try to connect to at least one bootstrapper when possible.
• We can't determine the latest release when we're testing an RC and/or custom build on a bootstrapper.

[Kubuxu]

Bitcoin has a notice system where there is a group of keys that can sign a message and this message will be propagated across the p2p network and displayed to users.

[lidel]

This was mentioned during stewards sync today, my thinking:

• We don't want to rely on bootstrappers too much: we want to use them only on initial bootstrap (Censorship resistant bootstrapping (e.g. for wikipedia) #3908, Saving previously seen nodes for later bootstrapping #3926), so can't use them for this reliably.
• Instead, we could detect when certain % of go-ipfs peers (Agent Version column from ipfs stats dht) use newer version and warn user that they should update to the latest version
  • this has very nice property of "not calling home" or producing any unnecessary DNSLink lookups for https://dist.ipfs.io/go-ipfs/ and does not impact private swarms, only public peers
• It needs to be WARNING printed to the stdout / logs of ipfs daemon
  • that way it will reach everyone, no matter what package manager / docker image is used etc
  • we could be very polite and allow for disabling new version check by setting ENV variable – but the default should always run this check

[BigLep]

I like this @lidel.

@schomatis : what do you think about implementing this?

[schomatis]

Yes, assigning.

[aschmahmann]

Instead, we could detect when certain % of go-ipfs peers (Agent Version column from ipfs stats dht) use newer version and warn user that they should update to the latest version

@lidel did you mean to specifically reference the DHT routing table (ipfs stats dht) since it has some basic sybil resistance going on, or did you just mean generally the user agents of all peers we're connected to, or even all peers we have information about in the peerstore.

These are all sort of manipulatable without some reasonably trustable mutability source (IPNS, DNSLink, HTTPS, bootstrappers, ...) although I guess there's not much to get out of it other than causing some confusion. Maybe we just want a wider pool here with which to gather update statistics from instead of something smaller like routing table size.

[lidel]

I meant nothing fancy tbh, just peers we are connected to at the moment would do, or (ideally) a bigger sample of peers we were connected to within last ~24h (if it is possible to get that info from the peerstore).

Realistically, we just want to know when new "stable" version appears on the network and gets popular enough (> some %).
This check would execute on startup (after bootstrapp) and then every 24h, and we show the WARNING only once (until user reboots their node).
Does not have to be perfect – if someone sybils our node with fake new version the only side-effect will be WARNING in logs.

[schomatis]

As mentioned in the DIscord thread I'll go over the routing table from that command. If I should do it differently please state it explicitly in this thread.

[lidel]

We are still observing significant lag in updates (source):

We've learned about big deployments which are packaging Kubo in docker images etc.

My suggestion for next step is to try to address it in Kubo 0.24:

• Pick up feat(cmds): add version check command #8839 or create a new PR
• Make it run the check every hour, and log warning about running outdated version every time
• Make sure message is loud, like the one in feat: warn users who are falling behind reprovides #9886 (emojis, multiline)
  • We don't want to break users, but we do want to annoy them into upgrading, or bothering the company that is responsible for bundling Kubo to updatede their docker image or app