proxy to nex protocol?

[d47081]

Hello, can I setup the upstream located at nex protocol?

[omar-polo]

I don't know the nex protocol, so probably not. The proxy facility only supports gemini and gemini-without-tls (which is not a proper protocol but in practice it can be useful.)

Can you share a link to a page describing the protocol?

Thanks!

[d47081]

It is same protocol to Gopher/Gemini, but without redirects, status codes, and other meta.

It also does not require domain / TLS / SNI so pretty useful for encrypted alt networks like yggdrasil, where addressation usually just 0200::/7 and certificate is extra-layer for traffic that already encrypted.

For example I run every my service on yggdrasil servers (in localnet) and proxy to internet using gmid.

• gemini://kvazar.duckdns.org/
• gemini://kevachat.duckdns.org/ ...

I must to make cert for each instance, even cert wanted just for gmid proxy outpoint.

Protocol details here:

• https://nightfall.city/nex/info/
• https://nightfall.city/nps/info/ - something like Titan for Gemini

I have few solutions already written in PHP

• nex-php - PHP 8 / Composer Library for NEX Protocol
• nps-php - PHP 8 / Composer Library for NPS Protocol
• next - Server in PHP 8 for Nex Protocol as the alternative to nextd

Nex also supported by Lagrange browser so don't think this protocol is rare and pretty new

[omar-polo]

Oh, interesting. This protocol went under my radar :)

Upon a quick look it seems like adding support for it will be very easy (easier than #23 for sure :p). I just have a few doubts/questions open:

• as far as I'm seeing, if the path terminates with "/" we can assume it's a directory listing, so we can serve it as "text/gemini" ?
• what do we use for the mime type? As far as i can see, we don't know the content of the response, so we'll have to guess? Maybe if there are no NUL bytes in the first n bytes we can serve it as text/plain, and application/octet-stream otherwise?

[d47081]

I'm still learning this protocol by development those solutions.

As understand:

• the slash at the end interpretation depending from client to care about. Just make sure that is dir on server-side.
• mime type detected from the file extension. for example I host .gmi and open it using nex protocol in Lagrange without any problems. just one moment - the index files (at the host root) ident as the plain text by default, because no extension given and no way to get it from headers. could be fixed by changing default mime type in browser I suppose.

[omar-polo]

Ah I see. Maybe we can even re-use gmid' built-in mime types for this.

[d47081]

Thoughts make same for next server, but how to make browser know that is gemtext without the headers?

The client-side only - default mime option or the markup detection, no server-side way :)

[d47081]

Thought, if you just make gmid able to pass the nex responses as is, there would be no problem with gemtext interpretation, because proxy has gemini:// at the protocol scheme.

Just pass the raw data with required for gemini protocol headers, maybe as the config option.

btw, still dream about same feature for #23

[d47081]

I also don't understand subject with / at the address ending.

Maybe protocol author is just Windows user where directories and files with same name possible to store in same location

[d47081]

Found that nginx able to forward both NEX/NPS connections as TCP stream:

# /etc/nginx/nginx.conf

stream {
        server {
                listen 1915;
                proxy_pass 127.0.0.1:1915;
        }
}

https://github.com/kevachat/npsapp#nginx

[omar-polo]

Yeah, if the intention is to just forward the connection to a specific backend then a dedicated daemon like relayd, haproxy or even nginx is probably better.

I don't think it would be a good move for gmid to become capable of proxy random data, it's not designed for that. There are better options for that.

What I think could be worthwhile, although i'm still a bit undecided, if it could make sense to use gmid to proxy/convert other protocols to gemini. So that it can be used to make available nex:// pages from gemini://, or like proposed in #23 to fetch content via http and serve it via gemini.