Fork target

NOTE: this was originally going to be my personal approach on trying to talk about the topic of a fork target, whenever that came up in a meeting agenda. i am very, very tired, and it is still very much my writing. there are facts, purposefully worded to be accessible, and we can pick those out as an appraisal of tootsuite / pleroma as two different starting points.

mastodon is not accessible

Here is the problem. Mastodon is not an accessible codebase.

i want to clarify that, and i’m going to do so, very carefully. an analogy for you: mastodon is a cake. a cake has layers. that’s fine. there is nothing wrong with having layers, after all. let’s compare the layers that make up the codebase of mastodon, with the codebase of pleroma. this is purely an example, rustodon is also an option, but i haven’t tried to code in that yet, so i cannot speak for it. also, putting it bluntly, pleroma runs and i have used it instead of mastodon, and i had very little to no issue as a user, so it is an option. rustodon is currently backend that doesnt yet connect with a frontend. it’s not got a running proof of concept.

mastodon is running Ruby backend on top of PostgreSQL. this is pretty standard, and pleroma is also running PostgreSQL, so we can ignore that bit. we can also ignore the web server itself that is serving up this data to the users. these are always necessary, and the SQL server in question is just a good standard open source server that follows the Specification of SQL, a very popular database server. this and the server that spits out the data packets of code and HTML that constructs the websites can both be removed from our equation. so mastodon runs on ruby, and pleroma runs on elixir, for the backend side of things.

and here comes that ‘but’ you may have been expecting: this isn’t the end of the story. both are running javascript and Node, a popular Javascript library. as far as i know, mastodon is at the very least using Node to compress the packets of code, and serve them up to the user. pleroma does the same. as i am not an expert, i cannot tell you just how intertwined node is with mastodon. these are not my languages of expertise. i’ll touch on my experience later.

Ruby on Rails (one of the code languages used for Mastodon) lacks common tutorials, structures, and conventions.

so right now i only have a ‘might’ for mastodon having more layers, and that’s where things get tricky. i know for a fact, from personal conversation with gargron, that the ruby in question is called Ruby on Rails, a specific set of architecture designed for web development. it uses a set of standards, patterns, and logical paradigms to define a method of development that many users of it choose to think means that comments are _less necessary_. i have a lot of problems with this, so i’m going to break them apart. i am an outsider to ruby as a language. that is fine. languages are largely syntax, and i have experience in many languages, even if they share syntactic similarities, i can work around those, and can generally work in any language i read up enough on. the problem is this, if you noticed, i spat a bunch of buzzwords, from the wikipedia page for ruby on rails. these are, cutting away the bullshit, simply a bunch of soft-rules, rules that can be broken, but people will frown at you for doing so, that supposedly mean we don’t need to explain what the hell we’re doing in comments, according to some users of that set of rules. i disagree with this, strongly, and i know for a fact at least a few tech-bros work on gargron’s codebase that said this, in a manner that i heard it. i don’t remember who. i’m not here to fucking shame. i’m here to make social media. i don’t know how to say it kindly, but i am not here for any of that .

There is another code base added on to Ruby on Rails which requires translation, and has around 90 libraries to research.

now, i will drop my proverbial bomb and say that mastodon is also running an absurd amount of includes in its gem-file, or ruby’s fancy way of saying ‘this is where i say what other code i will be using that isn’t in my codebase’. i know for a fact that (at least when i first attempted to get involved with this, nearly a year ago) Gargron built Mastodon with another fucking layer, for the frontend and UI. i don’t know if it’s javascript, if it’s in the backend that serves up that javascript, in ruby, or where the fuck the layer even is, but i know for a fact i cannot explain it to you in simple terms, like i can this sort of thing. it’s some sort of silly design over code approach, and i know that i am being dismissive, but honestly, it doesnt matter that the idea is to take raw data states and make those data states determine how the UI looks. that’s a bunch of magic words to make an arbitrary set of rules that the code operates under that is simply NOT LISTED ANYWHERE on the codebase. this set of rules is apparently fine to be left out, despite it being integral to the most essential goal of software: to put data on the screen, and display it to the user. now i won’t say that it’s still there, because you know, you’re right. i can’t find it anywhere, and it might have been removed. but if it is a thing that mastodon was built with that long ago, and was involved in development for long enough to have kept me out of it, then the majority of mastodon’s most active time in rapid changing was affected by this set of rules. if it was removed, it’s just as bad as it not being listed anywhere, because that still probably had a huge effect on the design of it all and it’s not even listed for the sake of history. i won’t drag y’all through this for proof from head to toe, but here’s a glance at the development guide.

Pleroma is built on a much more accessible codebase, with less overhead

so we’ll give gargron the benefit of the doubt, and say it’s still there. i want to find out where it is, so i can wade through all these layers of mud. i spent my tens of hours on mastodon’s ruby on rails rules, and now i gotta learn the rules of this design thing i keep mentioning but don’t know the name of. well, ruby uses ‘gems’ to include as the different bits of code you don’t make, and want to use to fill in some holes in your code. here’s the gemfile, which includes all of this code. i encourage you to open it and try to figure out what we’re looking for. my first glance, i didn’t even realize that the testing was being imported here, too, and a separate set of code for the development environment that likely doesn’t go into a production server. that’s all confusing but presumably, when you GET THERE, it works. but there’s still a screen and a half of includes above that, on my screen (which mind you is very big, and my text is pretty small, i am very lucky with my sight, personally). and i have no clue which set of code i need to google. i can make some guesses, but again, it’s not mentioned anywhere. if it’s removed i need to go ask gargron himself, most likely, to show me what rules i might need to know to get involved with his project

ok, i’ve been harping on this a lot. maybe this isn’t that normal. maybe this is par for the course. maybe you’re not a web-dev either. i’ll go ahead and list my code experience now, so you can see that i am coming at this from a developer standpoint. this is legitimately scary as a codebase. i have 10+ years, anywhere up to 14 if we’re being generous, started in Visual Basic 6 (before studio happened!), followed by Java (have a certification!), C++ (i made a 3D game engine, as well as 1 lost to time in java!) , and now C# and unity (I made & SOLD a game for over 100$ of personal gain!)

Pleroma follows conventions set forth by the W3 for it's structure.

so i know what mastodon's codebase looks like. now let’s look at pleroma. pleroma is running postgreSQL like we said before, just like mastodon does, and it serves up javascript as a frontend, using node.js to minify the packages sent over the internet to be very small. everything looks the same here. are there any weird rules to follow? well let’s look at mix.exs. i want to clarify here, i do not know the language involved, and i am looking at purely the include lines: 33 to 50. that’s so small, it’s half of a screen’s width of stuff. even better, i can read what most of them do, and parse it, thanks to what little the code told me before i got here. Pheonix is a framework that’s running the webserver, so we can ignore those lines. postgrex is again, postgreSQL. so we can ditch five lines of includes and get from 17 total includes down to 12. one of those is a calendar library, another looks like some other standard libraries for elixir, but that might be wrong. we have 10 includes on the background framework. this, i can do. ten links i can google, probably 5 of them are small things, heck one is called ‘gettext’. i can probably pore over this code, learn the language, and make my first change to the codebase in under a day, even on a BAD DAY for me, if i put all of my spoons into it. similarly, javascript is, as far as i can tell, just running base javascript, and i was reassured it runs node.js purely for making data transfer of javascript code smaller to get it sent to the client over the internet. that is not affecting the actual actions of putting things on the screen. on the flipside, mastodon has just shy of 90.

Pleroma has ~10 libraries to research.

i think i’ve probably made my most important point (accessibility problems with tootsuite), but i want to list off some more points before we close this topic for now. i know i’ve probably been a bit wordy, but it’s very important that everyone understands what i mean, and can believe me, when i say that mastodon is running a much less accessible codebase than pleroma. i even got a handy link by someone who made it more accessible for me to learn the intricacies of elixir since well, it is a niche language. that’s here if you want it.,%20Phoenix%20and%20a%20bit%20of%20ActivityPub

now, let’s talk about improving pleroma: pleroma is running a database that mirrors another specification we have going for us that mastodon didn’t: activitypub. for those who don’t know, activitypub is a specification for designing federated social media. this is by W3, the literal maintainers of the working group for CSS and HTML (now called HTML Media Extensions). this design choice is ingrained into the database itself, which means we aren’t working with a database layout designed by ruby on rails or gargron, but instead, designed from the ground up FOR THE COMMUNICATION PROTOCOL ITSELF. and even better, it has room for us to take this information and create new features. you might say that yes, pleroma does not have masto’s implementation of lists. well, in activitypub, we can implement an inbox that would represent this list’s inward stream of content. similarly, an outbox exists, that could be used to properly implement channels-- but we’re off topic.

Pleroma will have an easier starting point for new coders with less technical debt to clean

what i’m trying to say here is that this spec has room for us to iterate on it, and still follow the model it puts forward. we can make this database that is not limited by whatever rules gargron built it under before we had a set of rules, and make it more. we can make mastodon into whatever we deem most accessible and user friendly. if we start with masto, to some extent, we are locked in to what we have.

so what if we want mastodon? well, pleroma has an existing, working version of the mastodon frontend already there, built using upstream masto code. we can iterate on it. it currently lacks its own settings menu in that frontend. we can build that. it has some basic settings menus we could expand-- well, this is off the topic. what i’m trying to say is, we can work with this. it has room for us to copy and paste code wholesale over, for many things, from masto upstream, and glitchsoc, as well(which someone is trying to port already)

i think you may have already heard that pleroma runs on a raspberry pi. that shows that the codebase is light, and we’re not dealing with masto’s bulky rails overhead, but that isn’t always good, and i want to admit that openly. we may have to reinvent some wheels, but honestly, we have mastodon upstream to look at, and ultimately, we can reinvent those features, and build them on top of existing UI stripped straight from tootsuite. the fact that pleroma runs on a raspberry pi just means we have an accessible starting point for everyone. if we’re lucky, and patient, we can probably keep it running on a pi. i could self host, in theory, once i get down in this codebase. i couldn’t with masto.

personal note.

what i’m trying to say is that pleroma has an accessible starting point that is nearly identical to what we already have, for the average user. i personally used it with little issue. i have friends from mastodon on it, happily. we can add back in features that are missing. a lot of the code was straight up ported over from mastodon, stripping out the ruby backend i can’t deal with at all. if we have people willing to work with the masto code, we can do that, and get back all the features we’re missing on pleroma’s backend. this can be a long haul, if we’re unlucky, and that work is hard. but people have already been doing that in pleroma, and if we say ‘hey, we are aiming to be accessible’ then maybe they’ll come to us, instead of pleroma itself.

we can replace gargron, and ultimately, we’re just swapping out gargron for some other people you don’t trust. we’re all here because gargron wasn’t good enough. i can work with this code. can you?

all of these words are arbitrary, you might say, and that’s fair. i don’t have the spoons to learn all of the databases, all of the backend and frontend to tell you which is truly better. but i have had anecdotal evidence from 3-4 people saying mastodon is inaccessible, and another 3-4 saying they could in fact, personally, sit down and make code happen in pleroma.

pleroma is not without flaws, but considering i am an extra name on both of those lists, that’s a solid win for pleroma, for me, as a user-level dev willing to contribute code. i know we will have to patch it up, but it’s a wounded gazelle, to me, and not a robot speaking greek and expecting me to find my way around that set of rules without any help, and i can work with that. that’s all i have to say, but i will answer questions if they are asked. i relinquish my role as speaker.

before the above draft, i had this:

FAQ on pleroma

Why pleroma has value as a consideration in comparison to mastodon

  • Pleroma is more efficient in terms of cost to upkeep, and can offer multiple frontends/UIs to the same efficient backend, including an instance of a basic mastodon frontend, that we can extend to keep up to date with mastodon’s frontend
  • Pleroma is already working, running, and proven by doing so
  • Mastodon’s maintainer doesn’t let people merge code unless he oks it, pleroma is more open (multiple people with merge rights, i think at least two, maybe 3) and thus we can get more support upstream(IRC channel i got some of these answers from), and pull more features from upstream into the fork
  • Pleroma supports multiple API endpoints, so more app variety in choices for users
  • a quote from a user who uses pleroma; “because pleroma worked and mastodon killed my disk bandwidth when i tried to run it.”
  • Truly generic Activity Pub implementation, can run many things, not just mastodon style microblogging for an example, kaniini has a frontend that emulates facebook walls

What differs between the two in terms of programming languages

  • Pleroma backend runs on elixir
  • Pleroma frontend runs on VUE js / Node to minify the JScript
  • Elixir apparently surprisingly accessible to learn (from a dev who works on elixir/pleroma on the IRC)

Upstream, what differs between the two choices

  • Pleroma has channers on it, but also has a userbase that is not channers that might not behave in bad faith
  • Pleroma has maintainer willing to accept merges, gargron already has proven hostile, while pleroma has not
  • Pleroma is smaller, and newer, and thus easier to get your feet wet with, while also providing a front-end nearly identical user-experience wise.

What might make this more difficult than forking mastodon?

  • Mastodon has more userbase, so less instances will need to be moved to pleroma. Userbase being moved to pleroma is not currently ready-to-go, scriptwise, so users will lose data if effort is not made in that regard (scripts are already partially made for instance conversion to be possible w/o losing data)
  • Not on github, technically, but still git (lab)

Pleroma security concerns

  • running on a slightly different idealogy of home timeline. we can code this out, and make an option for users to opt out of appearing this way on pleroma instances we do not control
  • Does pleroma allow users to see restricted posts from mastodon users? If it can, how do we fix it?
  • As Secure As Mastodon according to irc, spec is the source of security concerns, not software
  • Pleroma does not filter file uploads, but mastodon’s filter can be bypassed