yes, but that resolves only to an NPUB hex pubkey, not a URL
this is for a git-http service right? why leave this unclear, make an exact specification how the name goes into the path that is resolved, and it should be a path, not a subdomain, because not everyone has *cough* wildcard certs (and letsencrypt are bitches about ratelimiting)
The purpose of the nostr git URL is to locate the nostr repository. The git server(s) can chop and change overtime and can always be discovered via the nostr repository announcement event.
The nip05 address format is totally optional. You can use nostr://npub/relay-hint/identifier if you like.
i can't believe you don't get it
the URL format is fine, good
but the semantics of user@example.com is entirely dependent on the protocol, and it's two pieces, the router, and the server
how does the username relate to the nip-05 json and the - optionally - npub (the name is unique anyway) just define a mapping, and nobody screws it up
if you are gonna leave that thing open you are inviting trouble
but idk what to say
i ported a C implementation of the hamming code and i had a lot of trouble imputing the ACTUAL type that was being used by the compiler so that my code produced the same result, in Go, you don't implicit type casting, it has to be explicit
this is exactly the same kind of mental model issue you are demonstrating, typical C programmer, you have some mapping in your mind, but you won't say it
if you don't, have fun supporting irritated devs using more strict typed languages, you thought this evening was fun, hahaha i'm done, gonna sign off on this
don't just submit to the stupidity of arbitrary nonsense
recommend... in RFCs they use the SHOULD verb a lot for this case, meaning this is preferred because it maes implementation more clear and differences in implementation should be avoided if possible, because they lead to remapping errors, so define a standard mapping, and you will have no problems with people who want to use apache vs nginx or their own homespun golang or C http server
the git-http protocol is simply a http file protocol, it uses paths, natively
it's just a variant of what is done with SSH
the reason why i'm needling about the remapping is because i know this, and i know how http lets you remap to whatever, but leaving out stipulations in specifications leads to interop problems and you simply don't want that, idk how this is hard for you to understand
implicit things are fine in idiom so long as you can easily find them explicated
too often, they are not, and you have to dig around, read thousands of words that are not telling you the important point until you get to some fucking footnote that finally makes it clear
just please don't do that, make it simple, it's simple, why complicate it?
the @ syntax is good for people
but it's weird for http servers
I totally misunderstood the premise of this conversation. I think what you are saying is that nip05 is poorly consteucted and your making a mistake by using it. I though you need help understanding nip05 and how it fits into the nostr git URL scheme update. That supirsed me given the knowledge you have displayed elsewhere on nostr. Sorry for the confusion there.
