💾 Archived View for tilde.team › ~aprilnightk › gemlog › 2022 › 05 › 31-hafnium.gmi captured on 2023-01-29 at 03:45:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-06-03)
-=-=-=-=-=-=-
It's been a week or so of hard work and thinking to make the renewed version of the protocol possible! I thank so much everyone who took the trouble to check it out and gave feedback. Your feedback has been valuable and actually it made me do some big changes, particularily, in how the quasidomain idea works. So, thank you!
I have received some more feedback, most of which concerns two things - dissatisfaction with some technical aspects of the quasidomain system, general insufficiency of explanations/documentation, and sloppiness of definitions/terms.
Well, I am learning, and this helps me learn too, so thanks. With this in mind, I guess I should temporarily slow down and review everything that's been done so far, make it better built, better commented/documented, and come up with a more thorough and in-depth documentation.
So before I move on with actually continuing this work, I will first take care of these, and, perhaps, tweak the quasidomain system some more (so keep this in mind, just in case), because at least some of the criticism I got makes sense and should be taken care of. In the meantime, I still welcome more feeback.
I don't want to be spamming Antenna with these things, because this would be uncouth of me, and at the same time I plan to sometimes post updates on my Gemini capsule for those interested. So, in future I will only post announcements of, like, really important things on Antenna. Otherwise, all the Hafnium-related things will reside here:
Hafnium Paging Protocol portal
Consider it a special thematic gemlog. The posts will look the same, only I will not relay them to Antenna.
With this out of the way, let's go!
This section continues on the previous post about quasidomains:
2022-05-24 - HFNP: Details on the quasidomain system
The quasidomain update has been the toughest, but it is the update I'm currently most happy with. I have received certain critisism over the week regarding these facts:
Both of these problems have been addressed. The resulting algorithm is an order of magnitude more complex (sorry), but it's the simplest I could come up with that would actually get the job done.
Now the quasidomain system is contained in a separate python library, the source is located here:
[HTTP] Quasidomain source on tildegit.org
There are all the libs used, and also a generator script and a simple resolver script.
Put succinctly, the biggest change is that quasidomains now can be generated from _actual_domain_names_ too.
Let's say you're John Dow. You've bought a domain johndow.co.uk, and now you want a Hafnium site, and you want it to be named well, "johndow". You don't want to bother about potential IP changes, of course - you have a domain name, you're better than that!
Well, now John can generate a quasidomain out of his actual domain. Actually, he can generate multiple quasidomains, all of which will resolve into his domain! So, he wants a server at port 9777 (standart for hfnp) and...
... johndow.S#9bFH4$ --> johndow.co.uk:9777 johndow.TDNJucfD --> johndow.co.uk:9777 johndow.TDJL78EJ --> johndow.co.uk:9777 johndow.TDHLzDUL --> johndow.co.uk:9777 johndow.TDBmodzL --> johndow.co.uk:9777 ...
He can choose whatever quasidomain he likes better, out of thousand of variants - any of them will work. His domain name, his top-level domains and his port number are all in there, in the quasidomain appendix.
Maybe he doesn't want to name his site 'johndow', maybe he wants another site - on the same server - about pencils (he likes pencils). Well, no need to buy a separate domain for that:
... pencils.mdsAJGtrZfrhyQ& --> johndow.co.uk:9778 pencils.mtuQEM2NUUBRgQ& --> johndow.co.uk:9778 pencils.m9tDnpRM6McaQQ& --> johndow.co.uk:9778 pencils.nCTiCCyeBhB!Xzg$ --> johndow.co.uk:9778 pencils.nCXgXipUY6NNFbE$ --> johndow.co.uk:9778 ...
These are longer, yes. This is the price to pay because now the quasidomain also needs to contain information about _whole_ hostname it has to resolve into, not just the top-level domains.
On the bright side though, John now has two different sites with different names running on the same machine. He can have any number of them.
As for the quasidomains based on IP addresses - they are still there. Not much has changed about them other than algorithm technicalities.
The description of the algorithm is more complex than the one before it, so I decided to put it into a different post. If you're intersted, please, come take a look:
2022-05-31 - HFNP: New algorithm of quasidomain generation
It is also available on the main HFNP site inside HFNP network (more about it below).
Also, if you don't want to use quasidomains, you can still make a HFNP site: IP addresses and normal domains are resolvable as well (should be, though I hadn't tested the latter).
There's a markup language for this protocol: HFNML (Hafnium Markup Language). It is described in detail on the HFNP home site.
It's different from HTML and Gemtext in that it is parsed by the server, not by the client. It's half markup/half template language, actually.
Visually, it looks a bit like BBCode (square brackets). It has tags associted with lots of terminal escape codes for colors, text formatting, etc. Also, it has some tools for handling the text alignment, wrapping, and hiding text based on conditions, user rights, et cetera.
Usage of HFNML is not mandatory, because the protocol and the browsers are agnostic about it: server just sends plaintext to the client; _how_ that plaintext is generated is up to the site owner.
I've already mentioned this, but just to put it here clearly, one server now can server multiple sites. A request has an URI in it, and it gets routed to a site instance, which, in turn, dispatches this request to generate an actual response page. Speaking of requests and responses...
I've put more order into just how the requests are handled. Now the sequence of events that starts when a user wants to make a request and ends when the browser receives and handles a response is laid down as a concrete sequence of 24 stages. Each of these stages has a purpose and an name, and within each of these stages there's potential for the external processors ("plugins") to intervene.
As a test example, I've created a simple user authentication processor (which doesn't use any cryptography, it's just a simple hash checking thing). But it does meddle with the requests and response, and halts the response if the user tries to impersonate another user ID: an error response will be sent to that user.
Here are some things I plan to do next (can't promise either of these - these are just plans!):
Written here are just a quick review of what was done. If you are interested in a deep explanation of all things that are in play on HFNP, please come take a look at the Hafnium Tour, which has more in-depth explanaions.
Here's how to do this:
1) Download a new version of HFNSurf browser here (it's a bit rough over the edges, I'll work more on it later, and I also plan to make a QT-based browser):
2) Read the help within the browser to understand how it operates;
3) Point it to hfnp://hafnium.D4GREATu/index (isn't that a great quasidomain, by the way?) and take a look around. (The tour itself can be found on hfnp://hafnium.D4GREATu/tour/contents)
The source code of Hafnium itself and HFNSurf Browser too are available here:
As always, if you're interested in using or participating in development of this protocol, if you have some feedback or just want to let me know what you've liked or disliked about it, please drop me a mail!
- - - - - - -
Keith Aprilnight (aprilnightk@tilde.team)