💾 Archived View for tilde.team › ~aprilnightk › gemlog › 2022 › 07 › 17-netamict.gmi captured on 2023-01-29 at 16:39:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Hi, fellow Geminauts! Hope everyone is doing well!
It's been a while again. Some things in life and in general kept me from updating a lot, but I will try to write more frequently, and not only about my projects too.
A lot of changes is underway in the codebase. Basically, I'm mostly rewriting from scratch because of some crucial new ideas I have come up with.
This means that the new release is going to be when I re-write the terminal-based browser and make sure it works.
I also renamed the Hafnium Paging Protocol (HFNP) into Netamict. Here's why.
The initial naming decision was very lazy and among the lines of "this protocol is based on my Hafnium serialization engine, so I will just call it "Hafnium [something]". But it really is a bad idea. First off, the protocol isn't a part of the engine. The engine can be used for other things, and the protocol is a whole different story.
Also "Hafnium Paging Protocol" is mouthful, uncreative and dull. So I decided to find a separate name for the protocol and now that I'm at it, separate the codebases too.
...So, hafnium is a metallic element that is sometimes found in minerals (though not in large quantities). Zircon is a prominent mineral that occasionally features some hafnium mixed in it. Along with hafnium, some other elements, some of them unstable, can be found in zircon, too. This may break the crystallic structure of zircon (happens to many other minerals, too).
This process is called metamictization, and these minerals are called metamict. And this word - "metamict" - sounds very cool in my opinion. But just using it would have been lazy, and it also starts with "meta", and nowadays it's not a word that I'd want to be associated with. So I changed the first letter to come up with this cool (or so I think) neologism: netamict.
So, the URL's in the Netamict network will no more be "hfnp://address", they will be "nm://address". Also, HFNML markup language is renamed into NMML.
The old HFNSurf browser (I took down the download links to it because it won't be of any use anymore) is scrapped and I'm in process of making a new one.
I really wanted some curses-like interface, but there were some problems about it. The thing is, Netamict pages are going to make heavy use of terminal ANSI sequences for formatting and sometimes page element positioning. Turns out, curses aren't exactly friends with the ANSI sequences. To write bold text or undelined text or whatever, you have to use curses' own syntax, and it will - under the hood - turn it into ANSI sequences to show the result in the terminal.
I couldn't live with it, so I decided that I should make my own curses-like library, which will allow any ANSI escape sequences I want. This is a Python library and it's under development. I don't know if it will work fine, but at least it works in principle and looks nice from what I can already see. I'll provide screenshots in one of the next posts.
I have been using tildegit.org to host my projects. I think it's a very great website and I want to thank people who make it possible.
However, as my project grows, I split it into several git repos (going to be six soon), and I have a habit of making frequent small commits.
When I commit to tildegit, my project rises to the top as the most recently updated. If I update all my commits, they all rise to the top. If I do it frequently, they could as well just stay on the top, and that's extremely unfair, I never wanted to usurp such a good public git forge. I had a byzantine scheme of commiting to my own personal repo and only occasionally upstreaming commits to tildegit, but I find it a bit unwieldy to operate.
So I decided that at this point I should take care of my repositories myself.
I've never been a huge fan of GitHub and the likes. GitHub is now operated by Microsoft. You know the drill. BitBucket is sluggish, and is, too, operated by a pretty large company.
Like me, you've probably seen recent articles urging open-source projects to use open infrastructure and not use GitHub. I wholeheartedly agree with that. So I went searching for a good way to host my projects, and I found sourcehut.
SourceHut is a git forge led by Drew DeVault (he used to have a gemlog, but some time ago decided to drop it, so I'll link to his HTTP website instead).
SourceHut is unusually fast compared to other git forges, this comes from the fact that it's really lightweight and doesn't even require JavaScript. Naturally, I wanted to use it.
Deploying a SourceHut instance is no easy feat (for someone who doesn't have a lot of experience with hosting services and stuff) but I was determined to do that.
(Note that you can avoid that by just hosting your repositories with your sr.ht account. It's the public Sourcehut instance held by Drew, so that lifts the burden of administrating the repositories from you. Note that it's planned as a paid service, and as it moves on from alpha stage, you will have to pay to host there - which is perfectly fine and a much better, honest and transparent provider/user relationship framework than sneaky "free-means-you're-the-product" stuff prevalent in the GitHubs of this world.)
I decided to deploy my own instance, though. Sourcehut provides a number of separate services (so that's pretty modular). You absolutely need the meta.sr.ht service, and if you want to host git, you also need the git.sr.ht service.
Sourcehut provides example configuration files from which you can build. Everything explained quite well there. You'll need also an SQL database - one per each service, so two in my case (Postgresqlis a good choice), a Redis instance, and a web server (I use nginx).
There have been several problems I faced, almost all of them stemmed from me not understanding the config comments correctly at first. There were two issues that I needed help with. I used the sr.ht mailing lists to get help, and I was promptly contacted with some good guidance.
Here's the explanation of the issues (pasted verbatim from the mailing list). If you happen to try and deploy a SourceHut instance on Debian, like me chances are you may stumble upon this, and the link above might be of help.
Keith Aprilnight <aprilnightk@tilde.team> Details 6 days ago First time posting here, I hope I do it right. I'm deploying meta.sr.ht and git.sr.ht on my server. The system is Debian (unstable), sr.ht installed from apt packages. All the services are running without errors, PostgreSQL, Redis and nginx all set up. I have an admin user and a password. When i try to log in, if the password is wrong - I get the "wrong password" notification. When I input the correct password, though, nothing happens - the login page just reloads with empty input fields, and I am not logged in. The logs show nothing relevant, no errors. I've tried different browsers, with add-ons on and off. I have a feeling that I am missing something fundamental here, did this ever happen to anyone else? As a side note: the srht-meta-webhooks service doesn't start when the "billiard" pip package of newest version 4.0.0 is installed. The service tries to import "buf_t" from billiard.compat which was recently removed from there. Downgrading to the previous version worked, but I wanted to bring this into attention. Thanks!
Keith Aprilnight <aprilnightk@tilde.team> Details 6 days ago Solved! It was let known to me that the issue was the "global-domain" config setting (put in the [sr.ht] section) that had to be correctly set (i.e. if the service is at "example.com", it has to be set to "example.com"). Without it, the "set-cookie" header of the form response said just "Domain==.com" instead of "Domain==example.com", and the whole thing didn't work. I was not aware of the setting as it was not documented. Perhaps example config files should make this config setting explicit. Thanks!
Now I'm happily hosting my code here:
[HTTPS] Netamict git repository
Please note that none of this is ready to be used for anything. I don't abide by the "each git commit must be a functional snapshot" philosophy, sorry. When your stuff works, you make a release. Commits are just there for you and others to keep track of your development process. Just my opinion!
Now that the infrastructure side of the project is settled, I'm back to actually implementing the projects. I'll get back when I have something to share!
Wishing y'all a great day,
Keith.
- - - - - - -
Keith Aprilnight (aprilnightk@tilde.team)