Repurposing Phaedra

Phaedra is an Android Gemini client written in Java that was intended to be as small as possible and also work on all Android devices all the way back to Android version 1. It ran into some difficulties with TLS as older devices have out of date versions and even with bloating the app by adding the Conscrypt library it could still only go back so far before the crypto broke again.

Phaedra
Conscrypt

By 'pivoting' (I hate that word) Phaedra from a Gemini client to a Mercury client the TLS requirement can be stripped out entirely (plus I can return to making the app as small as possible). Mercury is essentially Gemini without the TLS (plus a few other simplifications around Gemtext) and was put forward by Solderpunk a while back:

The Mercury protocol

Obviously without TLS Mercury is a security concern for general use, however in a decline/permacomputing world it means no old devices are rendered useless for communications. One of the original aims of Gemini was that a programmer could create a useable client or server in few hours and a hundred lines of code or so, the simplicity of Mercury lends itself perfectly to emergency scenarios: a server exposing content over basic sockets, and a client connecting without worrying about having out of date crypto suites. I can see Mercury working well in community intranet projects too.

Why not use Gopher?

When I floated the above idea on Mastodon a good challenge was made; Gemini without TLS is essentially what Gopher is. That's true, and there's lots of client and server software already available for Gopher. I'm going to continue with Mercury and Phaedra though, it can't hurt to have both, and I've never got on with Gophers archaic design decisions, Gemini/Mercury are both very simple and elegant, there's a clarity to them that older protocols don't have.

Discoverability

A nice addition to Mercury would be a default response to unrecognised request formats that returns the entire protocol specification. If someone hears about a host and tries to connect without knowing the specification they'd have everything they need to get a client up and running.

Port Number

The Mercury Protocol doesn't specify a port number though someone has suggested 1963 on the Gemini mailing list:

Mercury

By using this and including a default response that writes out the specification all someone would need to get going would be 'make a socket request to oppen.digital on port 1963'

Next Steps

• Amend this server software to accept mercury:// requests on port 1963 - DONE.

• Refactor Phaedra to work with the protocol, remove TLS, and make the Gemtext adjustments - DONE.

• Figure out a mechanism to output the spec for any 'bad' requests


© 2019 - 2021 ÖLAB
Part of a webring
view in Gemini