reiver, (edited ) to email
@reiver@mastodon.social avatar

I recently became aware of a new small-net protocol (thanks to @wholesomedonut ) —

Misfin
gemini://misfin.org/
https://sr.ht/~lem/misfin/

Where the gemini-protocol is an alternative to the gopher-protocol and the Web — Misfin is an alternative to e-mail.

Misfin is tied to the gemini-protocol & gemtext — messages are assumed to be gemtext, server responses are based on gemini-protocol server responses, etc.

reiver,
@reiver@mastodon.social avatar

@ruario @WildEnte

If you are interested in this type of thing — there is another small-net protocol I came across somewhat recently —

nex

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

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

nex is meant to be an alternative to the gemini-protocol, the gopher-protocol, and the Web.

reiver, to random
@reiver@mastodon.social avatar

I like that the nex-protocol supports directories.

(It is something that the HTTP protocol lacks, except for some atavi like relative path resolution. And, no, WebDAV doesn't count.)

...

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

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

reiver,
@reiver@mastodon.social avatar

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

reiver,
@reiver@mastodon.social avatar

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

reiver,
@reiver@mastodon.social avatar

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.

reiver,
@reiver@mastodon.social avatar

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

reiver,
@reiver@mastodon.social avatar

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")

reiver,
@reiver@mastodon.social avatar

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines