Should Mastodon remain compatible with GNU Social?

[noelle]

My opinion, and I speak only for myself and not for anyone else on the Mastodon team:

worrying about how GNU Social will handle changes to the Mastodon codebase is a recipe for the Mastodon codebase never changing. I don't know what the guiding principle is; are we assuming that all code should degrade nicely into GNU Social instances?

That is to say: should Mastodon be a strict superset of GNU Social?

I don't think it should. I believe it's a fundamental error to say that any codebase spawned from a GNU codebase should forever remain compatible with the source; perhaps that's not in keeping with the GNU license but it's absolutely in keeping with the principle of free and open-source software.

So I'll potentially go out on a limb: as free software we must include freedom from the source. Mastodon should be able to incorporate features that are not only not implemented by GNU Social but that are incompatible with it. And possibly that starts with an expansion of the content-warning code as indicated in the source thread.

[Naouak]

Personally, my instance interacts a lot with gnu social instances so I need the compatibility with it.

[Irick]

My social graph also includes GNU social instances.
Breaking compatibility would be a strong anti-feature considering that the userbase has grown with being able to talk to people on Ostaus compliant instances.

[hoodie]

while i do not encourage purposefully/for no reason breaking backwards compatibility, i dont think it is our fault if things do not federate backwards 100% properly.

if they actually wish to interact peacefully/compatibly with us, they should implement such vital features that, as far as i know, have gone unimplemented, such as respect for private posts and the like. if they want to remain compatible with us, it is just as much on them as it is on us, and we can only go so far without leaving them behind.

i do agree that we cannot say just because a feature does not work backwards 100% perfectly, that it should not be implemented, as then we will grow stagnant, and that is the opposite of good for the software.

[butternuts]

I won't cast a vote, as it were, one way or the other, because, quite honestly, Mastodon is my first foray into decentralized territory and I wasn't aware of GNU Social before using Mastodon.

That said, I've been in open source communities for many years, mostly CMS and forum communities, and I have seen many times when the project gets to a point like this where it must decide: refactor the core to move ahead in new/innovating ways, or forever carry the yoke to support backwards compatibility, and risk becoming obsolete over time as a result.

In every case, the project wisely decided to move forward with changing times and the world didn't blow up (yet). Though there was often an effort to run two branches simultaneously for a short while to allow laggards to figure out their lives. (I guess that sounds kind of biased, but I'm still not voting.)

One thing I do notice in Mastodon streams sometimes are toots that are way over the 500 character limit, and I see others puzzled by this a lot too, understandably. I'm guessing this is because some instance customize the limit, or because it's GNU Social and the limit is different there? I don't know. But what I do know is that those kinds of inconsistencies confuse the average citizen user when the see them. They think they're not getting the same feature set or don't know how to use the tool correctly, or whatever. Point being, maybe one factor in the compatibility considerations is ensuring that when in context of Mastodon, the content scope is consistent.

[jeroenpraat]

Of course it should stay compatible.

Incompatible features can be hidden or get a warning like 'This feature is incompatible with your network.'.

[shel]

I think that this question is based on some assumptions which constrain the nature of the question.

Mastodon runs on the OStatus Protocol in order to federate. The following software supports the OStatus protocol either as its core protocol or as an optional extension:

1. Mastodon
2. postActiv
3. Friendica
4. Hubzilla
5. GNU/Social
6. Pleroma

Each of these has features which are unique to it, or are not entirely supported by all of them. Pleroma is an entirely new implementation of the OStatus Protocol that popped up recently.

A part of being decentralized and open is also having open protocols. If I don't like Mastodon at all, I should be able to break off and make new software and still be able to interface with Mastodon. Otherwise you end up with something like Diaspora*, a decentralized, yet effectively closed, system.

Unless we are going to make Mastodon into a closed semi-centralized system, which I oppose, then all design decisions must consider what will happen if it interacts with an instance that doesn't support that feature.

Given that Mastodon is open-source, there may always be forks which would have differing levels of cross-compatibility. You have to consider that. I could easily fork Mastodon and make a Nega-Mastodon which appears to be vanilla but doesn't respect post privacy.

Additionally, because Mastodon is a distributed system, you have to consider that, for instance, there are tons of computers still running Windows XP. There are Mastodon instances that may be running older versions, which do not include support for a new feature.

Backwards-compatibility i just an important design consideration. Regardless of if, for instance, you have a handful of friends who are on non-Mastodon instances.

Presently, there is work being done to implement support for another protocol, ActivityPub, which seeks to remedy some of the issues with OStatus that makes things like "post leakage" and "wild posts" such a concern. Pleroma and postActiv are also, last I checked, planning on implementing ActivityPub.

Because email is such a great analogy, we can return to email.

Microsoft Outlook is an email client which has a lot of features that are not supported by other email clients. I find it very useful to be able to assign people tasks or invite them to calendar events. But not everyone can interact with these features, including people running different versions of Outlook from me. This is not a reason for Outlook to break away from using the email protocol, it's just something I have to consider when I email someone if they're not using Outlook. If Outlook became a proprietary protocol, it would become much less useful.

In terms of prioritizing cross-compatibility, it's presently clearly not a priority, and has rarely been. Trying to remain cross-compatible has the benefit of being a "good neighbor,' which will make other people like you more. It also allows you to interact with more people and expands the fediverse to be a more useful world. It's also important to consider how a cross-compatibility error can have undesired consequences. For instance, a GNU/Social instance has not idea that an instance runs Mastodon when it connects. If Mastodon throws tons of errors in their logs, that's really obnoxious and makes life difficult for the admin of that instance. It's just a nice thing to do to try and fix that if possible. You also have cases like #nsfw and conversation_id.

With the #nsfw issue, we had had two competing systems for hiding NSFW content, resulting in GNU/Social and Mastodon instances sending porn and gore back and forth unwittingly without any marking or hiding. This is undesirable for all parties, so of course we added support for #nsfw.

With conversation_id, there was an issue where, if a Mastodon user joins a conversation with GNU/Social users in it, that conversation thread would break, and it would become difficult to maintain a conversation as you couldn't see what any posts were replying to. This made it very difficult to have a coherent conversation and resulted in a lot of conflicts arising from very confusing conversations. As one user had said to me, "Every reply to a Mastodon user is like a quest." Mastodon users had no clue from their end this was happening, and can't see necessarily that a conversation they're joining involves GNU/Social users, so they would hop in and break their conversation, and even if they left one comment and left, it would make following that conversation a whole ordeal for everyone else. Fixing this issue (once v1.4 comes out) will ease tensions because people can actually talk to each other.

So, of course we should implement features we need and find useful regardless of if other implementations of our protocols support it. But we need to consider cross-compatibility and not intentionally break it. Even if we decide to give up on OStatus (despite it being the backbone of the software) this is still a problem we would have.

Anyway yeah we should stay compatible with GNU Social imo

[wolfteeth]

I think the compatibility with multiple types of software is part of Mastodon's selling point. If there are existing protocols being used by GNU Social or other compatible software to implement features that aren't defined by OStatus, we should try to follow the leader on those instead of rolling our own, unless we have a very good reason not to. On the flip side, I strongly agree with @shel's comments on compatibility. Any new feature that's not part of a standard protocol needs to play nicely with instances that haven't implemented it - whether it's older versions of Mastodon, PostActiv, GNU Social, etc. Ideally it would translate the feature in a useful way for those who don't support it, or in some cases, perhaps refuse to send posts with extra features to instances that don't support them (for example, posts with restricted privacy).

We shouldn't let it stop us from moving forward, but we can grow our feature set gracefully. OStatus seems like a pretty bare bones feature set for a social network - continuing to support it as a minimum makes sense.

[butternuts]

A lot of insights there. I learned much. Thank you.

[saper]

we should work hard together on the protocol. It is important to have a single protocol (maybe with extensions) running and encouraging multiple implementations.