vaguerant
1y ago
•
100%
For the most part, Threads content just wouldn't appear on Lemmy at all. It's like how you can't see Mastodon users' timelines on Lemmy. e.g. Jeri Ryan from Star Trek is on mastodon.world, but you can't read her blog from Lemmy because it just doesn't display microblog content, only stuff that's sorted into groups (communities).
The one exception is that Jeri Ryan can track down the equivalent group on her Mastodon instance and "microblog" directly into the group. Mastodon has some hacky tweaks to do things like reading the first sentence as a heading, the second line as a URL, and the third line as the post body, so if you're especially dedicated you can post to Lemmy from Mastodon. If Threads cares enough, they could add similar functionality to Threads to make it technically possible to post to Lemmy as long as you try hard enough, but just regular people's blog posts on Threads won't display on Lemmy at all.
vaguerant
1y ago
•
100%
Thanks, I appreciate it! It took a stupidly long time. :V
On some level, it's probably not that important that people understand all this stuff, but I think the most dangerous thing is people believing that their data will be protected if Threads gets defederated. Any other confusion is basically harmless, but that's the one thing where people have a false sense of security, because Meta has exactly the same access to your data whether or not they get defederated.
vaguerant
1y ago
•
100%
No, I don't want to? Weird take.
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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Cover_your_ass)) mechanism to head off regulations, especially in the EU, where the newly-applicable [Digital Markets Act](https://en.wikipedia.org/wiki/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](https://about.fb.com/news/2023/07/introducing-threads-new-app-text-sharing/) (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*.
vaguerant
1y ago
•
75%
There are literally, not exaggerating, over one billion Instagram accounts in existence. It's self-evidently not the case that they have just silently registered everybody a Threads account and are counting those numbers.
vaguerant
1y ago
•
100%
Nice, thanks for the tip! Found a couple more recurring cast and added them to the list.
vaguerant
1y ago
•
77%
Meta is categorically evil, but the pretty obvious gain from federation is the same as it is federating with anything else: content. Threads has people posting on it, some of those people say interesting things ... the end.
That's not to say that outweighs the downsides, like some of that content will also undoubtedly be hateful bigoted trash, and the moderation load of suddenly dealing with an order of magnitude more posts will be a huge strain on fediverse admins who choose to federate, but there's undeniably something to gain.
vaguerant
1y ago
•
100%
I think what did it for me was episode 3, "About a Girl". Up to that point I was enjoying the show, but the third episode was the first one that you're really supposed to take seriously as an audience. I think this quote from the episode's director Brannon Braga is informative:
There was an episode that was supposed to be a later episode. I’ll call “About a Girl” which was about a transgender metaphor using our Moclan characters. [...] It’s a very dramatic episode. And we decided to pull it up in the air date order to the third episode because we had to know, “Is the audience going to embrace what this show really is?” And they did.
The episode isn't perfect and MacFarlane has even said he would do it differently if given the opportunity to write the episode again, but the show was leaving nothing on the table, taking a huge swing for this early in a series. I had been really missing sci-fi with a social conscience in the last decade or so before The Orville began, and this episode specifically felt like coming home after a long time.
vaguerant
1y ago
•
100%
From Tom's Threads (sorry).
J. Lee also posted a BTS photo, anybody recognize the episode?
Behind the scenes shot of J. Lee as John LaMarr in engineering
vaguerant
1y ago
•
80%
Definitely. Meta is studiously only sharing the number of accounts registered. We have no idea how many of those are active. If we go with the old 1-9-90 rule, only about 10 million of those 100 million will become active users. Although, the rule obviously isn't a universal constant. On the fediverse, for example, it's closer to ⅓ of registered users that are active.
vaguerant
1y ago
•
100%
You already got a solution to this, but an alternative mechanism for people who use uBlock Origin is to add this filter to your custom list:
kbin.social##^style
That assumes you're on kbin.social, obviously substitute in your home kbin instance.
vaguerant
1y ago
•
100%
This is untrue. Threads accounts are reserved for the matching Instagram user, but those users have to actually choose for that account to be opened. If all Instagram accounts were auto-converted to Threads accounts there'd be over 1 billion Threads accounts. The 100 million Threads users are all people who have specifically opted to have a Threads account.
vaguerant
1y ago
•
87%
In fairness, I think we might already be the rest who don't matter. Threads has just passed 100 million users in like three days. The entire fediverse, in about ten years (it's tough to pin down an exact start date because "When did it become the fediverse?"), has accrued around 12 million users, of which less than 4 million are active. There's any number of things Meta might want, but I don't think greater access to 4 million geeks is at the top of their list.
I do think the embrace, extend, extinguish concerns have some merit. Meta isn't threatened by the fediverse now, but maybe they do want to kill it before it becomes a problem. In the short term, though, we're not overtaking Threads. Personally, I think another plausible theory is that Threads is using ActivityPub to demonstrate that they're not running a monopoly or gatekeeping control of social media (which the EU's new Digital Markets Act now regulates) by pointing to the fediverse--which will soon also include direct competitors Tumblr--and saying "See, we're all on equal footing! We don't control social media! Look over there at those 4 million geeks and whatever number of Tumblr users."
vaguerant
1y ago
•
98%
It comes from Fortune, they can't conceive of something that's not a business.
vaguerant
1y ago
•
100%
Hard to tell. It's been in decline since January though, so some of it is just Twitter being a place people want to be less and less.
vaguerant
1y ago
•
100%
vaguerant
1y ago
•
100%
Here's the graph, as posted by CloudFlare CEO Matthew Prince:
vaguerant
1y ago
•
100%
If nobody has ever subscribed to a foreign instance's community/magazine before, it won't show up on your home instance. Currently, the best way to pull it into your local instance is to copy its web address on the other site into your local search.
e.g. If you wanted to pull in kbin.social's AskKbin from lemmy.world you'd find its URL, https://kbin.social/m/AskKbin, and paste that address into your home instance's search box. As long as somebody has done this once, AskKbin will now show up in regular community lists, searches, etc.
vaguerant
1y ago
•
100%
Get us a photo of the popsicle stick skyscraper before it burns down.
vaguerant
1y ago
•
100%
Lemmy communities are "groups" in ActivityPub parlance, and groups do exist on the microblogging platforms. Using Mastodon as an example for now, a Masto user could find the group equivalent to a Lemmy community and make a post and/or comment there and it would show up on lemmy.world and anybody else who federates with that Masto instance. In reality, the groups experience is kind of terrible and a poor interface to these thread-style communities, and you lose all kinds of features like the recency/score sorting algorithm, the ability to downvote things, etc.
It would take a true masochist to post to lemmy.world from Mastodon, which is why you almost never see it. I've seen one Mastodon user in my time on the threadiverse so far. Most people who are already on the microblogging side of the fediverse have just chosen to register a separate account on a threadiverse instance so they can have an actual usable interface rather than stuffing a link aggregator through a blog-shaped hole.
Groups don't even exist on Threads currently. Maybe they will by the time they implement ActivityPub, but they may not consider that to be a core goal as a microblogging, Twitter-style platform which has no obvious use for them. This would currently make Threads an even worse interface to the threadiverse (kind of ironic) than Mastodon, which I can't stress enough is already awful. You would just have to search for individual posts by browsing somewhere like lemmy.world directly, copying and pasting the URLs into the Threads app or web site to populate the conversation in their interface in order to reply to the posts and comments there.
In short, using Lemmy via Threads is probably going to be such a nightmare that only turbo-nerds will try to do it, and turbo-nerds are more likely to realize "This is awful and I should just go join Lemmy or kbin or something," than persist with that hassle long-term. Now, kbin users have more justification to be concerned about how Threads will impact their communities, because kbin supports microblogging directly--in corporate terms, it's like if Reddit and Twitter combined into one site that you could tab between on the fly. This means kbin users will be more likely to see Threads content and vice versa.
vaguerant
1y ago
•
100%
The other problem here is that I don't think a lot of people actually know how defederation works. There's lots of takes like "I don't want Meta to get my data, so we have to defederate." But defederating stops you from receiving their content, not the other way around. Once Threads actually is federating, defederating it will stop people seeing posts from Threads users. That has its own merits, but it doesn't protect your data in any way. If you don't want corporate entities to access your online posts, either send them via some private end-to-end encrypted system where only you and the direct recipients can see them, or don't post them online at all. The Internet is on the Internet.
Now, a bit more of an explanation on what defederation is: while the decentralized nature complicates things (since different servers will have different defederation lists), defederation is closer to a Reddit shadow-ban than whatever it is people are imagining. If literally everybody defederated Meta/Threads, they would still see our content, but from their (Threads users') perspective, it would just seem like we're all giving them the silent treatment, because we never respond to their posts or comments.
From `@tomtheorville` on Threads: > > > While I live a new life of threading, it’s time for a Reddit eulogy. My favorite `@Reddit` sub r/TheOrville went private, and now soon full meme. I fully respect why… since corp Reddit kinda sucks, but losing such a valuable resource also… sucks. The great threads on “Twice in a Lifetime” is mainly why we changed the Gordon rescue timeline. RIP! > > For anybody out of the loop, the original broadcast of season 3's "Twice in a Lifetime" had Gordon send his message asking for rescue after three months stranded on 21st-century Earth, then the Orville crew goes back in time to rescue him *one* month after he vanished, which would result in a grandfather paradox, since in that timeline Gordon would never have sent his message in the first place. Discussion of this issue on /r/theorville led to the team re-editing the episode to have the Orville arrive on Earth *four* months after Gordon. Tom probably has no idea we exist yet, but hopefully we can rebuild that community here so there's nothing for him to mourn.
I know we hate Threads here, but if any Union defectors want to support them, I won't tell. * Seth MacFarlane (Creator/Ed Mercer): [https://www.threads.net/@macfarlaneseth](https://www.threads.net/@macfarlaneseth) * Tom Constantino (Producer/Editor): [https://www.threads.net/@tomtheorville](https://www.threads.net/@tomtheorville) * J. Lee (John LaMarr): [https://www.threads.net/@jleefilm](https://www.threads.net/@jleefilm) * Planetary Union Network (official podcast): [https://www.threads.net/@planetaryunionnetwork](https://www.threads.net/@planetaryunionnetwork) All four have been heavily promoting The Orville already, which is definitely cool. Let me know if you find anybody else and I'll add their links to this post. **EDIT:** * Anne Winters (Charlie Burke): [https://www.threads.net/@annewinters](https://www.threads.net/@annewinters) (registered, no posts yet) * Rena Owen (Heveena): [https://www.threads.net/@renaowen](https://www.threads.net/@renaowen) **EDIT 2:** * Scott Grimes (Gordon Malloy): [https://www.threads.net/@scottchristophergrimes](https://www.threads.net/@scottchristophergrimes) **EDIT 3:** Threads seems to have moved to a login-only setup similar to Twitter; I can no longer see anybody's profiles on the web site. I'm not about to register an account with Meta, so I won't be able to find any more Orville people. I'll still add them if anybody with a Threads account finds them and leaves a comment, but this post is a much less useful resource if non-members can't see what they're saying. **EDIT 4:** Seems like they've rolled back that restriction again? Here's a couple more recurring cast members: * Larry Joe Campbell (Steve Newton, S01 Chief Engineer): [https://www.threads.net/@larryjoe](https://www.threads.net/@larryjoe) * Chris Johnson (Cassius): [https://www.threads.net/@yochrisjohnson](https://www.threads.net/@yochrisjohnson)
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](https://digipres.club/@misty)
www.scanofthemonth.com
> > > 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](https://toot.me.uk/@revk) has created an app, simply called [QR](https://github.com/revk/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, `X`s 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 --overlay=@mastodon.txt --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 * `--overlay=@mastodon.txt`: 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](https://toot.me.uk/@revk) for developing the tool I used here. I will also credit Igara Studio for the [Aseprite](https://www.aseprite.org/) logo used in one of my examples, and [Brandon James Greer](https://www.youtube.com/@BJGpixel) 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.