For the time being we do not want to leak origin PIDs to the world, as they're not intrinsically computable on the origin itself (but only on the URLs, which is not the artifact itself, which is not digital, but just a locator for it). Let's consider ori PIDs only an internal shorthand useful in places where having fixed-length shorthands for full URLs is needed (e.g., swh-graph).

The archive.internal.softwareheritage.org cert is now valid (via rSPSITEbdddd7804bbb).

(I'm dubious about the high priority of this task; Guix has changed their code for the new API)

Turns out this was due to a left-over username/password in my ~/.netrc, which apparently requests uses by default and curl doesn't.
(But why the heck the caching effect? I've no idea...)

Actually, the observed dates discrepancy was due to the fact that the SWH snapshot was too old (08/10/2109) and not in sync with the current repository state on GitHub.
So the author date was not yet modified to the real release date of the software.

Also for me, it is not a problem, just two way of displaying the same info;

Maybe "This might be resolved with T2146 ?" - T2149 is this one :)...
Anyway .. No, even if T2146 is resolved, this is unrelated.
Actually the link in this issue https://archive.softwareheritage.org/badge/origin/https://github.com/Unipisa/TAUmus/ was already correctly responding .. as the software was already archived...

In T2147#39796, @anlambert wrote:

@zack, this is now deployed to production.

This might be resolved with T2149 ?

@zack, this is now deployed to production.

@scatenag , issue fixed and deployed. Thanks for reporting it !

Darn, sorry, I've looked for a dupe before submitting, but I obviously failed at that. Thanks for closing the duplicate.

I think I understand what's wrong here. Github will not render a badge if the associated HTTP request to get the image data does not return a 200 status code.
As the badge endpoint returns a 404 error code when an origin is not archived, the error badge is not displayed.
I will fix that behavior and deploy a new version of swh-web during the afternoon.

Well .. It is a strange behavior .. possibly related to GitHub ..

I am confused because this is already implemented. I just tested again and I got exactly the badge posted above when the origin is not found in the archive.

The first part seems wrong indeed.

Following up the F2F discussion we had yesterday on this with @olasd and @anlambert, I've thought back at @olasd question on whether I really need to access the Web UI via the public IP address.