What happens
gl repo create prints a View: URL that 404s for any repo not hosted on node.gitlawb.com.
Creating a repo against a self-hosted node:
$ GITLAWB_NODE=https://origin.gitlawb.com gl repo create my-repo
✓ Created repository: my-repo
Clone: git clone gitlawb://did:key:z6Mk…/my-repo
HTTP: https://origin.gitlawb.com/z6Mk…/my-repo.git
View: https://gitlawb.com/z6Mk…/my-repo ← 404
Clone: and HTTP: are both correct and both work. View: is built against gitlawb.com regardless of which node the repo was just created on:
https://gitlawb.com/<did>/<repo>
→ 307 → https://explorer.gitlawb.com/repos/<did>/<repo>
→ 404
The explorer is backed by the main network, so it can only resolve repos that node knows about. Confirmed by asking each node directly for the same repo:
| node |
/api/v1/repos/<did>/<repo> |
origin.gitlawb.com |
200 |
node.gitlawb.com |
404 |
node2.gitlawb.com |
404 |
node3.gitlawb.com |
404 |
Why it matters
This is the first thing a self-hosting operator sees after their first successful command, and it is the one line of the three that is wrong. The failure is also silent in the unhelpful direction: the URL is well-formed and the 307 makes it look like it resolved somewhere real, so the natural conclusion is "my repo did not get created" rather than "this link was never going to work".
Anyone posting or sharing that link — which is what a View: line invites — shares a 404.
Two things tangled together
-
The URL is unconditional. View: should be derived from the node the repo was created on, or omitted when that node has no known web view. Printing a link to a service that cannot see the repo is worse than printing nothing.
-
origin.gitlawb.com has no peers, so nothing it hosts can propagate anywhere the explorer could find it:
$ curl https://origin.gitlawb.com/api/v1/peers
{"count":0,"peers":[]}
That may be intentional for that particular node, but it means (1) is not a display bug alone — there is genuinely no URL that would work for this repo today. Worth deciding separately whether that node should be peered and added to bootstrap-peers.json.
Suggested direction
For (1): only print View: when the target node is one with a known web view — or make the web view host a property the node advertises on GET /, alongside did and version, and print the line only when the node supplies one. That keeps the CLI from hardcoding a topology it cannot verify.
Environment
gl @ fad75a6, reports gl 0.7.1
- node
origin.gitlawb.com, v0.7.1, network: alpha
What happens
gl repo createprints aView:URL that 404s for any repo not hosted onnode.gitlawb.com.Creating a repo against a self-hosted node:
Clone:andHTTP:are both correct and both work.View:is built againstgitlawb.comregardless of which node the repo was just created on:The explorer is backed by the main network, so it can only resolve repos that node knows about. Confirmed by asking each node directly for the same repo:
/api/v1/repos/<did>/<repo>origin.gitlawb.comnode.gitlawb.comnode2.gitlawb.comnode3.gitlawb.comWhy it matters
This is the first thing a self-hosting operator sees after their first successful command, and it is the one line of the three that is wrong. The failure is also silent in the unhelpful direction: the URL is well-formed and the 307 makes it look like it resolved somewhere real, so the natural conclusion is "my repo did not get created" rather than "this link was never going to work".
Anyone posting or sharing that link — which is what a
View:line invites — shares a 404.Two things tangled together
The URL is unconditional.
View:should be derived from the node the repo was created on, or omitted when that node has no known web view. Printing a link to a service that cannot see the repo is worse than printing nothing.origin.gitlawb.comhas no peers, so nothing it hosts can propagate anywhere the explorer could find it:That may be intentional for that particular node, but it means (1) is not a display bug alone — there is genuinely no URL that would work for this repo today. Worth deciding separately whether that node should be peered and added to
bootstrap-peers.json.Suggested direction
For (1): only print
View:when the target node is one with a known web view — or make the web view host a property the node advertises onGET /, alongsidedidandversion, and print the line only when the node supplies one. That keeps the CLI from hardcoding a topology it cannot verify.Environment
gl@fad75a6, reportsgl 0.7.1origin.gitlawb.com, v0.7.1,network: alpha