A small TLS-only plaintext request/response protocol inspired by Finger. The concept of Finger has great potential as a low-bandwidth API endpoint. We want to secure it and give it some room to breathe, while making it easy to import nearly 50 years of forgotten Finger-based utilities.
You can read a working draft of the fingers:// specification at fingers-protocol-draft.md.
This is an early draft.
The protocol is intentionally small and syntax-focused. It defines transport, request syntax, URI mapping, and response framing. It does not require any specific backend model.
Ignore anything about relays. That's one of the last ChatGPT-placeholder pieces that I still gotta research more about first.
- mandatory TLS from connection start
- one request per connection
- one plaintext response per connection
- UTF-8 text
- no headers
- no status codes
- no length fields
- URI scheme:
fingers:// - default port:
:8179
This draft standardizes only the protocol surface:
- transport and TLS behavior
- request-line syntax
- URI mapping
- response framing
- reserved syntax space
It does not standardize server internals. A conforming daemon may use plain files, scripts, CGI, templates, databases, or any other local mechanism.
This spec is intended to enable Finger-style passing of encrypted plaintext data around like this:
fingers user@hostname.com
fingers /FLAG /flag2=variable user@hostname.com
fingers://hostname.com/user
fingers://hostname.com/user?FLAG&flag2=variable
user<CRLF>
/FLAG /flag2=variable user<CRLF>
For more information, read the Draft Specification.
This draft is meant to be simple and easy to evolve. Much like Finger's RFC 1288, the goal here is a small, readable protocol document that people can independently implement without needing a large software stack.
The fingered application, on top of functioning as a traditional finger:// daemon, is also to be considered the Reference Implementation of the fingers:// protocol, and is equally a work-in-progress.