Forem: Gary Kramlich

Right to be Forgotten and Open Source

Gary Kramlich — Sat, 25 Jan 2025 01:05:17 +0000

The Right to be Forgotten is giving people the right to have their information removed from the internet. On the surface this is a great thing and I'm a big supporter of it. However, when it comes to Open Source projects, things can get messy very quickly.

Many people realize that interacting with an Open Source project means that basically everything is open to the world not just the source code. However, so people don't realize this and hopefully this post will help explain this a bit better.

When it comes to Right to be Forgotten we only have few places were we have user data as part of us running Pidgin. These are our mailing list archives which have been replaced by Discourse, our issue tracker, and our old developer WIKI.

Open Source mailing lists have historically been archived by the project and other mailing list archives out on the internet. This is done for a number of reasons, but at the core the idea is that there are a lot of discussion and answers to support questions and having them available is acceptable.

However, people have requested use to forget them in our mailing list archives. There are a few options here to do this randomize their Personally Identifiable Information (PII) or just deleting any emails that mention them.

The former is a ton of work and at the time of this writing I'm not aware of a tool that does this. The later of course is destructive and depending on how active the requestor was on the mailing list can have a huge impact of the value of the archives. But deleting everything from the user is generally the course that's taken because there's also a possibility they posted PII in the body of their messages which the former wouldn't detect unless it was the email address or whatever.

But there's a bigger issue here. Remember those other archives out there on the internet, the requestor has to send a request to all of them. As far as I know there's no index of mailing list archives which means deleting one or two doesn't really matter in the grand scheme of things.

That said, there's another sleeping dragon here. Many people just archive mailing lists in their email accounts. With a few scripts they can extract all the emails from their email account into a format where they can just mirror it on a website adding yet another site that the requestor has to find and request to be forgotten.

So basically, if you think you might ever want to be forgotten, please stay off of the mailing lists :) I know this is unrealistic, but people need to be made aware of it.

That said, we have replaced our mailing lists with a Discourse instance at discourse.imfreedom.org. Discourse has an option for users to anonymize themselves which effectively gives them all the power to be forgotten without actually getting the project involved.

When they anonymize themselves all of their posts stick around but their username and stuff won't have any reference to them. But like email above, if the user put PII in a post it will remain unless it is manually removed.

So next up is the issue tracker. Previously we were using Edgewall Trac for issues and documentation via it's WIKI functionality. We made this read-only years ago because it is abandon-ware now and wasn't scaling to the needs of the project.

When we did this, we redirected all of the URLs relating to tickets/issues to our new issue tracker. Our new issue tracker is JetBrains YouTrack and similar to Discourse, users can anonymize themselves. Again, this is just account details and does nothing about the contents of posts.

But more importantly to note, is that when we imported all of the issues into YouTrack we only copied a few developer accounts. We did not copy any user accounts so any a user would be mentioned we instead used a user named Ghost. This was specifically done to respect people's privacy by not copying their data from one service to another.

Semi-recently, we even went through and crawled our Trac instance and saved it all to static HTML. What you see today on developer.pidgin.im is the result of that crawl. This means we were able to shut Trac down completely and since Trac and it's backing database are gone, users can't delete their accounts.

However, there is still the WIKI to worry about and that's actually where the motivation for this whole post came from. But before we get to that, lets discuss what information is stored in the WIKI.

We are still serving the read-only versions of the WIKI on developer.pidgin.im because we haven't yet migrated them to the new site. We haven't migrated them because we determined that pidgin.im isn't the right place for all this information and that we should create a new developer.pidgin.im but we haven't gotten around to doing it yet.

So the WIKI can still mention user accounts, their edit history, and all of the edits they made. Now generally speaking the list of contributors here is much smaller than the one creating issues, but it's not zero. Luckily for us so far, no one that has edited the WIKI has requested to be forgotten.

So back to the impetus of this post.

we received a right to be forgotten email request to security (at) pidgin.im. It turns out that email address was not configured as we intended, but our provider figured that out and forwarded the email on to me.

The requestor was aware of our move to YouTrack but apparently did no investigation to whether or not any of their data was on there. I can't fault them too much here as I looked and apparently I never documented anything about the migration to YouTrack.

So knowing that all of the issues had already been anonymized and that we're redirecting the links from developer.pidgin.im to YouTrack, I knew we were in the clear there. That just left the wiki.

So I have a copy of the entire static dump we created of developer.pidgin.im. It is 30gb of uncompressed text and 1,142,949 files. It contains everything except the tickets that we redirect away from as I crawled the live site directly which had the redirects in place.

grim@spectre:~/d/trac-static$ du -sh
30G .
grim@spectre:~/d/trac-static$ find -type f | wc -l
1142949

So to check the WIKI, I have to grep through all of it. Even on my beefy machine, this takes a fair amount of time as you can see from the output below.

grim@spectre:~/d/trac-static$ time grep -ri RequestorsUserName * | grep -v 'developer.pidgin.im/query' | grep -v "developer.pidgin.im/timeline" | cut -d: -f1 | sort | uniq -c

real    2m21.859s
user    0m38.984s
sys 0m29.105s

I'm ignoring the query and timeline paths because they're related to tickets and weren't redirected until after I created the dump.

At any rate, you can see that we did not find any hits for the requestor.

So while the requestor was able to help us find our misconfigured email address, everything else was left to us to determine if any of their data was even visible publicly.

Now I completely understand the desire to be forgotten, but Pidgin like most Open Source projects is completely run by volunteers and when you're forcing them to do work when you haven't do any it takes them away from working on the project and that's not good for anyone.

Code signing HSMs for Pidgin2

Gary Kramlich — Wed, 22 Jan 2025 07:30:32 +0000

We haven't done a Pidgin 2 release in awhile because aside from other things, I've been unable to sign the Windows binaries.

I bought a new code signing certificate in March of 2024 and it came on a Hardware Security Module (HSM). This is a USB device you plugin into your machine and it contains a private key that allows you to use it without exposing it. The main issue with the HSM was the complete and utter lack of documentation that came with it. So I messed around with it for awhile, but couldn't figure it out. We had no pressing reasons to release so it sat.

In October, rekkanoryo was visiting and with his help we identified that when plugging it in to a Windows host it would show up in the certificate store. We spent a lot of time trying to figure out how to get it to work with osslsigncode but apparently we needed to use pkcs11 and neither of us had any experience with that.

So we ended up trying signtool from the Windows SDK and were able to get it to sign a Pidgin executable, but only when calling it from command prompt. We tried integrating it into our build system but we had zero luck.

Before I go into more depth, lets describe our build system. Our build system on Windows is a collection static Makefile's that depends on a POSIX shell like Bash to work properly. As you might have guessed, these Makefile's can get pretty complicated. For the shell part, we used to recommend cygwin but I've been using Msys2 for awhile now.

So to make this work, we needed to be able to run signtool from a shell running under msys2. However, whenever we'd run the command it would complain that we didn't provide the /fd argument even though it was for sure there. We ended up trying multiple versions of signtool as well and still no luck.

At this point, we started trying to launch a command prompt process with the command using the /C flag to run it. But this wasn't running the command and just giving us a prompt. We gave up at this point as we were out of idea.

So some more time went by and more and more issues started pressing for a Pidgin 2.14.14 release. The certificate prompts, the GCC14 and GCC15 compile errors, as well as the libxml compile errors were all pushing for a new release. So I started looking at this again today (January 21st).

Everything was fuzzy as it had been 3 full months since we looked at this and rekkanoryo and I both forgot a lot of the finer details of what we attempted. Because of this I started trying to get this working with PKCS11 again.

After an hour or two of searching and trying random things I finally learned that the module piece of PKCS11 is specific to your HSM. So I spent about 30 minutes looking to see if the vendor for my HSM provided one. I didn't find anything. So back to signtool I went.

Originally I was testing by modifying our Makefile's and waiting for them to get to the failure point and then tinkering from there but that obviously took a lot of time and got old quick.

So I went back to trying to run the command manually from msys2. But this was just failure after failure. I then realized I should just try running something like cmd.exe /C /c/Program Files (x86)/.../signtool.exe /? and see if I could get the usage out of it. But to my surprise I just got a command prompt in my msys2 Window. So it was clear at that point that that method wasn't going to work no matter how hard I tried.

That's when I got the idea to just put the command in a batch file and to try running that from msys2. So I threw the /c/Program Files (x86)/.../signtool.exe /? into a file named sign.bat and ran it from msys2 with ./sign.bat. To my great surprise, I got the usage.

I then updated sign.bat to include the full command and holy crap it works! We'll almost, I was connected to the machine via RDP and the HSM doesn't work when it detects an RDP session as a security feature. So I quickly ran over to the machine and ran the command again. This time the HSM software popped up asking me for the password to unlock the key. I entered it and SUCCESS!!

I then went to verify the signature and noticed that it only included a signature with a SHA-384 digest.

So this should work fine with with Windows 10 and 11, but we have people running Pidgin 2 on Windows as old as XP (I know..). We need to keep supporting that or they will complain, loudly.

After some digging through the signtool documentation, I determined that we can add multiple digests by running signtool again and pass the /as argument and a different value for the the /fd argument.

So with that done, the signatures look a lot better and we should be able to release now and not break anyone on very old Windows.

We still would like to have some people test on Windows XP, Vista, 7, and 8, so if you have any of those installed, please let me know so I can get you a file to try it out.

This has been ton of work, but it's finally done. I wrote a quick post in our discourse with the actual final setup in the event that they're useful to someone else and so that I have a backup in case I need it.

I hope you found this story interesting, but I hope to never go through it again :)

Tailscale Kubernetes Operator

Gary Kramlich — Wed, 14 Aug 2024 19:40:54 +0000

Apologizes to anyone looking for more #Pidgin content. I know it's been awhile and I'll get something out soon I promise, but there are quite a few Pidgin related things in this post too...

About a month ago I setup a Kubernetes cluster using Talos to handle my container load at home.

I have containers for all sorts of things including the graphs you all may have seen on my stream as well as an Ergo instance for developing our new IRCv3 protocol plugin.

I'll be adding to this cluster in the future too as we continue development on Xeme which is our new XMPP library as well as Myna which is our new Matrix library.

Having these servers running locally makes it easier to test interesting configurations, but more importantly, lets me use them on stream without leaking my IP address or any passwords.

Anyways, I'm not always at home when I want to work on something and I wanted to find a way to access services remotely. Well tonight I realized I should be able to do this with Tailscale.

I'm already using Tailscale to make sure we can access all of our build agents which are spread across a few sites, so being able to expose this to the other Pidgin developers who have access to that Tailscale network is just icing on the cake.

So I decided to give the Tailscale Kubernetes Operator a go. They have full documentation it here. As is pretty typical right now their installation instructions are based on using Helm.

I prefer to use Kustomize over Helm. There's plenty of reasons, but there's no reason to get into that now ;)

Thankfully, Tailscale provides a static manifest for deploying the operator. This is very easy to import into our kustomize and get running directly quite quickly.

But of course, it's not just that easy. Their instructions have you modifying that manifest and then applying that. This isn't a big deal, but it makes upgrading harder as you have to keep track of what you edited. Sure you could use version control (and you should have your manifest in version control) but kustomize makes this very easy.

First we needed to download operator.yaml which is the static manifest that Tailscale provides. We're going to use this file as is without modification which means we can just replace it if/when they update it.

Next we need to create our kustomization.yaml which is used to drive everything. My commented kustomization.yaml is below.



---
# Here we reference the unmodified operator.yaml we downloaded from
# Tailscale.
resources:
  - operator.yaml
patches:
  # Tailscale needs network admin and some other permissions, so
  # we use the following patch that will add the appropriate
  * annotations to the namespace.
  - patch: |-
      apiVersion: v1
      kind: Namespace
      metadata:
        name: tailscale
        labels:
          pod-security.kubernetes.io/enforce: privileged
          pod-security.kubernetes.io/audit: privileged
          pod-security.kubernetes.io/warn: privileged
secretGenerator:
  # As I mentioned earlier, operator.yaml defines a secret for the
  # tailscale oauth secrets which the documentation wants you to
  # modify manually. We can instead use a secret generator to read
  # those values from an `env` file and merge them into the
  # existing secret.
  - name: operator-oauth
    namespace: tailscale
    behavior: merge
    envs:
      - secrets/env

With this all now setup, we can run kubectl kustomize and verify our output. A condensed output with just the namespace and secret are below.



apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/warn: privileged
  name: tailscale
---
apiVersion: v1
data:
  client_id: aGFjayB0aGUgcGxhbmV0
  client_secret: aGFja2VycyBvZiB0aGUgd29ybGQgdW5pdGU=
kind: Secret
metadata:
  name: operator-oauth
  namespace: tailscale
type: Opaque
---

Now that we've confirmed everything looks good, we can get ready to apply it to our cluster. Normally I'd recommend doing a dry run first, but since we're applying a namespace as well most of the tests will fail because that namespace doesn't exist.

Anyways, we can apply this kustomization with the following command:



kubectl apply -k .

If everything is successful you'll see something like the following:



namespace/tailscale configured
customresourcedefinition.apiextensions.k8s.io/connectors.tailscale.com configured
customresourcedefinition.apiextensions.k8s.io/dnsconfigs.tailscale.com configured
customresourcedefinition.apiextensions.k8s.io/proxyclasses.tailscale.com configured
serviceaccount/operator configured
serviceaccount/proxies configured
role.rbac.authorization.k8s.io/operator configured
role.rbac.authorization.k8s.io/proxies configured
clusterrole.rbac.authorization.k8s.io/tailscale-operator configured
rolebinding.rbac.authorization.k8s.io/operator configured
rolebinding.rbac.authorization.k8s.io/proxies configured
clusterrolebinding.rbac.authorization.k8s.io/tailscale-operator configured
secret/operator-oauth configured
deployment.apps/operator configured
ingressclass.networking.k8s.io/tailscale configured

You can verify the operator is up and running the following command:



kubectl -n tailscale get deployments

You should see something like the following:



NAME       READY   UP-TO-DATE   AVAILABLE   AGE
operator   1/1     1            1           72m

If that all looks good you can go ahead and verify that it shows up in the Machines section in Tailscale. You should see something like the following:

Now we're ready to expose a service via Tailscale!

As I mentioned earlier, I'm running an Ergo instance for local IRC development. I have an Service of type LoadBalancer to expose it to my LAN via MetalLB.

The Tailscale operator has multiple ways to integrate with your Kubernetes cluster, but we're just going to expose existing services to the tailnet and doing that is extremely simple.

To do so, you just need to add the tailscale.com/expose: "true" annotation to the service. Below is my updated Service for Ergo:



---
apiVersion: v1
kind: Service
metadata:
  name: ergo
  annotations:
    tailscale.com/expose: "true"
  labels:
    app: ergo
spec:
  ports:
    - port: 6667
      protocol: TCP
      name: irc
    - port: 6697
      protocol: TCP
      name: ircs
  selector:
    app: ergo
  type: LoadBalancer

Now that that's done, I can apply the Kustomization for Ergo:



kubectl apply -k .

The operator will automatically add it to the tailnet with a machine name of <namespace>-<service-name>. This ergo instance is running in the reaperworld namespace so it's machine name, and therefore DNS name is reaperworld-ergo which we can now see in the Tailscale machines page.

And that's it, that service is now available on the tailnet accessible to anyone else on the tailnet!

I hope you all found this interesting. I decided to write this as I had to learn about behavior: merge property of the secretGenerator and figured others might find this useful as well. Plus it gave me an excuse to show the power of Kustomize!

Random Thoughts on Implementing Reactions

Gary Kramlich — Fri, 14 Jun 2024 20:48:09 +0000

I was randomly thinking of how we'd integrate stuff like Mastodon, Twitter, Facebook posts, YouTube videos, and so on into Pidgin 3. Now I'm not saying I'm planning on implementing these, but thinking about these helps determine how the interface should work to make them possible while still supporting traditional chat applications.

Replies/comments will be easy as they'll be built into libpurple. The protocol would just treat each post or whatever has a channel or group direct message and then everything else is business as usual.

However reactions might get weird because some of these only allow a few different reactions. For Mastodon and Twitter this is star/like, YouTube is thumbs up and thumbs down, and Facebook has it's normal 6 or whatever reactions.

Reactions are something we need to have and it's a topic I haven't actually spent much time thinking about it, but it's going to be coming up soon (tm), so I've been slowly working the problem.

In traditional chat applications you can usually react with anything from the Unicode Emoji list which would have made this whole thing easy if that were the only thing you could react with.

However, other chat networks have custom emoji that can be used as reactions too. Discord in particular makes this kind of funky because some servers won't allow custom emojis and other servers only let you use their custom emojis on their server.

With that background now, it becomes obvious that the only real way to determine what reactions are available for a given message is to ask the protocol plugin itself on a per message basis.

This means that we will have to add additional API to do this. This is anything major, and protocols that have a static list of elements, like Mastodon, Twitter, YouTube, etc will just have a simple function that can return the available reactions, where as something like Discord can go and ask the server what's available if need be.

Now that the UI knows what reactions the user can use, it can then pass it on to the protocol which will actually pass it on to the server doing what it needs to do.

We still need to figure out the exact representation reactions, which will probably just be an id,icon-name, anddescription`, but since most reactions are repurposed emoji, we'll probably have to wait until those are sorted out before moving forward.

At any rate we now have some ideas on how to move forward here which is always a good place to be :)

Why so rude?

Gary Kramlich — Thu, 21 Mar 2024 05:00:00 +0000

Having worked in the open for over 20 years I've conversed with people from all over the world and all different walks of life.

Recently I've noticed something troubling. Now this probably won't come as a surprise to many, but lately I've been running into people that just can't seem to understand that the experiences of others can be different than their own.

I know respect for multiple perspectives is hard, but the issues seem to have even grown to include simple mundane things about life where people can't look outside of their immediate surroundings.

The other night while watching a Twitch.tv stream, we (chat) got into a discussion about starting vegetable seedlings before planting them in a garden. One chatter said something along the lines of

lol you should have started that months ago.

I responded with

We're clearly in different hardiness zones as I'm still about 8 weeks out from the last freeze. Hell it even snowed yesterday...

The chatter then responded with something like

Oh yeah, I'm in Florida, we don't get frost.

Based on their initial response I knew that something like this response was coming because this has become a typical interaction for me.

I know I'm probably over analyzing this as I'm writing a blog post about it, but the original response comes off as disrespectful, elitist, and completely lacking in humility.

I have interactions like this all the time and I honestly don't understand why. Someone will just blurt out something that's obviously subjective, with a high level of confidence, and in some cases will even try to mock the person they're responding to.

I don't know if it's some statistical anomaly or what, but people do this to me constantly. In the official Pidgin channels, my own Twitch streams, random chats, forums, wherever. People refuse to acknowledge my reasoning, see it as an attack against them, and then start rambling nonsense at me. It's gotten totally out of control.

Unfortunately When I've tried to confront this behavior, no matter how gentle I try to be, it's almost always seen as an attack against the other person. This is very ironic as typically they're the ones being rude and obtuse in the first place.

A common example of this is that someone will mention that "Pidgin isn't a good IRC client". That is their opinion and I have no issue with that, but as the project maintainer, I would REALLY like to know what we can do better.

Unfortunately these discussions tend to devolve extremely quickly. People feel like I'm putting them on the spot and become defensive no matter how sensitive I try to be.

I've seriously had people and observers think I was interrogating someone when I was using phrases like "I'd to hear your thoughts" or "could you be more specific?".

I've spent a lot of time reflecting on these discussions and the only thing I've been able to come up with is that it appears that people just like to be rude. So much so, that they'll only remember that they didn't like something, and completely forget what they didn't like about it.

Another example was in the exact same Twitch stream mentioned above. I mentioned that I was setting up a new build agent for Pidgin based on a Raspberry Pi 5 using an m.2 SATA drive.

Apparently that wasn't enough of a reason for people as the discussion immediately devolved into the typical "you can get a more powerful x86 machine for just as much" and so on.

Whether or not that is true depends on your own personal situation. However, the point I'm trying to make is that my personal reasoning for my choices were completely ignored while the discussion pivoted into a meta discussion driven by elitism.

On the plus side, I wasn't directly involved in the discussion anymore, but I still accidentally kicked it off, because surprise, people seem to have some very strong feelings about Raspberry Pis and feel the need to tell you all about them whether you want to hear them or not.

The reasons someone may be using a Raspberry PI is quite frankly, none of your business, and their mention of it is not an invitation for someone to start preaching to them. Perhaps the Raspberry PI was was a gift or a hand me down from a mentor to a new enthusiast who couldn't afford one. In that case, and many others, the price difference is completely irrelevant and you're just making yourself look bad by being rude and pedantic.

As I mentioned earlier, this scenario happens to me all the time. This is precisely why I refuse to discuss why we don't use Git or GitHub for Pidgin.

No matter what reasoning or data I provide, it won't be enough for defenders of the monoculture. This group tends to think that there is one correct way to do things and everything else is empirically wrong and deserves immediate debate.

There's a similar group that will try to bait you into these debates with prompts like "I'm curious why you use ". For some reason they believe they deserve an explanation and will get indignant if you don't give it to them immediately.

Both of these groups are more interested in proving that their narrow focus is correct. They will ignore anything to the contrary and expect you to stop what you're doing and defend your stance immediately and attempt to sway their opinion, which can not be done. Many of them will also try to continue the discussion when you try to walk away. They're not interested in understanding, just their correctness and their ability to assert it.

As you might imagine, this is not only extremely exhausting and unproductive, it's also extremely hostile. No one wants to have to defend their choices constantly. Many people will write a blog post explaining their stance and point people to it like I'm doing now, but that has its own set of problems.

Many people have asked me to write a blog post on my preference of Mercurial over Git and so far I've refused and will continue doing so for the foreseeable future.

I already know what the comments section will be like. I see it in trivial discussions like those mentioned above and I've seen it in this specific case too many times to count. I already know what the Hacker News and lobste.rs comment sections will look like because this topic has been rehashed so many times.

Nothing productive ever comes out of it and no one's "curiosity" is ever satisfied. Maybe a few people learn about some alternatives, but the only thing stopping them from even looking for them in the first place is the status quo of the monoculture.

More importantly, there is nothing for me personally to gain here. My choices are made from my own opinions which are based on my own experiences. Even if someone were to gain some insight from my description, they can't necessarily act on it due to the incompatibility of Git and Mercurial and the monoculture around Git will continue to enforce that until a new contender appears.

If you've ever had a discussion with me that sounds like what I've described here, there's a good chance I ended up avoiding responding to you, timed you out, or banned you. Hopefully this post helps to explain why that happens.

Likewise, if you've ever seen me quietly disappear from a community it's most likely because I reached my limit of dealing with interactions like this.

I try to do my best to be understanding of cultural differences and translation issues that occur when interacting with individuals where English is a second language, but eventually my patience will run out and the only thing left that I can do is to leave.

Why is there no mobile version of Pidgin?

Gary Kramlich — Thu, 01 Feb 2024 06:00:00 +0000

We frequently get asked when a mobile version of Pidgin will be available or why it doesn't exist. There's actually quite a bit to it which makes for a decently sized blog post. So... Here we go!

It is completely feasible to write a libpurple user interface for Android, iOS, or any other mobile operating systems. In fact Palm Inc. used libpurple as the backend for their messaging application in WebOS since version 1.0 in 2009. But the problem for the Pidgin team is that we just don't have the resources and expertise to create and properly maintain these additional versions.

There was an attempt at libpurple on Android via a 2012 Google Summer of Code project. But that project had to manually write JNI bindings so that libpurple could be accessed from Java.

Modern innovations like GObject Introspection with JGIR have basically solved this issue and made Android development with native libraries nearly as easy as doing so with Objective-C or Swift on iOS.

So while this is technically possible, we come back to the issue of resources. Currently there are 2 people, including myself, actively working on Pidgin in their free time. However, neither of us know Android or iOS development at all.

For us to create additional user interfaces is to increase our workload immensely and take a lot of time away from Pidgin. We're currently struggling to keep Finch, our Ncurses user interface to libpurple, up to date as well. So much so that I will soon be calling for someone to step up and take over the Finch project in the near future.

The next hurdle to deal with is the terms of services for both the Android Play Store and the iOS App Store. libpurple connects directly to chat networks. What this means is that for multiple networks like Discord, Slack, Google Chat, Microsoft Teams, etc is that we are generally breaking their Terms of Service because they do not allow third party clients.

While this can be debated, this essentially counts as "unauthorized access" to these networks which is forbidden in the Android Developer Distribution Agreement § 4.9. However, the iOS App Store Review Guidelines § 5.2.2 states that you need explicit permission to connect to these networks which we won't get.

There's also the FOSS clause in the Apple Developer Program License § 3.3.4 A v which normally requires an exception to be granted by the copyright holders of the FOSS application. For Pidgin, that includes everyone in our COPYRIGHT file.

As you may have noticed, we don't have contact information for any of those people. Even if we did, it is probably safe to say that at least one of them is no longer with us, which makes this all impossible. But even if that wasn't the case, you might also have noticed that Sun Microsystems is credited in there as well.

Sun Microsystems was acquired by Oracle in 2010 and I have no idea whether or not their copyrights on their contributions to Open Source projects were included in that acquisition. This would probably require getting lawyers involved and just isn't important to us right now and I'm not sure it ever will be.

So essentially the app stores are not an option. We could do the work and take the chance of being taken down, but that doesn't sound like a good use of our extremely limited time.

After that, people generally ask about side loading. While it certainly is an option on Android, it isn't nearly as easy on iOS. This could possibly change depending on the results of Epic Games v. Apple but that's just speculation.

Regardless, building an application that can only be side loaded means your potential audience is very small and that you'll have more support requests for installation and updates than you would on any other platform. For those reasons, this is not an avenue we intend to go down.

So let's pretend for a moment none of these issues existed and that the only barrier to Pidgin on mobile was resources. Even then there's a huge problem lurking in the shadows, notifications.

On mobile platforms when the device goes to sleep network connections are typically terminated to save battery and network data. This works because the mobile platforms support push notifications which are basically a way to tell the mobile device that your application needs attention. For this to work, you need to know when to send a push notification.

For Pidgin to do this, we would need a server that knows when your messages come in and then send the push notification. To know when your messages come in, we'd need your credentials and have to be logged in on the server side to receive those messages. This is not what we're trying to accomplish. We are not trying to create a cloud service nor deal with all of the complexity, privacy, and security concerns that come that.

So, without push notifications, Pidgin on mobile can't tell you when messages come in without keeping something running which will use more battery and network data than most people would like, which of course means additional support requests for a problem that we can't possibly solve.

All of these reasons are why we won't be releasing Pidgin on mobile any time soon, if ever. If you have any questions or comments, or if I got something wrong, please don't hesitate to comment!

Scary Code Base

Gary Kramlich — Thu, 26 Oct 2023 05:00:00 +0000

Often I refer to the Pidgin code base as scary. This is because it is very old, has implementations for things that there are libraries for now, is full of tech debt. Most of it was originally written by teenagers and people in their early 20's. In other words, not "professional" developers.

But that's okay. As you all know I was one of those people in their early 20's writing some of that scary code. And now I'm pushing to make that code more friendly. It's way more approachable from all points of view today, but of course there's still work to do.

However, that's not what I want to talk about today. Today we're going to talk about my philosophy when it comes to the attitude or approach I like to take with that code and how it can affect both our peers and ourselves.

I've explained this quite a few times on stream but found myself explaining it again in person and decided that I should really just write this down so that others can see it and hopefully add to it. So without further ado..

We've all been there before, getting frustrated trouble shooting some code and finally go "Who the hell wrote this!?" and immediately reach for our blame tool. We're frustrated and annoyed and we want to be angry at someone for it dammit!

We all know the meme about this, that 9 times out of 10 it ends up being yourself, or something to that nature. But the real question here is, "Why are we so angry about some code?" Sure this code is weird, hard to read/follow, and probably buggy, but why are we so mad at it?

Do we feel like that person that wrote that code was really trying to make things inconvenient for us? Do they have it out for us? Are they lazy? The answer to all of these questions is "who cares?"

In my experience, most developers are trying to do the best they can every day every line of code. Maybe they didn't know of a technique that you're aware of and would be excited for you to teach it to them, maybe they were or are going through some personal things and aren't able to do their best, maybe they're just having an off day and don't want to put up with your shit, or maybe they don't even work or contribute to that project anymore.

Getting angry about this is just nonsensical. It doesn't fix the problem and in most cases it's going to slow you down as you have to calm down. Sure it sucks, but programming is hard and no one writes bug free code that's completely optimal. If someone makes that claim, they're full of shit.

And sure, watching an experienced programmer work can look like magic as they dance their way around writing bugs and memory leaks, all while avoiding the documentation as they have most of it memorized, but this all comes down to practice, so much practice.

So what do I suggest instead? It's easy, just fix the code. Most of the time it doesn't matter who wrote the code, the real issue is the bug and the effects it's having on the people that use your software. They don't care who broke it, they care that it is broken.

But in the case that it does matter, it's more important when they wrote that code. If someone has been working on this code for long time and they're making mistakes, you should be helping them to do better, constructively by mentoring them not humiliating them.

Don't approach them like "Hey this code is shit..." that's going to immediately put them on the defensive and make the situation worse because now they're rightfully going to think you're an asshole.

Instead try something like, "Hey I was reviewing some code in this section and noticed there's better/simpler/easier way to do this. If you're interested just let me know and I can walk you through it when you have some time."

I know a lot of you are probably cringing at this, but even if someone is 100% completely objectively doing something wrong, they're way more open to discussion about it if you're courteous of their effort and their time. Also if you can't be polite to each other, you're probably not going to be working together much longer as well.

This all applies to code review too of course. Many people get anxiety about code review because they identify with their code. This gets reinforced by the blame wars and messes with the motivators to write good code.

Instead of writing good code to write good code which is rewarding, they start writing good code to avoid getting blamed/flamed/put on blast/whatever which is negative reinforcement and just creates contention between peers.

What I'm really trying to say here is, be nice to each other, including your past self. We're all constantly getting better and we are not our old, new, or future code.

And in the very rare case you need to find out who wrote some code and when, use annotate. In most version control systems blame is an alias of annotate and it has none of the negative connotations with it which helps check those micro biases.

I hope you're enjoying these posts! Remember they go live for patrons at 9AM CST on Mondays and go public at 12AM CST on Thursdays! If there's something specific you'd like to see me cover here, please comment below!

In Tree Protocols

Gary Kramlich — Thu, 19 Oct 2023 05:00:00 +0000

Determining what protocols to carry in our source code tree never really had a standard or process until recently. In this post I'm going to describe the process we're currently adopting and the events that led to it.

Way back when we used to accept protocols into the tree without much hesitation. For example, we added a protocol Plugin for GroupWise that was gifted to us by Novell even though we couldn't actually test it because we didn't have a GroupWise server.

We had similar situations with SameTime and Zephyr where we also had no access to a server which meant we couldn't test anything. It should come as no surprise that these protocols started to bit rot immediately only seeing updates when a technical user with enough patience would work with us to fix issues.

Other times new protocols would get added by existing Pidgin developers because of their interest in it. This was generally okay because if someone reached Developer status, they had gained enough trust from the other developers and were expected to be around for quite a while. See Pidgin Developer Tiers for a more in-depth description.

As you may have guessed, over time developers would lose interest in the protocols they brought in which would then of course start bit rotting as well. This happened with the popular protocols too, but sometimes that was just due to their complexity like the OSCAR protocol that AIM and ICQ used.

While bit rot is a huge issue, the bigger issue with proprietary protocols especially, is keeping up with changes. With proprietary protocols changes are never expected and must be reversed engineered. This of course is all expected as these are proprietary protocols and there aren't supposed to be third party implementations by design but it's a huge burden to stay on top of.

But the unexpected changes in proprietary protocols still aren't nearly as bad as dubious legality of the reverse engineering processes. While I believe we have always followed the law here, that doesn't mean our contributors have.

I recall one contributor, a very long time ago, that was boasting about de-compiling an official client and using that to write patches for us. We of course had to reject those patches as they would have put the rest of the project as risk as that method of reverse engineering is to the best of my knowledge, illegal.

This dubious legality even led to us losing a contributor a few years ago. This contributor had immigrated to the United States on a work visa, and the legal department at the company they were working for decided that this legal dubiousness wasn't an acceptable risk and stated they could no longer work on Pidgin while employed there.

We were of course understanding of the situation, and as you expect, the contributor found something else to do with their free time and hasn't returned to the project. There's no ill will here, but we did learn an important lesson here about how others see some of the code that we carry.

So with all that history out in the open, lets move on to how we're moving forward.

To put it succinctly, Pidgin 3 will only have Open Source/Open Specification protocols in its source code tree that we can actually test. In doing so we will remove all legally questionable source code from our tree and thus avoid the previous situation where we lost a contributor.

This means that the core protocols we'll be aiming to have are Bonjour, IRCv3, and XMPP. We're not aiming to have these all done by 3.0, but these are acceptable for us to have in tree.

You might have noticed that Zephyr is not on this list even though it's an open protocol. We actually already removed the Zephyr implementation because we could not test it and because some of the code still use K&R functions as well as other pre-ansi C stuff.

Similarly, SILC has been removed because we can't connect due to a crash. We're not sure if it's the client library or the server that is the cause and looking deeper into it didn't seem like a good use of time.

When it comes to proprietary protocols they are going to have to live as separate repositories. I know this has been problematic for users especially when it comes to stuff like Facebook, Discord, and others, but this is just the way it has to be.

For starters, when something changes in these protocols, updates need to come as soon as they're ready. Releasing Pidgin is, complicated to say the least, and is not quick at all. So if these protocols were in the main tree, we'd have to force them into micro releases to get them out as fast as possible because the protocol would be broken but that importance is hidden expectations of a minor version number. They'd also be subject to string freezes and other quirks about our release process.

But the real problem that users have with protocols not being in the main distribution is one of discovery. Sure we have the plugins list to help people find them, but most users don't go to our website.

The plan to solve this is to add an "addon store" inside of Pidgin, similar to the Chrome Web Store and FireFox Add-ons.

This has been a concept we've been designing for a while but haven't actually built yet. A few interested parties have put together a few proof of concepts, but we haven't quite gotten to an minimum viable product yet. If this is something you might be interested in, please reach out!!

So there you have it. Our new policy of including protocol plugins into the main source tree is that it must be Open Source/Open Specification. That means stuff like SIP, Mastodon, and Matrix could one day land in tree, but due to resources constraints, aren't on our road map.

Proprietary protocol plugins will all be moved out of tree (only Gadu Gadu remains at the moment) but we plan to help users discover them via an add-on store that will also keep them up to date.

Our History with VCS's

Gary Kramlich — Thu, 12 Oct 2023 05:00:00 +0000

I often get asked why Pidgin doesn't use Git. This post isn't going to talk about that directly, but instead talk about our history of using multiple different version control system and why we chose to make those moves at that time.

When Pidgin was originally created by Mark Spencer back in 1998 under the name Gaim, the main version control system to use was CVS. So that's what Mark decided to use.

However, this was before even SourceForge existed so Mark had to set up his own CVS server that he ran on his own domain as Open Source code hosting just wasn't really a thing yet.

The project remained on that CVS server for the next few years even as the the project declined as enthusiasm for EveryBuddy, later renamed Ayttm, took off.

Then in March of 2003, Rob Flynn picked up development of Gaim by creating a project in SourceForge. Unfortunately he created a new repository and copied the code in instead of importing the existing repository, but that's okay. However, this is the only version control history of the project that is not in our current repository.

Then in March of 2006 we moved to Subversion as SourceForge had recently added support for it as well as automatic conversions from CVS. At the time Subversion was seen as "CVS done right" which admittedly was a pretty low bar. But regardless, it was tantalizing enough for us to make the move.

Before we pulled the trigger to convert to Subversion we were discussing moving to one of the new distributed version control systems. This list included Git with Cogito, DARCS, and Bazaar.

We eventually ended up choosing Monotone in April of 2007. Like many at the time, we were very interested in better branching, merging, and offline commits. In the near future I'll do a post covering how we used to handle contributions and why these features simplified the entire process.

Then in January of 2011 discussion started on moving from Monotone to Mercurial. There are plenty of reasons why we chose Mercurial in that mailing list thread so I won't discuss them here, but the prevailing issues were lack of tooling and complex user interactions.

We're still using Mercurial today (as of October 2023) and have no desire or need to move to another version control system. The main reasoning for this is that we don't really have any issues with our current setup and any change to it would essentially be busy work.

Also it appears that all of the innovation in version control seems to only be happening in Mercurial. See Changeset Evolution and Clone Bundles for some examples of those innovations.

I hope you enjoyed this trek down memory lane. As I mentioned earlier this is just historical information and not intended to sway someone's opinion. Also, we're not looking for opinions on switching VCS's any time soon either, so please keep those comments to yourself ;)

Talkatu's Future

Gary Kramlich — Thu, 14 Sep 2023 05:00:00 +0000

Previously I introduced you all to Talkatu. In that post I also talked about the uncertainty of Talkatu's future, well we've reached certainty now.

In the previous post I mentioned how emoji and how contacts are represented were causing issues. Well it's been quite a few months since then and I've yet to come up with a decent solution to any of those problems.

On top of that, the way we designed TalkatuHistory was modeled after what we had in libpurple at the time, which was to "write" each message to the conversation and therefore the history widget.

This doesn't work with what we were planning to do in Pidgin 3 by having a GListModel as a property of the conversation which is how we were planning on integrating the History API into everything.

While we could easily move TalkatuHistory to using a GListModel it just doesn't make sense to do so with all of the other issues.

That means that yes we've finally decided to stop developing Talkatu itself. We're going to keep the project around as it has been great at helping us prototyping ideas and we may want to use it for that again in the future.

This means that we will be integrating the Talkatu widgets into Pidgin 3. We're starting with TalkatuHistory but this won't be a direct copy or anything as TalkatuHistory is a GtkListBox and PidginHistory will be a GtkListView.

I still really like the idea of the TalkatuMessage interface that allowed the input field for conversations to be a TalkatuMessage as well as it could then be passed on to whatever was sending the actual message.

We might still go that route with PurpleMessage, but it'd require a bit of renaming and stuff, but it would also allow us to create more complicated messages later. Something that could potentially handle widgets and actions which seems to be all the rage in proprietary chat clients nowadays.

At any rate, Talkatu was a great middle ground that helped us find a path forward. I have no regrets about developing it as we will be using basically all of its features directly. Also it's still a really great name and we'll need to find a way to honor it in Pidgin 3.

A narrowing of focus...

Gary Kramlich — Thu, 07 Sep 2023 05:00:00 +0000

Awhile ago I wrote about what we were targeting for Pidgin 3.0.0 Alpha 1.

At the time this felt like a good step forward as we didn't really have a road map or anything and this was precisely that. Except it wasn't, it turned out to be more of a nebulous list with little to no direction. Unfortunately it took awhile for me to realize this, but a solution was pretty easy to find.

So, instead of just going through that list, we're going to focus on getting the new from scratch IRCv3 protocol plugin to the point where I can start using it with Pidgin 3 as a daily driver.

Not only does this give us some much needed direction it will also finally get me using Pidgin 3 as a daily driver. On top of that, it'll create a good cycle as I will be able to find and fix bugs much faster as they'll be directly affecting me.

So realistically not much is going to change from what we were doing before, but the 3.0.0 Alpha 1 issues will be prioritized to get IRCv3 working using all of the new APIs that we've been developing.

Busy Busy

Gary Kramlich — Mon, 04 Sep 2023 19:39:27 +0000

Hey everyone, sorry I haven't been posting lately. I keep intending to, but then all of a sudden it's Thursday or something and I've never posted.

That said, I have the next 2 post scheduled and I'm hoping to stay a post a head which will help keep these posts consistent.