vaguerant

A lot of us are pretty new to the fediverse and we've arrived just in time to grapple with what is easily the biggest federation/defederation controversy ever to hit it. I've put this thread together to hopefully help communicate some of the more complex ideas that we're trying to get our heads around.

What does federation do?

On a basic level, federation is offering an agreement and ability to share your content with other services. Being part of the fediverse means that the content from your instance (e.g. mastodon.social, lemmy.world, kbin.social) can be requested by anybody else. It's a system of requests and responses, where you freely hand over your content to other services who ask for it. When there's a bunch of services doing the same thing, you can request the content from their servers, too.

For a weird interpersonal analogy, it's like your group of friends show up to a street party in-progress carrying a big thing of candy beans and you announce to the party, "We brought candy beans for everybody!" You place them down on the table with all the other snacks, and grab yourself a tasty assortment of the things everybody else brought. You don't eat everything; that sketchy dude over at the side brought a fondue pot and it looks kind of gross. In turn, some people come over and eat your candy beans and some people don't. Even more people will arrive to the party after you, and even though you technically didn't offer them your candy beans, they can have some too because they're for the party. Importantly, nobody is force-fed anybody else's snacks.

In this analogy, the party is the entire fediverse. The friend groups at the party are instances, and the snacks are all the posts, comments and other share-able interactions.

What does defederation do?

Defederating another server means your instance will stop requesting content from that server. For a real-world example, several instances have defederated exploding-heads.com, meaning that they have stopped asking that instance to share its content with them. Those other instances still request content from most other parts of the "threadiverse" (which is, let's just say it, the Reddit-like segment of the fediverse), but they no longer ask for or receive exploding-heads.com content, whether that's posts, comments, upvotes or anything else. That's defederation.

Let's go back to the party analogy. Remember that gross fondue pot? Your friend group gets in a huddle and you all agree: you don't want anything to do with that fondue. You all have a great night at the party, trying all kinds of tasty and interesting foods, some of which you've never had before but none of which are fondue. It doesn't take long before you forget the fondue is even there. Nobody even tries to offer you any. At worst, somebody asks what you think of the fondue and you tell them you're avoiding it because you don't like the way it's furtively bubbling away in the shadows.

The dude who brought the fondue is an instance that you've defederated from, and the fondue is his content which you find objectionable. Maybe it's racist, transphobic fondue. Your group of friends (instance) decided not to see, respond to, think about or otherwise deal with that content.

What doesn't defederation do?

Defederation is about what data comes in, not what goes out. Your instance is still part of the fediverse, so if somebody comes asking for your instance's content, it gets handed over as normal. This is true even if the request comes from a server your instance has defederated. Defederation doesn't make you invisible, it doesn't block anybody else from seeing you, it doesn't protect your content, it only means you never have to see their content.

Let's head back to the party. Here's the crazy part: that weird fondue guy is allowed to eat your candy beans even though you're not eating his fondue. This is just how parties work. When you bring something for the party, it's for everybody who showed up, whether they're you're friends, your friends' friends, total strangers, or some creepazoid who everybody seems to be avoiding. As soon as you start guarding the table going "Not you! You get the f— away from my f—ing candy beans!", it's not a party any more. Don't do that.

As an open protocol, the fediverse is a street party. Anybody might turn up (start an instance), including people who bring fondue (people or groups you find objectionable). You can choose not to eat the fondue (defederate them), but they will still be able to eat your candy beans (request your content). This is just how street parties and the fediverse operate. You get to decide what you eat, but not what anybody else eats.

How will Threads joining the Fediverse affect the threadiverse?

Up to this point, I've mostly been talking about the fediverse as a whole, but on Lemmy and, to a lesser extent, /kbin, our primary concern is with the threadiverse: the part of the fediverse which revolves around discrete communities made up of discussion threads. Microblogging (like Twitter, Mastodon and Threads) as a type of personalized short-form content is not the primary focus of /kbin, and not part of Lemmy at all.

Threads is entering a space in the fediverse which is dominated by Mastodon, so it's Mastodon and other fediverse microblogging services (including, to some extent, /kbin) which will most heavily feel the impact of Threads. It is currently possible for microblogging platforms like Mastodon to interact with the threadiverse, but it is not optimized for this type of content, with non-linear threads sorted by recency and user voting. Mastodon and other "microblogging-side" fediverse users have mostly just signed up for Lemmy/kbin accounts, because stuffing a link aggregator through a blog-shaped hole is a terrible experience. How many Mastodon users have you noticed in your time on the threadiverse?

Threads as it exists currently is even less optimized to interact with the threadiverse than Mastodon, with no support for accessing groups (which it would need to see Lemmy communities/kbin magazines) whatsoever. If Threads were to start federating today, without any way to navigate the threadiverse, the only way to interact with our threads would be to visit a Lemmy/kbin instance directly in order to find a thread they're interested in, then copy the address to that thread, paste it into Threads to load it up as if it was a Twitter/Mastodon/Threads timeline, and finally start interacting with it. Consider that this is too much effort for the average Mastodon user–will Threads users be even more dedicated to posting on Lemmy/kbin than Mastodon users are now? Probably not. It's possible Meta will implement groups support in Threads before they start federating, but that still places them where Mastodon is now: such a poor way to interact with the threadiverse that nobody bothers.

Party analogy: The threadiverse and the microblogging fediverse are two different parties, a couple of street apart. Occasionally, somebody from one party will wander over to see the other one, but everyone's speaking some foreign language they don't understand, so they get bored and wander off again.

Why are people worried about federating with Threads?

Many fediverse and threadiverse users are concerned that Meta's Threads joining the fediverse will be harmful to the rest of the fediverse, for a number of reasons. This will not be an exhaustive list, but some of the causes for concern people have stated include the following:

1. Meta wants to attract the fediverse's users to leave their respective instances and join Threads instead

   The idea here is that Meta is specifically targeting the current fediverse userbase and desires to have them on their service

2. Meta wants to embrace, extend and extinguish (en.wikipedia.org) competing social media so that they have all of the users in perpetuity

   This is similar to the above, in that Threads will make proprietary improvements to their instance which make using alternatives an inferior experience so that people naturally prefer Threads, but with the end goal being that competitors die off so that future users have no choice but to join Threads

3. Meta wants to access all of our data in order to use it against us for marketing or other creepy data-hoarding purposes

   This one's pretty self-explanatory.

4. The large userbase of Threads (currently at 104 million registered accounts, compared to 12 million fediverse accounts) will overwhelm the culture and moderation of the fediverse

   Before anybody starts: yes, there's that many Threads accounts. Meta has reserved accounts for all one billion+ Instagram accounts but there is no indication that they are counting those as registered Threads accounts, which you can see for yourself by considering which number is bigger out of 104 million and 1 billion.

Some of these concerns have more merit than others, so let's address that next.

How will defederating from Threads protect us from the above?

Necessarily, some of the below are just my opinions since it's what I imagine Meta's motives are and how they relate to the goals of the threadiverse. While Meta may well be hostile to the fediverse, how it will impact the threadiverse is a different question.

1. Meta wants the fediverse's current users

   Firstly, the fediverse is a drop in the ocean compared to Threads (104 million registered [note: not active, we don't have those figures] users). Obviously, Meta wants everybody, but their specific goals in terms of user-poaching are far more likely to center around the ~350 million active Twitter users than the ~12 million fediverse users (~3.5 million active). The threadiverse is smaller again, at something like 100,000 active users. We're not even in the same medium as Threads and the current size of our userbase is not a threat to Meta or anybody else's dominance in the social media space.

   Defederating prevents us from being exposed to the handful of Threads users who are dedicated enough to figure out how to post to the threadiverse via the Threads microblogging interface. They were unlikely to convince us to move to Threads in this manner, so defederation doesn't do much here. 100,000 threadiverse posters are not a high priority for Meta, who are currently gaining about 4 million Threads users per day.

2. Meta wants to EEE the fediverse so that it never becomes a threat in future

   This is plausible, but again more of a concern for the microblogging side than the threadiverse. Threads could extinguish the entire microblogging community and we'd still be over here upvoting articles about how Meta just caused mastodons to go extinct for the second time in history.

   Defederating doesn't really do anything here. Until Meta decides to launch a Reddit-like (which could happen), any extension and extinguishing they do will be of software that's in the same microblogging arena as they are. Nothing indicates that they are currently trying to compete with link aggregators.

3. Meta just wants our data

   The fediverse (including Threads in future) doesn't really get our "data" via ActivityPub in the way people generally think about it. ActivityPub doesn't share our IP addresses, email addresses, click tracking, etc. Only the public interactions we make are shared (posts, comments, votes), and we already know we're sharing those because we're posting them on the Internet. More importantly, defederating changes literally nothing about how much of our content Threads can see. Remember the street party: defederating means we're not eating Meta's fondue. They're still eating our thing of candy beans.

   Defederating does literally nothing to prevent Meta accessing your data.

4. Threads will overwhelm the fediverse with their inferior content and culture

   Like the EEE fears, this one is legitimate but once again something that will primarily be felt by microblogging providers (/kbin included). Toxic users, advertisers, etc. can push garbage into feeds all day, but they will largely not be targeting the threadiverse because there's some 100 million sets of eyes to put that crap in front of on the microblogging side and it will be difficult-to-impossible for them to push that content into Lemmy/kbin threads from their interface that was never made to interact with the threadiverse.

   Defederating will again have a minimal impact, because Threads content is not coming to the threadiverse in the first place.

In short, these fears, for the threadiverse specifically, are mostly misplaced and not addressed by defederation anyway. Some of these concerns are valid for the microblogging softwares like Mastodon and to a lesser extent, /kbin, since microblogging is where Threads will be interacting with the fediverse and have the most opportunity to cause damage. While it's different for microbloggers, threadiverse instances defederating Threads is more of an ideological choice than a practical one, which is fine. I am passing no judgment on anybody who makes that decision.

Is there any chance Meta has good intentions?

No.

But it might have intentions that are both self-serving and fediverse-neutral.

The absolute best intention I can possibly ascribe to Meta is that joining the fediverse is a CYA (cover your ass) mechanism to head off regulations, especially in the EU, where the newly-applicable Digital Markets Act regulates "gatekeepers" of Core Platform Services like online social networks to prevent them from using their popularity to hinder other providers becoming or remaining available.

The EU has not released their list of who they identify as "gatekeepers" currently, but it is expected to include all of "Big Tech": Alphabet, Amazon, Meta, Apple, and Microsoft. By joining the existing fediverse community, Meta may hope that this allows them to claim they are not in control of the social network and so not subject to DMA regulations, or failing that, that it proves Meta are playing fair with other social media providers since Threads is graciously allowing services like Mastodon to exist. This becomes even more likely when considering that direct Threads competitor Tumblr is also planning to join the fediverse.

The fact that Threads doesn't support federation yet and is also not available in the EU yet is probably not a coincidence, since in their current state there's no indication that they're trying to accommodate other social media providers as they would likely be required to do. Some of the obligations under the DMA are that social media "gatekeepers" must support communication with other social media platforms and portability of user accounts across different providers.

Let's have a look at Meta's big introduction of Threads (I'll quote you the good bit so you don't have to actually visit Facebook):

Compatible with Interoperable Networks

Soon, we are planning to make Threads compatible with ActivityPub, the open social networking protocol established by the World Wide Web Consortium (W3C), the body responsible for the open standards that power the modern web. This would make Threads interoperable with other apps that also support the ActivityPub protocol, such as Mastodon and WordPress – allowing new types of connections that are simply not possible on most social apps today. Other platforms including Tumblr have shared plans to support the ActivityPub protocol in the future.

We’re committed to giving you more control over your audience on Threads – our plan is to work with ActivityPub to provide you the option to stop using Threads and transfer your content to another service. Our vision is that people using compatible apps will be able to follow and interact with people on Threads without having a Threads account, and vice versa, ushering in a new era of diverse and interconnected networks.

(Emphasis mine.)

If you read past all the marketing jargon, this is almost word-for-word just checking off the terms of the Digital Markets Act one by one and very publicly drawing attention to that fact. "Hey, look at us, we're doing all the things. You don't even need to regulate us, look how good we're being!" This doesn't mean "You should trust Meta," but it does offer one possible explanation for why they want to join the fediverse which is not "to destroy the fediverse."

tl;dr?

Defederation is about what an instance allows in, not what an instance allows out. Defederation stops you seeing the defederated instance's content, but it does not stop them seeing your instance's content.

Threads poses some danger to the fediverse, in particular the portion of it centered around microblogging (mostly Mastodon, but also Pleroma, parts of /kbin, etc.), but very little risk to the threadiverse.

The worst thing about the fediverse is all the fondue, but you don't have to eat it.

What's your problem with fondue?

Honestly nothing, I've never even had it. I just hate what the fondue represents.

Something I don't understand currently about the whole Meta/Threads debacle is why I'm seeing talk about instances which choose to federate with Threads themselves being defederated. I have an account on mastodon.social, one of the instances which has not signed the fedipact, and I've had people from other instances warn me that their instances are going to defederate mastodon.social when Threads arrives.

I have no reason to doubt that, so, assuming that they are, why? I don't believe instances behave as any kind of relay system: anybody who wishes to defederate from Threads can do so and their instances will not pull in Threads content, even if they remain federated to another instance which does.

I'm unsure how boosts work in this scenario, perhaps those instances are concerned that they'll see Threads content when mastodon.social or other Threads-federated instances users boost it, or that their content will be boosted to Threads users? The two degrees of separation would presumably prevent that, so I can see that being a reason to double-defederate, assuming that is how boosts work (is it?).

Other than that, perhaps the goal is simply to split the fediverse into essentially two sides, the Threads side and the non-Threads side, in order to insulate the non-Threads side from any embrace, extend, extinguish behavior on Meta's part?

Ultimately, my long term goal is just to use kbin to interact with the blogging side of the fediverse, but there are obviously teething issues currently, like some Mastodon instances simply aren't compatible with kbin. I'm too lazy to move somewhere else only to move to kbin "again" after that, so in the short term I guess I'll just shrug in the general direction of Mastodon.

To be clear, I have a pretty solid understanding of why people want to defederate Threads (and I personally agree that it's a good idea), it's the double-defederation I'm not sure I follow. Is my understanding at all close? Are there other reasons? Thanks for any insight.

I'm always seeing "first CD-ROM game" citations that are totally inconsistent, or which cite games like Myst, so I decided to put together a timeline of all the candidates - and ended up calling into question the point of "firsts" lists in the first place.

Fun article on retro CD-ROM games put together by @misty

Get a unique look at how controllers evolved into intricate devices, transforming games into immersive tactile adventures. Join our virtual CT scan journey through Xbox, PS5, and SNES gamepads.

While you could achieve a lot of this with my new invention the screwdriver (patent pending), these scans look pretty cool and you can also non-destructively inspect parts like the batteries, which it would otherwise be unwise to disassemble and reassemble.

Before I get started, I want to be clear that this has been my first time ever doing pixel art. I'm more interested in talking about the tech than my (lack of) artistic skill.

Background

Everybody knows QR codes; even if they didn't before 2020, they do now. But for an extremely quick rundown, they're just a bunch of data encoded using pixels as binary 0s and 1s, with some extra stuff used for orientation and tracking so that scanners know how to find the code in a larger image, etc. They come in many different resolutions, from 21x21 all the way up to 177x177, with a total of 40 available code sizes. They mostly look like a square of random pixels.

No doubt, you've seen custom QR codes before; usually somebody slapping their company logo in the middle or something. The way this works is that QR codes set aside some of their pixels for error-correction data. If the code is damaged in some way (such as somebody slapping their company logo in the middle), the error correction data allows your scanner app to reconstruct the damaged part of the code so that it can scan anyway. It's fine, I'm not criticizing anybody who does that, it's just that it grosses me out super hard to deliberately corrupt some data and be like "Robot will get it." Maybe there's a better way?

Each size of QR code has a set capacity in terms of how many bytes of data it can carry. Most QR codes are not completely filling their capacity: for example, the smallest QR code (version 1) can fit at most 25 characters of text, but if you e.g. make a QR code that links to https://kbin.pub/, you've only used 17 characters. Even if you increase the error correction level, you still have space for 20 characters, which leaves three characters worth of data that are empty. To cope with this situation, QR codes need to be able to fill any free space with a bit of "meaningless" padding data.

Going by the QR code specification, this padding data is technically supposed to have a specific repeating sequence, but in practice, QR code scanner tools don't actually care what the padding values are--after all, it's just padding. That means we're finally getting to the fun part: what if we could arrange that padding in such a way that it forms a small piece of 1-bit pixel art? The result would be a customized QR code which has all of its data intact, without having to rely on error-correction like some feral animal.

Setup

@revk has created an app, simply called QR, which can perform this function, and can be built and operated from the Linux console. Personally, my Linux proficiency ranks at "I have used Linux before, no further questions please." Mostly, I just run Windows, ~~although my Wii U runs Linux~~. That said, if you're a pleb like me, modern Windows (10+) makes it pretty easy to use a virtual Linux machine. You can open the Microsoft Store and download a Linux distro to run like a Windows app. Personally, I use Debian, but these instructions should also work for any of the Ubuntu flavors. If you're already a Linux user, you probably know what you're doing. On Mac, I have no idea.

First, you'll need to set up your Linux user and passwords, which I won't cover here. After that, the following lines can be typed or pasted into the Linux console. As always, don't trust some Internet jerk telling you to paste things into the console. Except this once. Note that the line cd /mnt/c assumes that the Windows C:\ drive is where you want to do your QR code work. You can change the path as appropriate to your needs, e.g. in real life, I used cd /mnt/c/Coding/revk. Note that you can't cd to a directory without creating it first, but I'm not explaining all of that here. Let's go already!

First up, install the dependencies:

sudo apt-get update && sudo apt-get install build-essential git libpopt-dev libz-dev

Then, enter the super-user password you set up earlier. Eventually, you'll get a prompt like this:

Need to get 101 MB of archives.
After this operation, 361 MB of additional disk space will be used.
Do you want to continue? [Y/n]

At this point, press Enter/Return to continue, or don't if you've changed your mind. It will probably take a few minutes to complete these package installs, then you can go back to entering these commands:

cd /mnt/c
git clone --recurse-submodules https://github.com/revk/QR.git
cd QR
make

If everything has gone to plan, you now have a Linux executable called qr in your C:\QR directory (or wherever you chose instead). If you like, you can move that executable to somewhere more convenient to you, do what you want. As a quick test, let's make a sample QR code by typing/pasting something like this into the console. Make sure you include the ./ on the front.

./qr "Hello world!"

Ideally, this will have printed a QR code directly into the Linux console which looks something like this:

█████████████████████████████
█████████████████████████████
█████████████████████████████
█████████████████████████████
████       █     █       ████
████ █████ ██ █ ██ █████ ████
████ █   █ ██  ███ █   █ ████
████ █   █ ██   ██ █   █ ████
████ █   █ ███ █ █ █   █ ████
████ █████ ████  █ █████ ████
████       █ █ █ █       ████
████████████     ████████████
████  █  █ ██  █ █ █████ ████
██████ ██ █ ████  ███  ██████
████ █ ██  ██  ██ ████   ████
████    ███     █ █ ██ ██████
█████  █ █  ██ █████  █ █████
████████████ ███      █  ████
████       ██  █   █ █ ██████
████ █████ ███     █   █ ████
████ █   █ █  █  ██ █ █ █████
████ █   █ █    █  ██████████
████ █   █ ███           ████
████ █████ █   █ █       ████
████       █ ██    ██████████
█████████████████████████████
█████████████████████████████
█████████████████████████████
█████████████████████████████

If not, I guess start regretting you ever read this thread.

Example

Now that you have the tool set up, it's time to start making pixel art for it. You enter the padding as plain text, like kind of janky ASCII art. You can pass it in as a console argument directly, but I find it easier to do it using a text file. For example, here's a text file I used to make one of my QR codes. I saved this file to the same folder as the qr executable for ease-of-access. For reference, Xs are black pixels, .s are white pixels, and (spaces) mean for the tool to handle filling those padding areas. Note that RevK's tool expects this file to have Unix line endings (LF), not Windows CRLF. Windows line endings are treated as black pixels, so they will interfere with your art.

mastodon.txt

  ..............  
 ................
....XXXXXXXXXX....
...XXXXXXXXXXXX...
..XXX...XX...XXX..
..XX..........XX..
..XX..XX..XX..XX..
..XX..XX..XX..XX..
..XX..XX..XX..XX..
..XX..XXXXXX..XX..
..XX..XXXXXX..XX..
..XXXXXXXXXXXXX...
...XXXXXXXXXXX....
...XXXX..........
 ...XXXXXXXX....  
 .....XXXXXX..    
  ............    
    ..........    

Then, you can create your QR code with a command like this:

./qr -v 5 --mm=4 --random https://joinmastodon.org --png --right [email protected] --outfile=mastodon-qr.png

To briefly explain these arguments

• -v 5: use a QR code version (size) of 5 (37x37 pixels)
• --mm=4: upscale the result 4x
• --random: fill any "unused" padding with random data
• https://joinmastodon.org: the payload when you scan the code
• --png: save the file as a PNG
• --right: rotate the code to the right
• [email protected]: use the padding layout stored in mastodon.txt
• --outfile=mastodon-qr.png: save the file as mastodon-qr.png

You can get a full list of the possible arguments with the following:

./qr -?

Canvas sizes

An extremely useful argument to use when figuring out your canvas size is to replace --png with --png-colour. This will output your QR code overlaid with colors to indicate which areas are data (blue), padding (green) and red (error correction). Also remember that depending on the orientation of your artwork, you may want to change the code rotation with --up, --down, --left or --right.

The size of the padding area will vary based on a) the length of your payload and b) the code version (1-40). Try to keep your payloads short, and use a QR version of about 5 (37x37 pixels). If you don't set a code version manually, the tool will generate as small a code as possible for your payload, which is not conducive to pixel art. In my experience, version 5 is the ideal compromise of canvas size and code readability. For reasonably short URLs like a bare domain or e.g. link to a social media profile, a version 5 code should net you at least a 16x16 pixel area for your pixel art to inhabit. Version 6 is larger (total size of 41x41 pixels), but the padding is intermingled with the encoded data, so it's not really going to give you one contiguous canvas to work with, making it sort of break-even against version 5 but (very) slightly harder to scan. You might be able to find a use for it, though.

Version 7 and above place alignment blocks (3x3 blocks of hardcoded squares) all over the code to make it easier for scanners to orient themselves, but these are going to infringe on your canvas as well. If you really want to push out the boat, you can use a massive version 40 code to get a giant canvas, but nobody wants to scan those awful hogging messes in real life, and you'll basically be refusing people who use budget smartphones, etc. because they can't reliably focus and resolve such large codes with their cheaper camera sensors. Plus, you'll have like 30 alignment blocks to either work around or try to incorporate into your art.

Color

All right, earlier in the thread, I said we'd be creating 1-bit pixel art, but in practice I've hideously violated that restriction in all but one of my examples (the Matrix logo). While you can set your light and dark colors in RevK's tool, this kind of color fudging is not something it supports or intends; I've just gone in and hand-painted in some extra color to try to make things pop a bit more. I've basically tried to keep sort of within a luminance range to make sure the colors still read as "black" and "white" even though they sometimes vary by a lot in hue (e.g. the Jack-o-Lantern with its yellows, oranges and purples).

Credits

Obviously, the bulk of the credit here belongs to @revk for developing the tool I used here.

I will also credit Igara Studio for the Aseprite logo used in one of my examples, and Brandon James Greer for his monkey avatar in another (I will also note that both codes when scanned lead to the aforementioned links). Lastly, the MacPaint icon is a modification of a graphic included in legacy versions of Apple's MacPaint for Classic Mac computers.

PS

Hi, threadiverse! This was originally posted to kbin.social while federation was down. Apologies to kbeans who already saw it, but I figured it was worth reposting now that we're all connected again.