@civodul I wanted to raise the topic of storing container metadata (in the style of what tools like pristine-tar do) here too, so thanks for giving me the chance :-)
I agree it might be a technical solution, *but*, I'm not sure I see the point.
Didn't you agree that having a "lookup service" from tarball/container checksums to SWHIDs (the Software Heritage identifiers, that can then be used to lookup stuff in the archive) would be enough to satisfy distro needs?
If yes, then "archiving container metadata" could be replaced by simply having a way to add entries to the lookup table. And allowing distros to do so is option that we can explore. (Once the service exists, of course.)

I suspect when this task was initially submitted we didn't have yet SWHID with qualifiers :)
From the point of view of the APIv2, given v1 was using only hashes, for feature parity we should indeed only need SWHID without qualifiers, i.e., "core" SWHIDs. (I'm gonna edit the task description to reflect that.) Thanks for noticing this!

In D3293#81350, @vlorentz wrote:

@zack How do you feel about the minified bootstrap code?

as a related data point, the current graph export code applies the following heuristic to decide which outbound edges from snapshot nodes to emit:

• keep branch names starting with refs/heads/
• keep branch names starting with refs/tags/
• drop everything else

thumbs up for a dedicated permission for API throttling, thanks !

@lewo it's used in our DB but also exposed in the swh-web UI in search results (and in the future it is going to be also be a field for user searches, so that you can search, e.g., "emacs" only in the list of packages archived from a given origin type).

In D3293#80514, @vlorentz wrote:

• I don't think adding an external dependency (the .css) is a good idea (it might change or disappear). But this file doesn't seem to have a license so we probably can't bundle it either (ping @zack )

In T2451#45441, @anlambert wrote:

Possible solutions are:

• We create the newsletter for each supported languages and send it directly from WordPress through the Newsletter plugin.

In T1352#45459, @lewo wrote:

So, we can now consider the sources.json file format as stable and you could make the required changes on your sources.json file. A new SHW origin should then be added.

Making explicit a direct answer to one of @lewo's question (hinted at by both @olasd and @rdicosmo): no, we do not want a new type of SWHID (swh:1:tar:...) for source code containers, which from our point of view are ephemeral.

Yeah, for having played with it quite a bit in recent times, the current state of timestamp offsets isn't great. I'm fine with the idea of switching them to bytestrings as proposed.

Another option is to simply drop this method from the public Web API, and keep the revision graph visit logic only in swh-web (the UI). If users want to do a full visit of the revision graph they can use /revision and implement the visit policy they want. (I've suggested this design consideration for API v2 in T1805.)

FWIW we have discussed already a related aspect in T1805 ("Use SWH PIDs whenever possible"). There it was only for the Web API, but it seems wise to do the same for /browse/ URLs too.

The webapp then enables to browse a content from each computed checksum using the following URL: /browse/content/(algo):(hash)/

duplicate of T2420

In T1832#44514, @moranegg wrote:

New use case for this mailing list:
announcing changes like in T2398

In D3154#76782, @vlorentz wrote:

for the context, we need to use the SHWIDs themselves, not the sha1_git that is bound to version 1 of SWHIDS

What's the difference? When we'll use something other than sha1_git we'll just migrate this data with the rest.

Question: can we support both context-full and context-less metadata for arbitrary artifacts?

Given Wikidata software properties already contains "source code repository" URLs, shouldn't we work on our side to make sure those URLs resolve to corresponding origin URLs, rather than adding yet another property (very similar to "source code repository") on their side?