#nexprotocol — Public Fediverse posts

How to use #nexprotocol from #CLI

1) telnet 202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148 1900
2) enter / (public root)
3) get result (end of session)

same principle for #nc; read more:

telnet nightfall.city 1900
/nex/info/specification.txt

How to use #nexprotocol from #CLI

1) telnet 202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148 1900
2) enter / (public root)
3) get result (end of session)

same principle for #nc; read more:

telnet nightfall.city 1900
/nex/info/specification.txt

How to use #nexprotocol from #CLI

1) telnet 202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148 1900
2) enter / (public root)
3) get result (end of session)

same principle for #nc; read more:

telnet nightfall.city 1900
/nex/info/specification.txt

Testing our #nexprotocol server with few services - flarumdown, podcast, user blogs:

nex://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]/ - #Yggdrasil
nex://[505:6847:c778:61a1:5c6d:e802:d291:8191]/ - #Mycelium
nex://sl5ddrkufwd37xbbf4bj7542qljtnwe6pzd54epqg6zfytkj7q5a.b32.i2p/ - #I2P

By the way:

#Nexy server v.0.6.0 release with enhanced Cyrillic listing support (https://crates.io/crates/Nexy)

#Yoda browser v0.12.12 release is now support #Markdown renderer for #Nex driver (https://crates.io/crates/Yoda)

Testing our #nexprotocol server with few services - flarumdown, podcast, user blogs:

nex://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]/ - #Yggdrasil
nex://[505:6847:c778:61a1:5c6d:e802:d291:8191]/ - #Mycelium
nex://sl5ddrkufwd37xbbf4bj7542qljtnwe6pzd54epqg6zfytkj7q5a.b32.i2p/ - #I2P

By the way:

#Nexy server v.0.6.0 release with enhanced Cyrillic listing support (https://crates.io/crates/Nexy)

#Yoda browser v0.12.12 release is now support #Markdown renderer for #Nex driver (https://crates.io/crates/Yoda)

Testing our #nexprotocol server with few services - flarumdown, podcast, user blogs:

nex://[202:68d0:f0d5:b88d:1d1a:555e:2f6b:3148]/ - #Yggdrasil
nex://[505:6847:c778:61a1:5c6d:e802:d291:8191]/ - #Mycelium
nex://sl5ddrkufwd37xbbf4bj7542qljtnwe6pzd54epqg6zfytkj7q5a.b32.i2p/ - #I2P

By the way:

#Nexy server v.0.6.0 release with enhanced Cyrillic listing support (https://crates.io/crates/Nexy)

#Yoda browser v0.12.12 release is now support #Markdown renderer for #Nex driver (https://crates.io/crates/Yoda)

The nex-protocol specification is very short.

https://nex.nightfall.city/nex/info/specification.txt

#nex #NexProtocol #SmallNet #SmallWeb

The nex-protocol specification is very short.

https://nex.nightfall.city/nex/info/specification.txt

#nex #NexProtocol #SmallNet #SmallWeb

The nex-protocol specification is very short.

https://nex.nightfall.city/nex/info/specification.txt

#nex #NexProtocol #SmallNet #SmallWeb

The nex-protocol specification is very short.

https://nex.nightfall.city/nex/info/specification.txt

#nex #NexProtocol #SmallNet #SmallWeb

The nex-protocol specification is very short.

https://nex.nightfall.city/nex/info/specification.txt

#nex #NexProtocol #SmallNet #SmallWeb

PostFreely Update (2023-10-01)

https://flamewar.social/post/2579

#PostFreely #WriteFreely #blogdom #blogosphere #blogoverse #gopher #gopherProtocol #gemini #GeminiProtocol #gemtext #nex #nexProtocol #finger #fingerProtocol #smallnet #smolnet #smallweb #smolweb

PostFreely Update (2023-10-01)

https://flamewar.social/post/2579

#PostFreely #WriteFreely #blogdom #blogosphere #blogoverse #gopher #gopherProtocol #gemini #GeminiProtocol #gemtext #nex #nexProtocol #finger #fingerProtocol #smallnet #smolnet #smallweb #smolweb

PostFreely Update (2023-10-01)

https://flamewar.social/post/2579

#PostFreely #WriteFreely #blogdom #blogosphere #blogoverse #gopher #gopherProtocol #gemini #GeminiProtocol #gemtext #nex #nexProtocol #finger #fingerProtocol #smallnet #smolnet #smallweb #smolweb

PostFreely Update (2023-10-01)

https://flamewar.social/post/2579

#PostFreely #WriteFreely #blogdom #blogosphere #blogoverse #gopher #gopherProtocol #gemini #GeminiProtocol #gemtext #nex #nexProtocol #finger #fingerProtocol #smallnet #smolnet #smallweb #smolweb

PostFreely Update (2023-10-01)

https://flamewar.social/post/2579

#PostFreely #WriteFreely #blogdom #blogosphere #blogoverse #gopher #gopherProtocol #gemini #GeminiProtocol #gemtext #nex #nexProtocol #finger #fingerProtocol #smallnet #smolnet #smallweb #smolweb

You can tell if the whole file was downloaded using the HTTP-protocol by using the Content-Length header.

I think the creators of the nex-protocol, gemini-protocol, and other similar protocols felt something like that was too complex.

I wonder if using the ␄ control character to mark the end of the file was considered.

End of Transmission (␄) = 0x04

And used ␛ control character to escape when ␄ (or ␛) appeared in the data.

Escape (␛) = 0x1B

#nex #nexProtocol #gemini #geminiProtocol

You can tell if the whole file was downloaded using the HTTP-protocol by using the Content-Length header.

I think the creators of the nex-protocol, gemini-protocol, and other similar protocols felt something like that was too complex.

I wonder if using the ␄ control character to mark the end of the file was considered.

End of Transmission (␄) = 0x04

And used ␛ control character to escape when ␄ (or ␛) appeared in the data.

Escape (␛) = 0x1B

#nex #nexProtocol #gemini #geminiProtocol

You can tell if the whole file was downloaded using the HTTP-protocol by using the Content-Length header.

I think the creators of the nex-protocol, gemini-protocol, and other similar protocols felt something like that was too complex.

I wonder if using the ␄ control character to mark the end of the file was considered.

End of Transmission (␄) = 0x04

And used ␛ control character to escape when ␄ (or ␛) appeared in the data.

Escape (␛) = 0x1B

#nex #nexProtocol #gemini #geminiProtocol

You can tell if the whole file was downloaded using the HTTP-protocol by using the Content-Length header.

I think the creators of the nex-protocol, gemini-protocol, and other similar protocols felt something like that was too complex.

I wonder if using the ␄ control character to mark the end of the file was considered.

End of Transmission (␄) = 0x04

And used ␛ control character to escape when ␄ (or ␛) appeared in the data.

Escape (␛) = 0x1B

#nex #nexProtocol #gemini #geminiProtocol

You can tell if the whole file was downloaded using the HTTP-protocol by using the Content-Length header.

I think the creators of the nex-protocol, gemini-protocol, and other similar protocols felt something like that was too complex.

I wonder if using the ␄ control character to mark the end of the file was considered.

End of Transmission (␄) = 0x04

And used ␛ control character to escape when ␄ (or ␛) appeared in the data.

Escape (␛) = 0x1B

#nex #nexProtocol #gemini #geminiProtocol

One nice thing about the nex-protocol is —

The response is the actual file. You don't need to do any decoding. So it is simple.

One cost of this is —

In general, you cannot tell if you actually received the whole file or not. You don't know, for example, if the network connection died before you received the whole file.

(This is also a problem with the gemini-protocol.)

#nex #nexProtocol

One nice thing about the nex-protocol is —

The response is the actual file. You don't need to do any decoding. So it is simple.

One cost of this is —

In general, you cannot tell if you actually received the whole file or not. You don't know, for example, if the network connection died before you received the whole file.

(This is also a problem with the gemini-protocol.)

#nex #nexProtocol

One nice thing about the nex-protocol is —

The response is the actual file. You don't need to do any decoding. So it is simple.

One cost of this is —

In general, you cannot tell if you actually received the whole file or not. You don't know, for example, if the network connection died before you received the whole file.

(This is also a problem with the gemini-protocol.)

#nex #nexProtocol

One nice thing about the nex-protocol is —

The response is the actual file. You don't need to do any decoding. So it is simple.

One cost of this is —

In general, you cannot tell if you actually received the whole file or not. You don't know, for example, if the network connection died before you received the whole file.

(This is also a problem with the gemini-protocol.)

#nex #nexProtocol

One nice thing about the nex-protocol is —

The response is the actual file. You don't need to do any decoding. So it is simple.

One cost of this is —

In general, you cannot tell if you actually received the whole file or not. You don't know, for example, if the network connection died before you received the whole file.

(This is also a problem with the gemini-protocol.)

#nex #nexProtocol

I like the nex-protocol.

I wish it supported (as part of the protocol) imperative-verbs like HTTP has.

(For example, HTTP has the imperative-verbs — DELETE, GET, HEAD, PATCH, POST, PUT, PATCH, etc.)

(The finger-protocol also has imperative-verbs — although only one was defined in the specification — "/W")

#nex #nexProtocol

I like the nex-protocol.

I wish it supported (as part of the protocol) imperative-verbs like HTTP has.

(For example, HTTP has the imperative-verbs — DELETE, GET, HEAD, PATCH, POST, PUT, PATCH, etc.)

(The finger-protocol also has imperative-verbs — although only one was defined in the specification — "/W")

#nex #nexProtocol

I like the nex-protocol.

I wish it supported (as part of the protocol) imperative-verbs like HTTP has.

(For example, HTTP has the imperative-verbs — DELETE, GET, HEAD, PATCH, POST, PUT, PATCH, etc.)

(The finger-protocol also has imperative-verbs — although only one was defined in the specification — "/W")

#nex #nexProtocol

I like the nex-protocol.

I wish it supported (as part of the protocol) imperative-verbs like HTTP has.

(For example, HTTP has the imperative-verbs — DELETE, GET, HEAD, PATCH, POST, PUT, PATCH, etc.)

(The finger-protocol also has imperative-verbs — although only one was defined in the specification — "/W")

#nex #nexProtocol

I like the nex-protocol.

I wish it supported (as part of the protocol) imperative-verbs like HTTP has.

(For example, HTTP has the imperative-verbs — DELETE, GET, HEAD, PATCH, POST, PUT, PATCH, etc.)

(The finger-protocol also has imperative-verbs — although only one was defined in the specification — "/W")

#nex #nexProtocol

A nex-server could support something similar to piping (commonly found on Linux, Unix, DOS, etc) by chaining file-extensions.

I.e., something like:

nex://example.com/path/to/file.txt.stem.sort

nex://example.com/image.png.png2ansi.gz

#nex #nexProtocol

A nex-server could support something similar to piping (commonly found on Linux, Unix, DOS, etc) by chaining file-extensions.

I.e., something like:

nex://example.com/path/to/file.txt.stem.sort

nex://example.com/image.png.png2ansi.gz

#nex #nexProtocol

A nex-server could support something similar to piping (commonly found on Linux, Unix, DOS, etc) by chaining file-extensions.

I.e., something like:

nex://example.com/path/to/file.txt.stem.sort

nex://example.com/image.png.png2ansi.gz

#nex #nexProtocol

A nex-server could support something similar to piping (commonly found on Linux, Unix, DOS, etc) by chaining file-extensions.

I.e., something like:

nex://example.com/path/to/file.txt.stem.sort

nex://example.com/image.png.png2ansi.gz

#nex #nexProtocol

A nex-server could support something similar to piping (commonly found on Linux, Unix, DOS, etc) by chaining file-extensions.

I.e., something like:

nex://example.com/path/to/file.txt.stem.sort

nex://example.com/image.png.png2ansi.gz

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing content-type negotiation like HTTP does with the Accept & Content-Type headers.

BUT —

Since file types are given by file-extensions, a nex-client could just try different file-extensions.

For example, if a nex-client saw:

nex://example.com/path/to/file.txt

Then it could request:

nex://example.com/path/to/file.xhtml

nex://example.com/path/to/file.html

nex://example.com/path/to/file.md

Etc.

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing content-type negotiation like HTTP does with the Accept & Content-Type headers.

BUT —

Since file types are given by file-extensions, a nex-client could just try different file-extensions.

For example, if a nex-client saw:

nex://example.com/path/to/file.txt

Then it could request:

nex://example.com/path/to/file.xhtml

nex://example.com/path/to/file.html

nex://example.com/path/to/file.md

Etc.

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing content-type negotiation like HTTP does with the Accept & Content-Type headers.

BUT —

Since file types are given by file-extensions, a nex-client could just try different file-extensions.

For example, if a nex-client saw:

nex://example.com/path/to/file.txt

Then it could request:

nex://example.com/path/to/file.xhtml

nex://example.com/path/to/file.html

nex://example.com/path/to/file.md

Etc.

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing content-type negotiation like HTTP does with the Accept & Content-Type headers.

BUT —

Since file types are given by file-extensions, a nex-client could just try different file-extensions.

For example, if a nex-client saw:

nex://example.com/path/to/file.txt

Then it could request:

nex://example.com/path/to/file.xhtml

nex://example.com/path/to/file.html

nex://example.com/path/to/file.md

Etc.

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing content-type negotiation like HTTP does with the Accept & Content-Type headers.

BUT —

Since file types are given by file-extensions, a nex-client could just try different file-extensions.

For example, if a nex-client saw:

nex://example.com/path/to/file.txt

Then it could request:

nex://example.com/path/to/file.xhtml

nex://example.com/path/to/file.html

nex://example.com/path/to/file.md

Etc.

#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing gzip, brotli, etc compression like HTTP does with the Accept-Encoding & Content-Encoding headers.

BUT —

A nex-server could support gzip compression when a ".gz" extension is added to the end of a file.

So if a client saw:

nex://example.com/path/to/file.txt

It could request:

nex://example.com/path/to/file.txt.gz

... to try to get a gzip'ed version.

Could do brotli, too:

nex://example.com/path/to/file.txt.br
#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing gzip, brotli, etc compression like HTTP does with the Accept-Encoding & Content-Encoding headers.

BUT —

A nex-server could support gzip compression when a ".gz" extension is added to the end of a file.

So if a client saw:

nex://example.com/path/to/file.txt

It could request:

nex://example.com/path/to/file.txt.gz

... to try to get a gzip'ed version.

Could do brotli, too:

nex://example.com/path/to/file.txt.br
#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing gzip, brotli, etc compression like HTTP does with the Accept-Encoding & Content-Encoding headers.

BUT —

A nex-server could support gzip compression when a ".gz" extension is added to the end of a file.

So if a client saw:

nex://example.com/path/to/file.txt

It could request:

nex://example.com/path/to/file.txt.gz

... to try to get a gzip'ed version.

Could do brotli, too:

nex://example.com/path/to/file.txt.br
#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing gzip, brotli, etc compression like HTTP does with the Accept-Encoding & Content-Encoding headers.

BUT —

A nex-server could support gzip compression when a ".gz" extension is added to the end of a file.

So if a client saw:

nex://example.com/path/to/file.txt

It could request:

nex://example.com/path/to/file.txt.gz

... to try to get a gzip'ed version.

Could do brotli, too:

nex://example.com/path/to/file.txt.br
#nex #nexProtocol

The nex-protocol specification doesn't describe a way of doing gzip, brotli, etc compression like HTTP does with the Accept-Encoding & Content-Encoding headers.

BUT —

A nex-server could support gzip compression when a ".gz" extension is added to the end of a file.

So if a client saw:

nex://example.com/path/to/file.txt

It could request:

nex://example.com/path/to/file.txt.gz

... to try to get a gzip'ed version.

Could do brotli, too:

nex://example.com/path/to/file.txt.br
#nex #nexProtocol

The nex-protocol doesn't have anything like a Content-Type header (for declaring the type of a file).

It instead uses file-extensions (for declaring the type of a file).

...

See also:
https://mastodon.social/@reiver/108770165047632509

...

https://nex.nightfall.city/nex/info/specification.txt

https://nex.nightfall.city/nex/info/station-guide.txt

#nex #nexProtocol

The nex-protocol doesn't have anything like a Content-Type header (for declaring the type of a file).

It instead uses file-extensions (for declaring the type of a file).

...

See also:
https://mastodon.social/@reiver/108770165047632509

...

https://nex.nightfall.city/nex/info/specification.txt

https://nex.nightfall.city/nex/info/station-guide.txt

#nex #nexProtocol

The nex-protocol doesn't have anything like a Content-Type header (for declaring the type of a file).

It instead uses file-extensions (for declaring the type of a file).

...

See also:
https://mastodon.social/@reiver/108770165047632509

...

https://nex.nightfall.city/nex/info/specification.txt

https://nex.nightfall.city/nex/info/station-guide.txt

#nex #nexProtocol

The nex-protocol doesn't have anything like a Content-Type header (for declaring the type of a file).

It instead uses file-extensions (for declaring the type of a file).

...

See also:
https://mastodon.social/@reiver/108770165047632509

...

https://nex.nightfall.city/nex/info/specification.txt

https://nex.nightfall.city/nex/info/station-guide.txt

#nex #nexProtocol