Note 1 : This post was published December 10, 2015, and is still often accessed. I’d like to inform readers that since then, with the exception of # 3.8. (inserted Juli 2016), I didn’t update the article. Neither have I been much around on GNU Social since its publication and therefore don’t know how many of the problems mentioned below have been fixed in the meantime. I’d label this article “outdated”, it’s kept for archival reasons.
Note 2 : People in search of a readable user- and admin manual for GNU Social should have a look into the very good The Unofficial GNU Social documentation. It has the beginner in mind, contains a lot of screenshots, and is available in English and Spanish. (May 29, 2017)
If you ponder whether to leave Twitter and join GNU Social, you best should know in advance some of the problems and pitfalls that await you. For most newcomers to GNU Social, things are not easy, and I would rather warn people to leave or delete their Twitter accounts and move to a GNU Social instance. One needs to learn quite a lot to get the basics done here, and it is rather a matter of taste if that is worth the effort. Communicating on Twitter is much easier than on GNU Social; and if a newcomer isn’t interested in geek stuff, in tinkering, and learning, then GNU Social may not be the right choice. (On the other hand, the people on GNU Social are usually very gentle and helpful, so asking people is the right way to start and get used to the ways GNU Social works.)
In the past there have been several waves of people coming from Twitter to GNU Social (esp. Quitter), and most of them returned to Twitter after a short while. Why didn’t they stay, if GNU Social and its instances are that promising? I find technical constraints and usability to be two of the major reasons.
In order to point out (and explain) some of the usability issues, some info on the technicalities are necessary. I try to sketch them as succinctly as possible.
GNU Social is a free software allowing to set up microblogging instances that can interact with each other due to the same software (GNU Social) and transmission protocol (OStatus) (pretty much like independent email providers can interchange messages with each other). There are large instances and smaller ones, some are self-hosted and used only by their sole user/admin to connect to other instances. The total of all connected instances using the software and protocol is often called the “Fediverse”, a noun derived from the word “federation” which describes the way how the instances communicate with each other.
The problems using GNU Social are less obvious if a newcomer joins an instance with a large number of accounts (and followings to other instances, see below) but more so if s/he joins a smaller instance. The reason for that is how “federation” is constructed in the first place.
Roughly, federation is designed like this:
Instances communicate with each other via the relation of users following other users. Some user b from an instance B is “visible” to a user a in instance A only, if there is someone on instance A following user b from B – either user a herself or somebody else who has an account on the instance A. To be “visible” in A thus means: notes from b of B are copied into the database of instance A only if someone from A follows b on B.
On large instances, people may interact with many people who already have an account on this instance. As their posts are already in the database of that instance, they are available to all other folks on that instance. Those people can thus be followed easily, their posts easily replied to, favourited and repeated.
Another characteristic of large instances is that many people will happen to also follow people on other instances, so the amount of posts and people (or: accounts) of the fediverse that this particular instance can “see” is rather huge. But on a small instance with only few accounts, chances are that this instance will not “see” much of the fediverse, as its few accounts will not follow enough accounts on other instances.
From this characteristic of the federation stem many of the problems and difficulties newcomers face, and for which only a few workarounds are available.
1. Following other accounts
This is pretty straightforward for accounts that reside on the same instance as yours, but a bit tricky for accounts that dwell on “distant” instances. One usually has to visit the instance where the other person has her account, ask there to follow that account and confirm that request on one’s own home instance again.
2. Reading posts
On large instances this is rather easy. As many accounts reside on this instance and many accounts of the fediverse are “seen” by this instance, the posts of many people, from this instance or other, are presented in the Public Timeline or that of the known network (i.e., the federation as seen by this instance). (Note that only Quitter provides the flow of all posts seen by Quitter as a distinct timeline, other instances either don’t show it at all or show it only indirectly). But that means that you read different notes (esp. notes from conversations, see below) on different instances. (Workaround: To see the Public Timeline of any instance, manually add “/main/public” to its address in the address bar of your browser, e.g., instance.com/main/public. To see what segment of the whole Fediverse this instance “sees”, add “/main/all” to its address, e.g., instance.com/main/all.)
3. Interacting with posts
If you come from Twitter, chances are that you are well-versed in replying, favouring, retweeting, blocking, muting. And this is really very simple because Twitter is one self-contained instance that keeps all posts “inside”, not interacting with other instances. So every post is “visible” to everybody, as it is already in the same database. But on a GNU Social instance things get rough due to federation and the copying of sent posts into the databases of the individual instances.
You can reply to, favour, and repeat all posts from accounts that are on the same instance as yours. If the account is on another instance and you follow that person, you can likewise reply to, favour, and repeat the post, because your following makes the other account “visible” in your home instance. Likewise, if you don’t follow a person from a different instance but her posts are already “visible” in your instance, you can reply to, favour, and repeat it.
If you don’t follow a person from another instance and her account is also not known on your instance (i.e., nobody of your instance follows that person), then you won’t see her post on your instance but either on hers or, more probable, on a different instance where you happened to stumble upon it while reading around. But reading it on her instance or on the other instance doesn’t make that post available to your instance nor does it provide you with a permission to write on those instances; you will therefore not be able to reply to, favour, and repeat the other person’s post. (Usually rephrasing that other person’s post in your own post and publishing it on your instance serves as workaround.) This is a major confusing and annoying thing for newcomers: one finds an interesting post, tries to interact, and isn’t able to.
Likewise just writing a post to someone on a different instance doesn’t work. You’ll need to use a special version of the other person’s account address, and that may be confusing too.
Whereas Twitter is more like a broadcasting medium by which individuals send “announcements” to their followers, GNU Social is more a medium of conversations. That is: The interaction in the Fediverse is far more conversation-based than on Twitter. And with that the problems of federation play out. Usually, larger conversations happen between people from different instances. There are statements, replies, counter-replies, favourings, repeats, all in one thread of conversation. But if one participant b in that conversation is not known on the instance A from which another user a participates in that conversation, then the posts of the participant b (of B) will not show up in the conversation as presented in the timeline of the instance A. That is, person a will miss some posts (statements, replies, favourings, repeats) in the conversation. On a large instance this will mostly not be a big problem, as chances are that most people from other instances are already “visible” in that instance. But if an account is not “visible” on a smaller instance, then larger gaps in the conversation will be the result. A person from that instance will then have to look up the root post of the conversation on its original instance as well as the instances of all participants to make sure not to miss a contribution to that conversation. And if that missing post is on some distant tiny instance, chances are that the person interested in that conversation will not be able to reply or otherwise interact with that “missing” post. (I am leaving aside the glitch that sometimes posts of a conversation simply don’t get federated across several instances at all.) (Partial workaround #1: One can reduce the numbers of instances to visit in order to find possibly missing posts of the conversation by visiting the Home Timelines of some of its participants. In the address bar of your browser add “/all” to the address of any user on any instance, e.g., instance.com/username/all, and you’re shown the user’s Home Timeline with all the posts and replies. Partial workaround #2: @firstname.lastname@example.org has written a “GNU social Conversation Assembler“-tool that “assemble[s] complete GNU social conversation trees from the URL of a single notice in the conversation” so that one is “able to read the conversation without hopping from node to node”. Main issues right now are, first, that in the resulting tree one cannot reply to an individual post; and second, that for technical reasons (“cache requests”) a conversation cannot be updated once it is viewed. But to collect all posts of a conversation of the past, this should suffice. Thank you @laemeur for this labour of love.)
On Twitter to block a person makes her disappear from your timeline and your subscription lists. On GNU Social things are more complicated due to the interplay of different independent instances. First of all, with the sole exception of Quitter.se, blocking someone does not make that person’s posts disappear from your timelines. The only thing it does is stopping that person to follow you and send you a post or a reply. But you will still see her posts on the Public Timeline or receive them in your Home Timeline if they are repeated or replied to by someone you happen to follow. Revoking the block is easy if you both are on the same instance, as the revoke-message is delivered to the same database. Blocking people on different instances though is problematic. For one, you will keep seeing their posts in the Public Timeline or when they are repeated or replied to by someone you happen to follow. But second, you cannot revoke such a “remote”-block by yourself. Although the block-message is sent to the database of the other instance, the revoke-message is not. (There are technical reasons for that.) You will have to ask the admin of that instance to manually revoke your block. So with regard to people on other instances, a block is a permanent matter. It only achieves that the person cannot contact you, but you will still be bothered by her posts about which you can do nothing. (This is obviously problematic in all cases of spam, harassment and stalking.)
As federation consists of followings and the copying of messages from one instance’s database to another, one would expect favouring and repeating to be copied across instances as well. Unfortunately, this is only partially so. Given several instances, if a person b (on B) that I (on A) follow repeats or favours a post of person c (on B or C), then it shows in my Home Timeline as another favour or repeat but not in the Public Timeline of my instance. The post by c will gather numbers of favours and repeats on its home instance and “abroad”, but not “combined”.
There is no direct way to repeat a post from a different (but “seen”) instance into the Public Timeline of one’s own instance. The easiest way around that obstacle is to reply to it. This “conversation” brings the post from your Home Timeline into the Public Timeline of your own instance.
Deleting a message on Twitter makes it unattainable for authors, recipients, and Twitter’s public timeline. Even via search it can no longer be found. On GNU Social, due to federation, this is not so. Although it will vanish from the instance’s database in which it was originally published, due to federation it has already been copied to other instances’ databases. Thus the deletion of the message from user a in A will not remove it from instance B to which it was copied via b‘s subscription of a, and so it will stay in all the conversations on B in which it started to become a part. Here it can still be replied to, favoured, repeated. And when user aa from A replies to the message in B or to user b‘s reply to it, a‘s original message from A will return to A‘s database. First into A‘s “view” of the federation, that is, A/main/all. Then, when someone on A replies to it, into A‘s Public Timeline, that is, A/main/public. So even as one can delete one’s messages on one’s home instance, that makes it disappear only on that particular instance; it remains accessible throughout the whole Fediverse and can return to the instance of its original publication any time again. In short: There is no deletion of messages in the Fediverse; and everything survives somewhere.
On GNU Social the Direct Messages are confined to members of the same instance. That is: One cannot send a Direct Messages across instances. (Private Groups, somewhat like DMs for/to several people, are restricted to members of the same instance as well.)
4. Centralization of a different kind
That posts of a conversation between accounts of different instances can be “missing” is a major annoyance. (But there are voices that see this as something very positive, e.g., here.) Another is that due to this problem larger instances are more attractive to sign up to than smaller ones. The result is a similar effect of centralization that the advocates of Open and Free Software usually condemn in “walled gardens” like Twitter or Facebook. Federation as it is designed right now favours instances that already dominate the Fediverse. Self-hosting or tiny instances have to grapple to be “seen” and to “see” by subscribing to many other accounts.
5. Unclear interplay of publishing licenses
Publishing a post occurs under the publishing license of your home instance. On Twitter, you keep your copyright but grant Twitter the “worldwide, non-exclusive, royalty-free license” to publish it in its original or derivative form. On the Fediverse things are more complicated. Many instances differ in their licenses with which posts and content are published. Quitter.se, e.g., uses Attribution-NonCommercial 4.0 International (CC BY-NC 4.0), whereas, e.g., Micro.Fragdev.com uses the slightly different license Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) and GNUsocial.de uses a Attribution 3.0 Unported (CC BY 3.0). The first forbids any commercial re-use of the content by a third party, the latter two apparently not. Now, which license applies when I publish a post on, say, Quitter, and it is re-published (“copied”) on, say, Micro.Fragdev, or on GNUsocial.de, due to people following me? The question of possibly conflicting licenses hasn’t yet been addressed by the people active in the Fediverse.
6. Who owns the data, and, really, who cares?
There is the opinion that people don’t “own their data” on “centralized” services like Twitter or Facebook, but would do so on the Free and Open instances of the Fediverse. I am not that sure about this claim. Of course, if we’re talking about mere usage data, not the created content and the copyright applying to it, then Twitter will indeed not hand over to you the data it collects about you. But how sure can you be that the admin of the GNU Social instance where you have your account would do so? He might point to the license under which all data (like the content) is “published”. What does it then even mean that you “own” your “own data” when they are all under an open license and you have no access to the instance’s server and database? In the end, the only way to “control your own data” in a meaningful sense in the Fediverse (ignoring the question of possible conflict between different licenses, see above) is to self-host an instance. But that requires a lot of technical expertise many people will surely not want to spend time to acquire to become proficient in. So even on GNU Social the “right to own your data” comes either as a vague promise or at the high price of much learning. Of course, if you like to learn programming languages and technical stuff, then this will be all fine and liberating. But for those who don’t, the claim that one “owns the data” comes as theoretical and detached as the intricacies of the Federation, with no real bearings on reality.
Given these points, the main question for any newcomer pretty quickly becomes: Is it worth to join GNU Social? One has to learn quite a lot before one can enjoy the advantages of GNU Social’s technological structure as well as of the community of people. The communication is more direct, more vivid, at times more boorish and often more gentle than on Twitter. But the number of participants / active accounts is limited, the range of topics small. Because of that a newcomer may find Twitter more interesting and way easier to use. Especially when the new user doesn’t share (or care about) the political stance of Free and Open Software, there doesn’t seem to be a point in joining GNU Social and the Fediverse. People have the freedom not to care about freedom; and if freedom is the only figurehead of the Fediverse, then only the already converted will join the choir. Which will be the main reason why the Fediverse is this sparsely populated pocket universe, and why geek stuff still is the main topic of its conversations.
* * *