no, it's not like that, lightning addresses also use this, it's borrowed from email and that was originally borrowed from ... i forget... maybe telnet

protocol://username:password@address

this is the basis of it, i think there is an RFC for it and all

in http, this has generally equated to username:password being parsed into http headers in some way in the request, iirc

for humans to read it, what you have proposed is fine, but for web servers you have to say where that username is going, and i say a path prefix is the simplest

you presumably would do it with subdirectories right? this is the standard for http file servers, and git servers are literally this, each subdiretctory.git is literally a folder, and inside it is what in the "not bare" version on your system when you "git clone" if you add the extra part `--bare` to the git clone command it puts it in the format that the http git service is expecting, on the client side

so you see what i'm saying, you have to define a route remapping, and for clarity of implementation, you should recommend a preferred method

aside from that, you can also use the nip-05 to decode a prefix, being the npub, which could be another option, but since you can't have more than one key in a json object with the exact same string, it's equally distinct as the hex pubkey, and human readable

just trying to get you to think about how it's implemented so the spec is not complicated, do it this way, or be retarded.

username@example.com has a standard implied meaning to put the username:password fields into headers in the actual request, the semantics are being muddled here that's what i'm trying to get you to consider, i think it's better to just do it as a subpath, but leave the actual URL how you are using it, web servers are webservers and maybe someone wants to implement this with some nginx configuration and your scheme doesn't make it clear where that username fits into it

the domain is an address, yes, but the username is a qualifier that has to be separated

you don't want to have issues with this:

nostr://lez@example.com/somerepo

conflicting with

nosttr://dave@example.com/somerepo

the domain is an address, yes, but the username is a qualifier that has to be separated

you don't want to have issues with this:

nostr://lez@example.com/somerepo

conflicting with

nosttr://dave@example.com/somerepo

sorry to disrupt the joy there i just did literally implement a nip05 feature in my fork of leproxy (which automates getting certs, i recently added the ability to add your own paid certs) and i understood how it worked at the abstract level for the domain, and how all of those name@ parts refer to a different user but they don't refer to a different name or address so the web server would need some other scheme to specify

perhaps it can be simply done with an automatic http-basic path resolution rather than a subpath as i am suggesting, maybe this is just "implementation details" but i think it's important to establish a standard practise

Is this list cached anywhere?

I can see that argument but some users are very used to setting the protocol in the git url. eg:

```

git remote set-url origin nostr://dan@gitworkshop.dev/identifier

git remote set-url --push origin nostr://nym1@ssh/npub/identifier

````

From ec99da472f7fd9678b10f95e2f55cc17f96f8e62 Mon Sep 17 00:00:00 2001

From: DanConwayDev

Date: Mon, 16 Dec 2024 13:17:43 +0000

Subject: [PATCH] docs: add FAQ with server protocol question

A question came up about the reason to specify git server protocol

and ssh user in the nostr git url format. this is an attempt to

answer it in a more holistic manner.

---

FAQs.md | 27 +++++++++++++++++++++++++++

1 file changed, 27 insertions(+)

create mode 100644 FAQs.md

diff --git a/FAQs.md b/FAQs.md

new file mode 100644

index 0000000..4a24bf4

--- /dev/null

+++ b/FAQs.md

@@ -0,0 +1,27 @@

+# FAQs

+

+## what protocol is used to interact with the git server(s) listed in the announcement event `30617`?

+

+Most Git servers support a variety of protocols, and it is the user's responsibility to specify which one to use in the Git remote URL.

+

+For a Nostr repository, the Git remote URL(s) are specified by the maintainer in the announcement event. These URLs may include a protocol that is not suitable for the user. For instance, if SSH is specified, the user may not have SSH keys configured for the Git server.

+

+Privacy-conscious users often prefer to use unauthenticated HTTP for read operations and SSH for write operations.

+

+The git-remote-nostr plugin is designed to increase the likelihood of success by disregarding the protocol specified by the maintainer and using the following approach. It attempts to use the following protocols for read operations:

+

+- Unauthenticated HTTP

+- SSH

+- Authenticated HTTP

+

+For write operations, it tries:

+

+- SSH

+- Unauthenticated HTTP

+- Authenticated HTTP

+

+If the first protocol attempted fails but a subsequent one succeeds, all future attempts will default to the successful protocol.

+

+Some users may prefer a different configuration, such as using SSH for both read and write operations. They can achieve this by specifying ssh in the Nostr Git URL: `nostr://ssh/dan@gitworkshop.dev/ngit`.

+

+Additionally, users may want to use non-default SSH keys. The user for non-default SSH keys can be specified in the Nostr Git URL: `nostr://nym1@ssh/npub123/identifier`. In this case, NIP05 addresses cannot be used.

--

libgit2 1.8.1