I agree: the links in the current UI presentation are sometimes confusing.
We need to think this a bit over to get all the functionalities we want into a clean UI:

It seems Phabricator reopened the task automatically with my last comment, that was not intended.

@moranegg , for the branch case the anchor will be the revision it points to. For your example, it will be

Just a question about using a path with a different branch, for example for a tag of a version (which is not a release):

• in this case, the anchor is the snp and the branch name (the tag) is in the path?

A few suggestion for the repository view:

1. I like the divided tabs, but in each tab, the context should be kept
2. In source code tab : context of the source code (SSC)
   • opencv\opencv\[dir-id] with snapshot date and branch
   • Also readme should be kept in the SSC tab
3. About metadata:
   • there is metadata in revision
   • there is deposited metadata for origin in the origin_metadata table
   • there is indexed metadata for origin
   • there will be metadata that can be associated to each artifact
   • A metadata tab is nice but will be very difficult to understand to which part of the repository the metadata is relevant,
     • show metadata as a separate button, as proposed in the task, is a temporary solution
     • we should reflect on this with the upcoming metadata additions (most registries, show metadata on the right, with several metadata functionalities, see Zenodo, HAL or SwMath)

seems so from the design ;-)

try again button, will it appear only for failed requests ?

In T2317#43088, @moranegg wrote:

In the sidebar menu I would keep the API access (unless it is accessible during the navigation - not on the landing page).
Also the access to the API on the side, is very small.

The behavior of the page:
I enter the link to the repository
click submit (which I suggest to change to save)
and there is a green box appearing below the form.

I think the reference here should be the vault page

From the design, there is also a change of colors on the visits page.

Great UX proposal not to interrupt the browsing with the download page.

Will you change Visit type into Origin type?
the former is more accurate, the latter is more comprehensible by someone that is not familiar with the data model.

I agree that a search box is a great way to keep the user engaged.
The text in the search box can be leading, here in the example we have Enter keyword, but the result is a search on the url, right?
If the search is the actual search on url:
Enter url
Enter repository
Search the archive

In the sidebar menu I would keep the API access (unless it is accessible during the navigation - not on the landing page).
Also the access to the API on the side, is very small.

This is now done in the few commits leading to https://forge.softwareheritage.org/rDMODaccca603c42ad68252532222ca6467a19691524e

@zack thanks for spotting the missing pieces... now fixed in the description, we're ready to go! :-)
Would you take care of extending the definition in https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html ?

@rdicosmo: the current version of the full example above LGTM (the surrounding text is inconsistent, e.g., it still mentions "snp" as a key and forbids snapshot anchors, but I suspect it's just that you didn't bother editing everything. Hence, we're good! :-))

Update the proposal with visit instead of snp

About the anchor point: no objection to having also shapshot as a possible anchor in the schema.

(removed the last point, the hierarchy thing is in fact not relevant here, as we're pointing upward, not downward)

LGTM in general.