An HTTP frontend to ERIS

This week I wrote a server for serving ERIS data to naïve HTTP clients.

https://git.sr.ht/~ehmry/eris_utils#erishttpd

The server accepts uploads via HTTP PUT, which can performed by cURL:

The server responds with a "Content-Location" header that indicates the URL path for accessing the upload:

With this the content can be retrieved:

The implementation of the server makes it a zero-knowledge data-locker. So long as the server is not logging the URNs in requests or responses, the operator of the service is unable to browse the stored content. Clients have no guarantee that they aren't being logged, but the operator can use ignorance to avoid some ethical hazards (do you really want to know what your friends are uploading?).

https://en.wikipedia.org/wiki/Zero-knowledge_service

Implementation

Data that is streamed to the server with a PUT request is segmented into fixed-size blocks (1 or 32KiB). These blocks are hashed to derive a 256-bit encryption key, encrypted using that key, and the ciphertext hashed again to derive a 256-bit block reference. The key and reference of content blocks are stored in fixed-size meta-blocks, which are encrypted in the same manner, and stored within a tree of meta-blocks until a key and reference to a root meta-block is determined. This key and reference forms the ERIS URN which is returned to the client. The server does not retain the key to the root block.

ERIS spec

During encoding blocks are stored in a Tkzrzw key-value database file, the key of each stored block is its hash.

Tkrzw: a set of implementations of DBM

When dispatching GET requests the server parses an ERIS URN and loads the meta-blocks from the database, then streams the content-blocks to the client. After streaming is complete the server discards the keys to meta- and content-blocks.

Disadvantages

Future plans

I wrote this server to integrate with an existing web-service, but I also plan to include as a library within a chat-bot for publishing file uploads.

I could write a Gemini server, but I'd rather not deal with TLS at all. The server is intended to operate within private networks or behind proxies and features no transport encryption or authentication.

Proxied content from gemini://gemini.spam.works/users/emery/erishttpd.gmi

Gemini request details:

Original URL
gemini://gemini.spam.works/users/emery/erishttpd.gmi
Status code
Success
Meta
text/gemini
Proxied by
kineto

Be advised that no attempt was made to verify the remote SSL certificate.