💾 Archived View for tilde.team › ~aprilnightk › gemlog › 2022 › 06 › 17-not-dead.gmi captured on 2023-01-29 at 03:45:32. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Neatmict portal

2022-06-17 - HFNP: The project's not dead! I'm working hard

It's been almost three weeks since I last wrote anything about Hafnium, it might seem like nothing is happening, but that's wrong. :)

I didn't make the changes public yet, I'll roll out the commits once I'm sure that everything works fine.

Wait, what's Hafnium?

Chances are, you haven't heard of it before. Briefly put,

Hafnium is my pet binary data serialization engine (there's only a Python implementation as of now). Basically, an engine to turn data into bytes and back. Yes, a new one. Because the others were not invented here. See how self-ironic I am?

HFNP stands for Hafnium Paging Procotol. Imagine Gopher or Gemini, but terminal-oriented, with colors, formatting, and interactivity, and also formatting is done server-side, not client-side. That's basically the idea. And also you can give your site a name without bying a domain.

If you're interested, here's the feed of my HFNP-related posts.

Hafnium/Netamict portal

Rewriting the core functionality

These were some really busy weeks life-wise, but it doesn't mean that the project has halted. In fact, I have heavily refactored the Hafnium core functions (the serialization engine, the bytecoders, the socket server/client framework and some of HFNP-related things).

These changes removed some really dumb decisions I've initially made, so turning the requests to bytes and back should become faster and more straightforward now. I tried to make the code more beautiful and sound this time.

I'm also in process of concretely defining what comprises the core functionality and algorithms of Hafnium. This will be laid out in documentation, and it will open way to implement Hafnium in languages other than Python (because neither HFNP, nor Hafnium in general are Python-specific).

Exception handling

A lot of work was done in the exception handling domain. Common exceptions were given codes, and the process of sending error information to the client has become slick and straightforward (or so I hope).

Quasidomains

I put a lot of thought into it, following some critical feedback (for which I'm thankful). Rethinking the idea made me realize how to make it better. This is one part of a project that - I hope - might once become useful outside of HFNP even, so by design it will not be tightly tied to HFNP. There will be room for enhancement.

So, what do I plan to change?

There will be numerous possible schemes of creating a quasidomain. I am planning a scheme for general hostnames, and a scheme specific to HFNP (to save a byte or two), also schemes will differ by whether they use specialized compression or not (see previous posts about SDNE, it will be redone and won't be mandatory for those who would prefer simplicity at the cost of the quasidomain length).

Quasidomains won't make heavy use of special symbols now, and they will become URI-safe. Also, there will be no "special" base64: standard base64 uncoding with two URI-safe altchars will be used. So, in an event when a HTTP-to-HFNP gateway might come around, including a quasidomain name into an url will not cause pain.

No more limit on quantity of variants. There will be an infinite amount of quasidomains to choose from for any combination of hostname+port.

The ideas have been finalized, and I'm in process of implementing them now.

Documentation

I have been really awful in documenting this project up to this point. The information was insufficient and sometimes misleading.

To mitigate that, I am going to make use of the awesome MkDocs static documentation generator. It's really awesome and working with it is like a breeze!

[HTTPS] MkDocs homepages

I have conjured up a small script to generate comprehensive reference out of function declarations (I love Python's introspection abilities), typehints and docstrings - I really like how it looks so far. It will be available on my site when it is ready. I'm also planning to convert it automatically into Gemtext an into HFNML (though that's not top priority for now).

The browsers

The HFNSurf browser is an awful user experience. The scrolling is pain, and I really shouldn't have released it like this. As the protocol itself matures, I will put more attention to the client side of it.

Initially, I have plans to create two browsers:

HFNSurf - the commandline browser which does already exist, I'm going to make it better
A PyQT-based browser, to marry the terminal-like visuals and the link clickety-clackety experience.

Next update

I think I'm 2-3 weeks away from releasing the next version, unless I get super productive for whatever reason. I hope that it will gain traction as it matures and turn into a fun sitemaking/browsing experience. Can't wait for the fun to begin!

- - - - - - -

Keith Aprilnight (aprilnightk@tilde.team)