Fringe Mastodev
Part III: Joining GlitchSoc

GlitchSoc

When I published the first chapter of Vague, I really was hoping to be done with Mastodon development for a while. It hadn't gotten me anywhere, hadn't made much of a difference to the software, and didn't seem to be sustainable. I wanted to refocus my time on my passions—writing, especially, and on making things, and bringing light into the world. Vague was experimental, but the hope was that it would help me build the chops (and—although it was a longshot—the audience) to pursue writing more actively in the future.

All of that got pushed aside a few weeks later, however, when @bea made me an offer I couldn't refuse.

The context: After publishing Mourning Mastodon, I made good on my efforts to stay out of MastoDev—at least, the Mastodon development that was happening at that time. What I would do, however, was post little historical note threads to my Mastodon account, divulging the history of various features and how they had sprung into being—something which doesn't get talked about enough, imo, and something which I still do from time to time. These threads attracted @bea's attention—although at the time I mostly identified her (perhaps rightfully) as part of the glitch/tech/hacker crowd, which I wasn't (amn't) really a part of and didn't (don't) really understand. Apparently (looking at GitHub), there were already the beginnings of an attempt at implementing some glitch hacks onto Mastodon in these early days, and these were completely not on my radar, probably for this reason.

In any case, during the course of my postings I had noticed there was a discrepancy between the way in which characters were counted in the Mastodon frontend, and the way in which they were counted in the backend's status validator. (This sort of minute detail is an incredibly me thing to notice and look into, as those of you who know me probably know well.) Because I'm a Unicode sort of gal, and was curious, and familiar with the Mastodon codebase, I tracked down the exact lines in Mastodon's source which were causing the problem. I posted these findings to my Mastodon account, and @bea offered to let me try patching it live on her development instance, dev.glitch.social.

In the private discussions with @bea which followed, I explained that I had actually stopped doing Mastodon development, given my past history with it and the way it had treated its queer contributors. She responded that she had heard that a lot, thought it was sad, and was actually trying to pull together a fork of the software, as a space for queer devs who had been pushed out of mainline Mastodon development. Her focus, she said, was on trans women, and creating a safe place where their contributions would be heard.

I'll admit—I had a moment of hesitation. After cis white men, techy trans women are one of the largest and most influential demographics on Mastodon, and already had a long and established history of contributions both to the Mastodon culture and to its codebase. Although I was vocal about ensuring these contributions received the recognition they deserved, and concerned about the long‐term viability of trans Mastodon development (see Mourning Mastodon lol), trans women were far from the top of my list of underrepresented groups in need of support. I didn't (don't) think that Mastodon's less‐than‐stellar history of responding to race‐related issues would be resolved by anything other than a significant nonwhite presence in the development staff—and that, far more than Mastodon's handling of queer issues, was what had gotten me into Mastodon development. A trans‐dedicated fork could well end up in tension with those goals if—as historically had been the case on Mastodon—those trans women trended overwhelmingly towards being white.

On the other hand: How many major user‐facing open‐source projects are significantly‐to‐entirely owned, operated, and dedicated to trans women? For a time at least, that was GlitchSoc. It was a big deal, and I couldn't exactly say no.

Needless to say, Vague got placed on hold.

(NB: GlitchSoc is now over a year old, and has undergone a number of internal changes during that time, for a variety of reasons (some of which I will get into later in this series). Although we might be able to point you in the direction of current active staff and developers, neither @bea nor I are currently involved with development or management of the fork in any significant, day‐to‐day way. There are probably better people to approach if you want to know what the status of the fork is right now! —KIBI Gô)

First Week of Features

Over the course of the next week, I implemented on the GlitchSoc fork a number of features, some of which I had previously tried and failed to get into upstream Mastodon:

• User‐defined profile metadata [20 June 2017; upstream issue @ 23 November 2016 (-209 days); upstream adoption @ 14 April 2018 (+298 days)]
• Collapsible statuses [21 June 2017; upstream issue (a less‐featureful request and implementation, solely for collapsing long toots) @ 22 November 2016 (-211 days); original upstream PR @ 28 February 2017 (-113 days); upstream adoption @ 27 September 2018 (+463 days)]
• User‐controlled layout [with help from a friend; 24 June 2017; upstream issue @ 11 October 2017 (+109 days)]
• Images inside CWs [25 June 2017; upstream issue @ 05 April 2017 (-81 days); original upstream PR @ 27 June 2017 (+2 days)]
• An in‐app settings modal [28 June 2017]

When I first arrived at dev.glitch.social, I was able to make these commits straight to master, because I was more‐or‐less the only one around. (NB: Dev on production and break stuff often was the Original Glitch Ethos—but then we got all popular.) By the end of that week, a number of users had moved over and were considering making DevGlitch their main. I can't take full credit for this—the dialogues taking place on the Discord server and @bea's outreach definitely contributed to our early popularity as well—but it isn't exaggerating to say that my early involvement implementing these features was a huge factor in getting the project off the ground.

Summer of Go

Although my early work with GlitchSoc received a fairly wide amount of acclaim, it was, in essence, a week's worth of hacks, and I still had my sights set on other things. I visited the beach, and a friend and I chatted about making a visual novel engine in Qt+Go, tentatively titled Kirin VN. I spent a week or two playing around in Go and learning the language—one thing in its favour, Go is incredibly fast to learn.

Go's channels seemed incredibly well‐suited to feed‐based applications, and so I toyed around with creating a Mastodon API library in the language. It was titled Ratatootille, and all the components were given culinary names, like Mirepoix and Roux. I was frustrated with the lack of native apps for Mastodon on desktop platforms, and saw Ratatootille as a potential first step to getting there. (Ratatootille was never finished—my time got taken up with other projects before I had the chance to bring it to a working state.)

As I developed these projects over the summer, I remained involved in the Glitch community, moving my personal account over to @kibi@glitch.social and leaving my Icosahedron one open for more political conversations. (For a while—after all my involvement with Mastodon politics and community drama, however, I really needed a break, and so that account gradually fell out of use.) I continued to hold conversations about the state of Mastodon and the potential for new features on the GlitchSoc Discord, and added polish to the various things I had already implemented, slowly converting them from quick hacks into more fully‐developed features. I came up with absurd things like ƔAML (pronounced Garglamel), the subset of YAML's syntax which GlitchSoc used for its profile bio metadata.

/*********************************************************************\

                                       To my lovely code maintainers,

  The syntax recognized by the Mastodon frontend for its bio metadata
  feature is a subset of that provided by the YAML 1.2 specification.
  In particular, Mastodon recognizes metadata which is provided as an
  implicit YAML map, where each key-value pair takes up only a single
  line (no multi-line values are permitted). To simplify the level of
  processing required, Mastodon metadata frontmatter has been limited
  to only allow those characters in the `c-printable` set, as defined
  by the YAML 1.2 specification, instead of permitting those from the
  `nb-json` characters inside double-quoted strings like YAML proper.
    ¶ It is important to note that Mastodon only borrows the *syntax*
  of YAML, not its semantics. This is to say, Mastodon won't make any
  attempt to interpret the data it receives. `true` will not become a
  boolean; `56` will not be interpreted as a number. Rather, each key
  and every value will be read as a string, and as a string they will
  remain. The order of the pairs is unchanged, and any duplicate keys
  are preserved. However, YAML escape sequences will be replaced with
  the proper interpretations according to the YAML 1.2 specification.
    ¶ The implementation provided below interprets `<br>` as `\n` and
  allows for an open <p> tag at the beginning of the bio. It replaces
  the escaped character entities `&apos;` and `&quot;` with single or
  double quotes, respectively, prior to processing. However, no other
  escaped characters are replaced, not even those which might have an
  impact on the syntax otherwise. These minor allowances are provided
  because the Mastodon backend will insert these things automatically
  into a bio before sending it through the API, so it is important we
  account for them. Aside from this, the YAML frontmatter must be the
  very first thing in the bio, leading with three consecutive hyphen-
  minues (`---`), and ending with the same or, alternatively, instead
  with three periods (`...`). No limits have been set with respect to
  the number of characters permitted in the frontmatter, although one
  should note that only limited space is provided for them in the UI.
    ¶ The regular expression used to check the existence of, and then
  process, the YAML frontmatter has been split into a number of small
  components in the code below, in the vain hope that it will be much
  easier to read and to maintain. I leave it to the future readers of
  this code to determine the extent of my successes in this endeavor.

  UPDATE 19 Oct 2017: We no longer allow character escapes inside our
  double-quoted strings for ease of processing. We now internally use
  the name "ƔAML" in our code to clarify that this is Not Quite YAML.

                                       Sending love + warmth eternal,
                                       - kibigo [@kibi@glitch.social]

\*********************************************************************/

Notably, during this time, the initial steps were taken towards GlitchSoc's multiple frontend support. Splitting out the frontend and the backend was something I had been passionate about since my work with Ardipithecus—however, thanks to Mastodon switching over to Webpack for for asset management, it was now possible to support on a per‐user basis. I rewrote significant parts of Mastodon's Webpack configuration and created a first‐steps implementation on 30 July 2017, then rewrote it to use YAML configuration files on 25 September 2017. During that time, upstream Mastodon implemented its own theming support; however, unlike GlitchSoc, these themes were limited to switching out stylesheets, not replacing the whole frontend. I would eventually add support for this method of theming to GlitchSoc as well, calling total‐frontend‐replacement themes flavours and just‐stylesheet‐replacement themes skins (20 November 2017).

KibiWriter and Web Apps

At the same time as I was working on these big changes on the big GlitchSoc codebase (now deployed across multiple servers!), I was growing increasingly disillusioned with big codebases and applications in general. I didn't like the way that the Web App was trending—towards big, centralized apps which try to do everything, as opposed to small, personalized, forkable ones that do One Task Only, which I think the Web App model is inherently well‐suited for. I wanted web apps that looked and functioned like DSi applications, that came in multiple skins and colours, that could be saved to disk and run without needing a server, and which were written in human‐readable HTML and JavaScript such that anyone could modify them and make them their own.

To this end, and drawing inspiration from both the DSi and apps like OmmWriter, I created a small plain‐text writing app, which I called KibiWriter. It was essentially just a glorified <textarea>, and I threw it together in about a day just to show the sorts of low‐effort, compact Web App projects people could do if they ever bothered. (It was astonishing to me—given the simplicity of throwing a <textarea> on a page and styling it—that small, themed plain‐text editors aren't something that hardly anyone on the Internet has made before. Nobody builds web apps like this—and I don't understand why? I mean—it's personal, wholesome, and can't be used to turn a profit, so I guess I understand why… but that's precisely the problem, though.)

Small, hand‐coded web apps, webrings, and indie web design and publishing—these things were my focus as summer came to a close in 2017.

To be continued.