Merge branch 'odin' of git.hitchhiker-linux.org:jeang3nie/capsule into odin

content/gemlog/an_overview_of_dory.gmi

@@ -0,0 +1,26 @@
+Meta(
+    title: "An overview of Dory",
+    summary: Some("An overview look at Dory, a Misfin protocol library in Rust"),
+    published: None,
+    tags: [
+        "misfin",
+        "rust",
+        "programming",
+    ],
+)
+---
+This is a follow up to my previous post about Dory.
+=> gemini://gemini.hitchhiker-linux.org/gemlog/dory_a_misfin_protocol_library_in_rust.gmi Dory announcement
+=> gemini://misfin.org/
+
+So Dory is a WIP Misfin protocol library. That means that Dory will implement the Misfin spec without actually providing a server binary (although I will likely add a rudimentary single threaded example server). I'm writing it in a fairly generic way so that the library user can choose for themselves how to handle storing certificates and messages, as well as how to set up a listener. I have some opinions on those things, but I'll leave that for a later project when I actually put Dory into production.
+
+Dory is written in Rust, as are most of my projects these days. I'm not going to argue with anyone about the merits of Rust, but it works well for me. I particularly love the tooling. I've been able to write a lot of tests as I go so I can be pretty sure that things are working as intended before actually trying it all out. I'm usually pretty careful about dependencies when using Cargo, however, as adding one line to Cargo.toml can easily bring in a half dozen or more transitive deps. Even so, some things don't make sense to implement completely from scratch, so I'm using the following libraries.
+
+* rustls - managing tls connections
+* digest and sha2 - generating certificate fingerprints
+* time - parsing time into the correct format (this one I may change)
+* x509-parser - parsing and validating certificates
+* serde(optional) - serializing certain datatypes
+
+The serde dep is behind a feature gate. I've put that in so that someone could provide, say, a json api for Android or IOS apps. It would also be useful if one wanted to store things like client certificates and certificate fingerprints in text files.

content/gemlog/dory_a_misfin_protocol_library_in_rust.gmi

@@ -0,0 +1,36 @@
+Meta(
+    title: "Dory: a Misfin protocol library in Rust",
+    summary: Some("Dory is a (WIP) Misfin protocol library in Rust which will implement the protocol in a way that both standalone servers and integrated services can be developed on top of it."),
+    published: Some(Time(
+        year: 2023,
+        month: 5,
+        day: 24,
+        hour: 17,
+        minute: 45,
+        second: 18,
+    )),
+    tags: [
+        "misfin",
+        "rust",
+        "programming",
+    ],
+)
+---
+Misfin is a protocol proposal for a messaging and mail service designed along ideas from the small web.
+=> gemini://misfin.org/
+
+I'm intrigued enough by the spec that I started working on a Rust crate which implements the spec. It's early days, but the goal is to implement the spec in such a way that it can be used either by a standalone Misfin server or as part of a larger Gemini (or other smallweb) application.
+
+=> https://codeberg.org/jeang3nie/Dory Dory repository on Codeberg
+
+The name Misfin made me think of the character Nemo from the pixar film. My favorite character from that movie was Dory, hence the name.
+
+I plan to limit the scope of the crate as follows:
+* Implement opening connections and sending mail/messages for the sending server
+* Implement handling a request by the receiving server and sending a response
+* I'm not planning to implement the event loop for the receiving server, as the library consumer should have some choice in how they want to set this up.
+* I'm considering making client certificates a requirement. The spec recommends them but does not require them.
+* Tofu is handled by a `CertificateStore` trait. It will be left to the library consumer to implement the trait on their own data type, so that you have the option of using anything from a simple HashMap to a database connection.
+
+## Status
+Right now what exists is mostly a collection of data types, with a fair bit of the functionality just stubbed in. I started with status codes and parsing requests/responses from their raw data, so those parts are all in place. The Tofu verifier is partway written. I took pains to set up the repository to be easy to understand, and there are lots of doc comments specifying what the various types are meant to be (although I haven't gotten around to examples yet). Basically it's a solid base to build on, but not ready for use. I figured I'd go ahead and put it up publicly in case anyone wants to join in (haha).

content/gemlog/nwg_shell_for_sway.gmi

@@ -0,0 +1,42 @@
+Meta(
+    title: "Nwg shell for Sway",
+    summary: Some("Nwg shell adds a lot of full blown desktop functionality back into Sway."),
+    published: Some(Time(
+        year: 2023,
+        month: 5,
+        day: 23,
+        hour: 21,
+        minute: 45,
+        second: 48,
+    )),
+    tags: [
+        "sway",
+        "discoveries",
+    ],
+)
+---
+My previous post about migrating to Sway:
+=> gemini://gemini.hitchhiker-linux.org/gemlog/migrating_to_sway.gmi Migrating to Sway
+
+As a follow up, I found a pretty cool project called Nwg Shell which provides a lot of the functionality that you might miss from a full blown desktop environment, but for Sway specifically.
+=> https://github.com/nwg-piotr/nwg-shell Nwg Shell
+
+I'm using two of the component pieces and find that it's plenty for my uses. I've replaced Wofi with nwg-drawer as my launcher and am using nwg-panel as (surprise) my panel. Both are very attractive, very functional and look surprisingly like Gnome. It's like a best of both worlds setup.
+
+## Nwg Drawer
+=> https://github.com/nwg-piotr/nwg-drawer Repository
+When open this looks a lot like the applications grid in Gnome's activity overview. It's also a nice search as you type sort of interface. The only issue I would point out is that it opens a little slower than something like rofi or wofi on slower hardware, but on my circa-2017 Dell laptop (7th gen i5) it's plenty snappy. It's written in Go using Gtk+3. Comes in at 4.7M in size, so it's a little chunky in that department, but I've seen worse these days.
+=> ../images/screenshot-Tue_May_23_13:48:55_EDT_2023.png Screenshot
+
+## Nwg Panel
+=> https://github.com/nwg-piotr/nwg-panel Repository
+Unlike Nwg Drawer, this one is written in Python. Again, it's using Gtk+3 though, so at least there's some consistency there. What I don't like is that I had to add some python modules that Void didn't have packages for, but if you're using Arch there's an Aur package. The default layout gives you two panels with the taksbar and weather applet on the bottom, and all of the other applets on the top. The clock is centered on the top panel and clicking on it brings up a small calendar. There is a little utility menu on the right which is a lot like Gnome's quick settings. You get a graphical settings manager with it as well, so no editing config files unless you want to. I ditched the bottom panel and moved the taksbar into the top panel because I hate taking up extra screen.
+=> ../images/screenshot-Tue_May_23_13:38:40_EDT_2023.png Screenshot
+
+## What's missing?
+One thing I always loved about Plasma and Gnome is that you hit the Super key and start typing to bring up an application. I loved that enough that I set up XFCE the same way by using the Whisker menu and a small X11 app called Ksuperkey, which allows you to bind to the Super key by itself while still using it for other keycombos (otherwise your menu would still open when using Super+1 or whatever). Anyway, since Sway isn't X11 I don't have a way to duplicate that, so I've had to get used to Super+D. It's not a huge deal, but muscle memory being what it is I find myself occasionally wondering why my app launcher isn't opening.
+
+## Gnome still pisses me off, and I'm still using Zellij
+So all of what I wrote in my previous post about Gnome still applies. I'm only thinking about it because these two programs (nwg-drawer and nwg-panel) look so much like their Gnome counterparts, which I really do like. So I've basically got my best of both worlds setup now, since I have so much more room to see the content of my applications than I would in Gnome, and I've also got tiling window management.
+
+After a few days of just opening a new terminal instance every time I wanted a terminal I did wind up switching back to using Zellij. It's just a nice way of working to me. I have the keybindings set up exactly how I want them and just find it a little more productive than only using Sway's native tiling, especially because I also have tabs available.

content/gemlog/on_bubble_centralization_and_federation.gmi

@@ -31,8 +31,8 @@ Skyjake already has an issue up about federating with other Bubble instances.
 Even having this as an issue for the project is a great sign. But really I doubt that we're going to see a bunch of different Bubble instances all living together in harmony. For one thing, there's a lot less people using Gemini than there are using the big web. For another, it already has traction. And finally, I don't think it would be healthy if Bubble was the lone option for federating with other Bubble instances. Which leads me to path two.
 
 ### Path two - we, as a community, work up a spec and do this right
-The fediverse has it's issues, but what it does have going for it is a clearly written specification and multiple implementations of same. Mastodon may be the biggest, but yoiu also have pleroma, pixalfed, funkwhale, and gotosocial to name just a few. That part really matches the ethos of Gemini IMO. Gemini has a well written spec and numerous different servers and clients. Lagrange may be dominating the client space but we do have other options, and we have a whole lot of different server implementations to choose from. My favorite one happens to be "roll your own" due to the fact that the spec is not only very clearly written but also pretty darn simple. So simple that there are fully functional clients written in everything from C/C++ to Python to Rust to shell scripts.
+The fediverse has it's issues, but what it does have going for it is a clearly written specification and multiple implementations of same. Mastodon may be the biggest, but you also have pleroma, pixalfed, funkwhale, and gotosocial to name just a few. That part really matches the ethos of Gemini IMO. Gemini has a well written spec and numerous different servers and clients. Lagrange may be dominating the client space but we do have other options, and we have a whole lot of different server implementations to choose from. My favorite one happens to be "roll your own" due to the fact that the spec is not only very clearly written but also pretty darn simple. So simple that there are fully functional clients written in everything from C/C++ to Python to Rust to shell scripts.
 
 I really think that rather than starting with an implementation in Bubble for federating with other Bubble instances we would be better served by actually working out a way for different Gemini services to federatein a more generic way, so that people could continue to roll their own. Bubble could then be one implementation of a protocol, rather than not having a protocol at all, or having the protocol be "try to match what Bubble does". That's not to say anything negative about what Skyjake is doing. I'm a fan. I just think that this past week has raised some questions, and I think it's time for all of us, or at least some of us, to step up and decide what we want to do going forward considering this type of service is obviously going to be popular.
 
-I would be happy to put time into this. I'm not putting myself forth for any type of leadership capacity, but I'll gladly collaborate with anyone who this resonates with who might want to take it past talk. I hope to get some response to this one. Normally I'm fine with just putting my words out to the void but please do contact me with any thoughts on this post. Email is good, as are your own gemlog posts, or even conversing over Bubble for that matter. Thanks in advance.
+I would be happy to put time into this. I'm not putting myself forth for any type of leadership capacity, but I'll gladly collaborate with anyone who this resonates with who might want to take it past talk. I hope to get some response to this one. Normally I'm fine with just putting my words out to the void but please do contact me with any thoughts on this post. Email is good, as are your own gemlog posts, or even conversing over Bubble for that matter. Thanks in advance.

content/gemlog/spell_checking_in_neovim.gmi

@@ -0,0 +1,29 @@
+Meta(
+    title: "Spell checking in NeoVim",
+    summary: None,
+    published: Some(Time(
+        year: 2023,
+        month: 5,
+        day: 21,
+        hour: 15,
+        minute: 2,
+        second: 52,
+    )),
+    tags: [
+        "neovim",
+        "workflow",
+        "lua",
+    ],
+)
+---
+I had an email reply to one of my posts this morning which pointed out a spelling error. Well, there was more to the reply, but for the sake of this post that's the important bit. Anyway, what's funny is that I was just last night looking at the possibility of adding spellcheck to my NeoVim configuration.
+
+It turns out that NeoVim has a spell checker built in as of version 0.8. That's fantastic. You can turn it on with the command `:set spell`, or if you are using a language other than en_US `:set spelllang=<LANG>` where <LANG> would be your language code. But I really like having things like this mapped to an easy to remember keybind whenever possible, so I wanted to be able to toggle it on and off using `<leader>sc`. Well, that was pretty easy as well with the following snippet in init.lua.
+```
+-- Toggle spellcheck
+local function toggle_spell_check()
+    vim.opt.spell = not(vim.opt.spell:get())
+end
+vim.keymap.set('n', '<leader>sc', toggle_spell_check, {noremap=true})
+```
+I love having lua available in NeoVim.