Lain is one of the more interesting figures developing software in the fediverse right now. As one of the lead developers of Pleroma, they focus on the development of a lightweight social server that works with Mastodon apps, and even supports its web interface.

For the purpose of this interview, Lain insisted on keeping the details of their own identity private.

Tell me a little bit about yourself. How did you get into developing federated web applications?

I’ve been interested in free software for a very long time now, and I’ve always been suspicious of corporation controlled social media. I quit my Facebook account 6 or 7 years ago, mainly because I thought it didn’t lead to many positive interactions, and I didn’t like having one company control so much of my private data.

Around that time, I registered a Diaspora account and used that one a lot for a while. I also contributed to Diaspora a bit, implementing the redesign of the single page view. This was when you were holding that ship together 🙂 Still, after a while, I stopped using Diaspora. I guess following the #nsfw hashtag isn’t enough forever. I did start using Twitter, which I did not see as problematic as Facebook, because it’s all public data anyway.

I had once installed GNU social, but back then, the network was mostly Spanish socialists, so it wasn’t too interesting for me. I later read about Gnu Social on a tech discussion board and tried it out again. This was a few months after the ‘new’ Gnu Social servers (SPC, SLC, Gnu/Smug) came online. This time, there were a lot more interactions and just general fun things in the Fediverse, so I quickly stopped using Twitter altogether.
 
Of course, after using it for a while, some problems and missing features became apparent, so I started working on the tech side of the Fediverse.

What motivated you to develop a new federated social platform, rather than work on an existing one?

A few reasons. GNU Social, Friendica and Hubzilla were all written in PHP, and that’s not something that I want to do for fun. GNU Social’s code is also very plugin based, which makes it very extensible but also hard to read, because the execution jumps from one file to another in a way that’s not apparent without knowing the whole configuration. The modern frontend for Gnu Social, Qvitter, was also written in a somewhat weird half-php, half single page application style, which made it hard to change and understand, too.

As I had written a social network in Ruby for my work at around that time, I wanted to apply my experience to a new project. As Mastodon was going in a rather different direction, technologically speaking, I started writing my own system. This was also to get some experience with Elixir and the Erlang ecosystem, which seemed like a great fit for a fediverse server — and I think it is.

“That’s something I’d recommend to other fediverse projects, too: Write compatible APIs. I implemented the Mastodon API, too, so now we can use nearly all Mastodon apps, including the Mastodon UI itself.”

How did you initially develop Pleroma? What’s the history behind the project?

Some people think that Pleroma was a reaction to Mastodon, but that isn’t true. When I started working on Pleroma, Mastodon was still in very early stages. At first, it was a purely client side replacement for the GNU Social frontend, Qvitter. This is what is now Pleroma-FE. This one still works with GNU Social, and several instances use it. After this was done (or rather, worked well enough), I wrote the backend server with the same API as Gnu Social, so that Pleroma-FE would work with it.

This two-stage approach worked very well. I could quickly get something useful for me and others going and still work towards the goal. That’s something I’d recommend to other fediverse projects, too: Write compatible APIs. I implemented the Mastodon API, too, so now we can use nearly all Mastodon apps, including the Mastodon UI itself.

Pleroma is rapidly growing into its own unique community on the fediverse now. What has your experience been like in organizing and developing an open source project with volunteer contributors?

Mostly it has been very good. We are not hosting our code on github, but on our own gitlab instance at git.pleroma.social, which is widely seen as a good step to prevent outside contributions. Still, people seem to have no problems with registering there to make an issue or donate some code to the project.
 
By now, there are a few people beside me that have made significant additions to the code, and I’m very happy about that. It makes it easier to take a step back and let others do the work 🙂

One thing I’m not happy about is that it sometimes takes a bit long until I can properly review a merge request. I don’t want people to think I’m ignoring them, but sometimes a merge request (especially a complicated one) might sit there for a week or two. I hope with more people contributing regularly, reviewing will be done by other people, too. This already happens, and I hope it will be a lot more in the future.
 
Also, I hate writing documentation, so just having it appear in your Wiki page is a great feeling 🙂 I’m also very happy about people sharing their experiences with Pleroma on blog posts or helping each other out with installation and configuration, both on the fediverse and on IRC. I think it makes people feel welcome.

In the user community space, it seems that there is a bit of a schism between Pleroma and Mastodon. What is the overall relationship between both projects?

It’s true that there’s a perceived tension between the projects, but it’s mostly on philosophical grounds. Technologically, I disagree with a lot of the things Mastodon does, but they can run their project however they want. We do share features and code with each other. Mastodon took our implementation of federated emoji, and we use their user interface.

“I think Mastodon tries to steer the network in a certain direction with strong, unchangeable defaults. We like to put more power into the hands of the individual admin and user.”

I think a big difference between the way Mastodon and Pleroma are developed is that I’m that set on a vision as they are. Usually, if something makes sense and is configurable, we will merge it.

This isn’t the case at all for Mastodon, where, for example, merge requests for a configurable character limit have been rejected many times, even though there’s a lot of demand for it. I think Mastodon tries to steer the network in a certain direction with strong, unchangeable defaults. We like to put more power into the hands of the individual admin and user.

One thing that stands out to me about Pleroma is the fact that the server backend is in Elixir, which sits atop Erlang. What made you decide to use that instead of, say, a certain Ruby-based framework?

When I started writing Pleroma I was already writing a social network in Ruby for my day job. Because of that, I knew a lot about the pain points of doing it with Ruby, mostly the bad performance for anything involving concurrency. I had written a Bittorrent DHT client in Elixir, so I knew that it would work well for this kind of software. I was also happy to work with functional programming again, which I like very much.
 
It worked very well for us. Pleroma only has two dependencies, Elixir and Postgresql, while Mastodon needs to use Redis/Sidekiq for job queues, ElasticSearch for search, a node js server for the streaming API, all because these things are hard to do in Ruby/Rails. I think using the right technology gives us an edge.
 
What else can I say? I think the fact that a fast Pleroma instance can be hosted on a $3 server speaks for itself. The whole Erlang ecosystem is perfect for a fediverse server. I guess if it’s good enough for telecom companies using it to handle millions of calls, it’s good enough for us to handle a few thousand funposts.

What has your experience been like in working with ActivityPub?

I wrote about this on my blog. Overall, I think it mostly reinvents OStatus in a somewhat unnecessary manner, replacing XML with the equally complicated JSON-LD. But I don’t really want to dwell on that. It’s here now, and we have to live with it.
 
One interesting aspect is that Pleroma was an ActivityPub (AP) server before Mastodon, but only used AP internally. Our database structure is based around AP activities, saved as json in the database. We only used OStatus to federate at first because there were no other AP servers around, and talking to yourself gets boring after a while. Because of Pleroma’s design, it was rather easy to add ActivityPub federation later on.
 
Using AP Activities as our internal data representation works well. It especially makes it easy to add new Activity types which can add new functionality. This is somewhat hard for servers that don’t implement this. Mastodon, for example, has an off-spec implementation of the whole ‘following’ flow, because they don’t save follow requests as activities internally.

What’s your overall impression of the ActivityPub applications currently being worked on? Is it hard to maintain compatibility between all these systems?

On one hand, it’s easy, because you just have to do whatever Mastodon does, as all systems will strive for compatibility with it.

On the other and, some parts can be rather hard to implement, though, because many properties of AP Activities can take several forms. For example, an “actor” might be just the user id, or a full user object, or a list of users, or a list of user objects… I wish AP was defined more strictly and not as ‘free-for-all’ as it is. This flexibility comes at a cost of hugely increased implementation complexity. Luckily, most servers don’t actually use that flexibility, so you can get away with implementing only parts of it.
 
Overall, I’d say that federation bugs happen a lot, but they are also quickly fixed, because they usually don’t involve big differences. They are very annoying, though.

A lot of former GNU Social instances seem to be steadily migrating onto Pleroma. What do you think of that?

My goal when I wrote Pleroma was to bring the fediverse towards a better technological foundation. If people want to switch because they think Pleroma will make life easier for them, I’m very happy about that. We are also working on GS to Pleroma migration tools, so people don’t have to register again or lose their posts. There are some requests from Mastodon admins that want to move to Pleroma, but it’s not a priority at the moment.

That all being said, I don’t really want to push people to migrate to Pleroma. If they are happy with what they have, they should stay where they are 🙂 We will support OStatus and AP as long as people use them, so there’s no rush to switch.

Let’s talk about the Gopher support in Pleroma for a moment. A lot of people initially thought it was a joke, but apparently it really does work?

Yes, it really does! It was a project for April Fool’s day, but gopher is such a simple protocol that I did really implement it. It works fine; you can look through the public and federated timelines with it, and it is absolutely the most efficient way to browse the fediverse (< 10ms response times!).

It is inactive by default, but I want to keep it around and enhance it a bit. Having a bit of fun in a social network never hurts. Install lynx and run “lynx pleroma.soykaf.com:9999” to check it out!

What developments are you working on right now? Are there any features in particular that you’re excited about?

The things on my mind right now (besides all the small fixes we need to reach 1.0) are groups, polls and chat. Groups and polls should be rather self-explanatory.

Chat is probably the most interesting of those. We already have a local-only chat box on Pleroma instances, but this new, enhanced chat, will federate over AP. My plans for it are to make it an IRC server that federates, so you’ll be able to use it with an IRC client or with our Pleroma chat interface.

This project was born out of frustration with Discord (good but non-free) and Matrix (free but non-good… for my use case) and it’s progressing well. I should have something out to test for people very soon.I hope that it can be an alternative to systems like Discord or Slack.

As people will be able to use it with their existing accounts, there’ll also be a good existing userbase to test it out. It’s an experiment, but I’m looking forward to it!

What’s the hardest part of doing all of this?

Two things: Finding the time to actually work on this. And seeing people think very negatively of you for reasons you don’t understand. This might just be part of the dynamics of these kinds of projects, but it’s the first time that this kind of thing happens to me, so it’s getting to me at bit.

What do you do for fun in your spare time, when you’re not developing Pleroma?

Usually playing with old technology. I installed Windows 95 recently and bought a few Laserdiscs. The future is here.

Is there anything else you’d like to share with the people reading this?

For everyone who helps me with Pleroma: Thank you so much! You’ve all helped me a a lot and I’m happy I can rely on you!

For everyone who is interested in Pleroma: Please try out Pleroma and see if you like it! If you do, maybe set up your own instance! It’s much easier than you probably think. I already found many new friends on the fediverse; I’d be very happy to make a few more!

Thanks for reading this interview with Lain from Pleroma! If you’d like to know more, check out these links:

• Lain’s Blog: https://blog.soykaf.com/post/
• Follow Lain on the fediverse: https://pleroma.soykaf.com/users/lain
• Pleroma Project site: https://pleroma.social/

 Share