Identifying how broken the Matrix bridge is

This post is as a result of multiple failures of the Matrix<->Freenode bridge recently, and what I’ve learned using Matrix daily for several months.

The first note on Matrix is that depending on how the server/internet feels, it can take 30 seconds for a message to send, sometimes even longer. This can make debugging a bit more difficult, but ~30 seconds is a good cut-off if you are waiting for a message to send.

The first part of identifying how broken the bridge is is to look at if messages are coming though. If neither side is getting the other’s messages, then the bridge is potentially down. Matrix often reports this sort of outage on their Twitter & Mastodon, but don’t rely on that alone. When debugging it’s helpful to have another connection to the other side, such as using Freenode’s web chat. In #rit-foss we also have a bot that will respond if you send the message “test”

The bridge isn’t as simple as a boolean up/down though. You might discover that messages are going one-way. I’ve seen it go one-way in both directions before. And it can get even weirder. If you’re really familiar with IRC you probably know how there are multiple servers and what a netsplit is. Well, it would appear that the bridge can sometimes fail to recognize certain servers. I’ve seen cases in which I can only see a couple people talking, and also where I can see everyone except a couple people.

The most frustrating part of this is that since Matrix controls the infrastructure, you can’t a lot about this. Thankfully, the server and bridge are both open source, so you could run your own infrastructure, but that doesn’t solve the larger issue and also begs the question of whether you want to have to maintain it.

Ultimately this article fails fixing the issue, but hopefully helps is figuring out where and how bad the issue is when it does occur

[PCOMP: Project 3] Voice Chatbot

Project 3 was to do something interactive with audio. After some failures with audio input libraries, I managed to dig up a text-to-speech library for Arduino on GitHub. I then used a couple switches and a button to do binary-encoded input for selecting options in a menu. The project isn’t very expansive in its options right now, but it’s easily scalable. Due to the quality of the speaker output (I didn’t have time to build in the amp circuit that was provided for one), this also shows an interesting cognitive property of the brain in that if it knows what it’s hearing it can match the sound to the words (like with subtitles).


Some (not all) of the lines:

I am nothing but a simple Arduino, nothing to see here.
System Menu:
1. Greeting
2. Sing

FOSS in Design: An introduction

This project stems from an in-depth discussion (explained here) about the lack of FOSS being used within RIT’s design programs. More specifically, this project will be aimed at students, who have a very short time frame for work and already have some base knowledge of relevant concepts. I intend for this project to be applicable outside of students but when making priorities the student audience will be the most important consideration (when relevant). I feel that trying to bridge the gap is the most effective way to beget usage, as opposed to trying to completely retrain users or rewrite software.

What this project WILL (attempt to) do:

  • Centralize/aggregate existing information about how to use FOSS software
  • Create resources to bridge the gap in understanding between traditional/”industry standard” software/workflows with FOSS ones
  • Focus on what’s available now rather than saying to come back in a year [or any other distant amount of time] (as a student, a couple months is most often a really long time (the scope of assignments is often a week and for many projects still less than a month); the luxury to wait is not something easily viable)
  • Explanation of basic FOSS concepts, limited to what’s directly relevant for target audience (who is expected to have little/no familiarity with FOSS)
  • Attempt to build a reasonable expectation for how the software will work compared to the nearest traditional/”industry standard” software

What this project will NOT be:

  • A comprehensive training manual for the everything relating to a given field; some base knowledge of concepts is assumed
  • A moral/ethical manifesto; I’ll explain why FOSS is good, but I’m not going to force you to use it, nor force you to accept other’s morals/ethics (although you’re welcome to choose to do so)
  • An explanation for why you can’t do your homework; you might have a specific feature that isn’t supported, and you might need to revert to Photoshop (or another piece of software) to do that; it happens occasionally

What does success look like?

A successful outcome would be having a readily-available resource to allow users familiar with traditional/”industry standard” software to be able to be able to pick up and use FOSS software with minimal adjustments to their workflow beyond some initial setup. Over time, familiarity with the toolchain will create the ability to go outside what they’re familiar with, but this project will aim specifically for a “grab & go”-style approach on the part of the end users.

What is the desired outcome?

Greater access to FOSS and open standards as acceptable methods of making and submitting work, or where that is not possible that ability to use FOSS and open standards to the fullest extent within a preexisting ecosystem.

What would I like to see in 3-5 years?

I would like to see FOSS & open standards to be accepted as a valid method of doing student work. Additionally, I would like to see it accepted in “the industry” if development is capable of making it industry-ready. For this project it’ll just mean that my work is easier and this project gets cleaner instructions.

FOSS in Design: Some background

This project started from hearing a rumor (via a professor) in RIT’s College of Imaging Arts & Sciences that free (both as in cost & as in freedom) software was not allowed to be installed on the lab machines for use (with an asterisk for where it’s too popular to not install). While this has not been confirmed directly by their IT department, that became irrelevant quickly. Upon hearing this rumor, I posted it in our FOSS channel on IRC to see what others thought of it.

This resulted in an important conclusion: disregarding whether the rumor was true when we went and dug up the list of lab software, there was a little FOSS, but ultimately there was a distinct lack of it. This semester there are more detailed lists of lab software, and it’s a bit better, but there is still a general trend that FOSS isn’t particularly accepted, and for many pieces of FOSS software it might only be available in a specific lab.

Where the main point of this project comes from has also been developed from a number of conversations with professors, both in CIAS and on the FOSS side. Here are the ones that have significantly influenced the direction of this project:

Me: “…with the state of how GIMP is right now, and how quickly development is happening, it’ll be at least a year before I’ll even be able to look at GIMP again as a potentially viable alternative to Photoshop.”
FOSS Prof A: (not seeming to see a point being made) “So?”
Me: “…since I’m here for only four years, one year makes a world of difference in whether I can use it or not.”
FOSS Prof A: “Ah, I see. To me, one year isn’t that long”

This exchange is one of the primary reasons why this project is aimed at students and specifically aimed at what is available now. It also highlighted the fact that software development happens at a different pace than usage, so a significant part of this project is finding what tools can accomplish this functionality in a reasonably cohesive manner.

Me: (listing off a number of features that GIMP lacks that are used heavily in my classes, non-destructive editing being a focus)
FOSS Prof A: “But do you really need those features? Can’t you just save a bunch of versions?”
Me: (explaining how non-destructive editing is non-linear and that’s way too much work)
FOSS Prof B: “Heh. Back in my day, we didn’t have the undo button. You kids these days have it so easy.”

(Yes, I actually got a “back in my day” and a “kids these days”) The influence this conversation gave to the project was that modern workflows have changed a lot since many of these pieces of software were written, and the use cases have also developed. There are a lot of old tutorials around for some of the older use cases, but some of the newer use cases aren’t well-documented. At the very least, there’s a lot of cleaning that could be done in some cases.

CIAS Prof A: “It’s the industry standard” / “In the industry, they will expect to be given [file format].”

This has become one of the cornerstones of this project: how to maintain integration with existing environments (bridging, not converting). This is easier to do with some software and file formats than others, but this project includes how to build interoperability yourself, not how to make others change how they operate.

What’s happened since?

A lot actually. I was approached by one of FOSS Professors about doing an independent study (not one of the two quoted above by the way) and ended up in this Project in FOSS Development class. I was originally doing some work for another project, and since had been starting to look like it wouldn’t get touched on again I was going to write a couple blog posts and then be done with it. However, I ended up on this project again and it’s giving me the opportunity to elaborate on this as well as try to build a resource for others. There has also been talk of continuing this in an independent study next semester since there’s more work here than can be done in one semester. I’ve also near-completed my personal FOSS suite for my own work.

So what’s next?

I’ve gotten down (on paper) all the things that were touched upon previously in conversations and am now in the process of turning that into something readable (you can read the introduction here). Additionally, I’ve started to do an in-depth look at how to best accomplish the goals of this project. As was determined in my last meeting about this, “just start writing [blog posts].”