{ "id": "741db7cc8c2fffcd035aff4f9e87e13bb2d3ff810199488c1bd88a2fc0be9b6c", "pubkey": "a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d", "created_at": 1725224160, "kind": 1622, "tags": [ [ "e", "a5b6fda137d6a523b3423ee2f0169104409ab60e8b4d6807a8fda67ee47b9e45", "", "root" ], [ "p", "8685ebef665338dd6931e2ccdf3c19d9f0e5a1067c918f22e7081c2558f8faf8" ], [ "a", "30617:a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d:ngit" ], [ "r", "`git@example.com" ], [ "alt", "a git issue reply" ] ], "content": "I thought a `git://` URL uses the native git transport which is unauthenticated and unencrypted, whereas `ssh://` or `git@example.com:user/repo` formats use ssh?\n\nI noticed the problem of a lot of nostr repos advertising their git servers with ssh 'clone' urls and git-remote-nostr failing to clone as fetches via ssh require authentication. \n\nOf course, fetched should be auth for a private repo and some git servers dont even offer https. So the helper can't force all fetches through https. Also some like to auth over https so all pushes can't be via ssh.\n\nThe solution I implemented in v1.4.5 for https/ssh was to try over the protocol specified in the repo event and if it failed, try again with over the other protocol.\n\nSo if you change the clone URL in your repo event with `ngit init` to ssh/https, your pushes should succeed. Its ineligant though because it willl, in either the pull or fetch scenario, try over an undesirable protocol first.\n\nI could add a protocol parameter to the URL so the user could specify the desired protocol and use a different one for fetch and push?\n\nThe tools should also nudge maintainers to use the desires fetch URL in the repo announcement event.", "sig": "34e185b4c6da48944d9145154b2f45e82bf5dfbe39ac040a294d621ac7b8f6967e588d4be2150ef29224609307d64ee7abaec9d961e3e6aee93d33a31a0b9f70" }