A couple of thoughts about IPNS republishing in 0.40 RC1

[Chara-Freedom]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

For last months I use ipns republishing via Kubo for my program. I have a Windows and Linux version of the same program, and republishing it only on Linux for both platforms, because it is easier in multiple aspects. There are downsides like increased weight because Kubo is not small but its not that big difference.

The 0.40 RC1 has built-in republishing, previously Kubo was connecting to someguy, this is how I previously did it and how it looks now, both with portable dependencies.

The pluses are obvious! The syntax is consistent, curl is no longer required, the operability of someguy is no longer required, the built-in functionality is much easier for mass-use.

So only three concerns that may be subject to change when 0.40 is released?

1. The changelog doc says that --force option is required only if the record is outdated or malformed. But my record was neither of this! You can see that I am just getting the fresh record then republishing it and do it several times for several records (so long ipns lists are possible). But without the force option I got this:

1. There is just a minor discrepancy I don't even know where exactly? And it occurred on a freshly generated, working record from an existent link. So it either should react not only on outdated or malformed records and the docs are misleading, or it's a bug.

2. The wording here is not very precise too. "Use --force to overwrite" - it is the get command that actually writes the record physically on your PC, not the put command. And I have two get commands, so my instincts were saying that the problem here is that the second get command sees the previous record and doesn't want to work; I tried --force option on both get commands, but Kubo said that its not a valid option. Only then I checked from changelog that you need to apply the --force command on put, that doesn't overwrite the existent record on your PC, but rather does this for the circulating record within the network. So we have the command that writes a physical file locally and the command that overwrites the file within the network. Even short clarification like "Use --force on put to overwrite" could be helpful.

3. Someguy was sending "HTTP/2 200" code after successful put. Kubo 0.40 RC1 doesn't do this. The success code is very useful I don't need to explain it, but Kubo doesn't have it. So maybe add some message after successful putting.

Those are not critical they are more about design, maybe there is something I miss. Anyway, great work, great update, thank you very much!

[Chara-Freedom]

@lidel @gammazero

[lidel]

Thank you for testing this and quick RC1 feedback @Chara-Freedom

Allowing multiple puts of the same valid record (byte-for-byte) is sensible quality of life improvement, this and message fixed in #11199 (also added short message on success).

As for HTTP 200, Kubo RPC at /api/v0/name/put returns HTTP 200 on success, I assume you meant lack of any text printed on CLI stdout. This is sensible, added that on the PR too. Give it a try (or wait till next release):

• fix: improve ipfs name put for IPNS record republishing #11199