Protocol relative URLs are highly discouraged. As such IABot fixes them to the proper and recommended protocol.

See Wikipedia:Protocol-relative URL, which holds true for all Wikimedia projects.

For more insight, see e.g. this blog post.

In T199846#4433316, @Tacsipacsi wrote:

@Cyberpower678 Where is it stated? Anyways, the edit summary is wrong: it says it added an archive for a rotten link, but it’s not true, as exactly the same archive link was already there.

Cirdan, sum it up quite nicely why Protocol-relative URLs should be frowned upon. As for the edit summary, I don't speak the language, so I don't know what it was translated into. The original language, claims that the URL is rescued. This word was chosen carefully as rescuing a URL can mean fixing its archive URL, adding one, or removing a dead link tag from the original if it's not dead.

In T199846#4434913, @Cirdan wrote:

See Wikipedia:Protocol-relative URL, which holds true for all Wikimedia projects.

While protocol-relative URLs may cause problems if used incorrectly (americanbilliardclub.com) or in edge cases (//archive.org appearing in article text, i.e. not in link target, as that’s converted to HTTPS when printed, at least in Firefox 61, Chrome 67 and Internet Explorer 11), I see neither large-scale problems, nor significant community support behind it (about removing protocol-relative URLs is only the June 2017 discussion, where exactly three people commented on the topic within six hours, and was abandoned after that).

For more insight, see e.g. this blog post.

It’s about resources loaded with a protocol-relative URL on HTTP sites, as opposed to our situation with protocol-relative simple links on an HTTPS site. While some parts may be relevant at protocol-relative simple links on an HTTP site, not on HTTPS.

In T199846#4435730, @Cyberpower678 wrote:

As for the edit summary, I don't speak the language, so I don't know what it was translated into. The original language, claims that the URL is rescued. This word was chosen carefully as rescuing a URL can mean fixing its archive URL, adding one, or removing a dead link tag from the original if it's not dead.

The Hungarian summary is nothing like that, it’s only about adding an archive. And I have no idea how to translate it correctly—words with such complex meanings are better to be avoided in texts to be localized, as they are likely to cause problems while translating. Maybe you should split the edit summary to different actions. And not change working archive URLs—the community voted on enabling a bot that adds archive links, not one that makes seemingly random changes in connection with such links. If we want to change protocol-relative archive.org links to fixed HTTPS, we have plenty of bots that can do this, this is quite an easy task.

Well IABot does have options that manage normalizing archive URLs. I can disable them. It think converting to absolute urls is part of the normalization process.

I’ve disabled the features. They should take effect soon.