Fediverse

***Please DM me if you are interested ***

Standalone Instance If Your Interested In Joining

We are NOT federated with the rest of lemmy The reason is safety issues when it comes to weirdos posting disgusting crap and it's just chilling on your server.

Our admin team doesn't want that liability.

One advantage with no federation is that we welcome you to post content you've created. Like memes or funny videos.

As long as you're chill, posting in the appropriate community, we're not going to lay the hammer on you. Or take down your post over dumb stuff.

Lastly, you should join our Instance if you feel your values align with ours. It's important to note that we understand that at the end of the day, lemmy is just a hobby.

We don't have a desire to be, we'll, tyrants. People disagree, and we get that. Not everyone thinks the same or believes the same things. That's just the truth.

We're just regular people like anybody else and want a place where we can actually be ourselves and not walk on eggshells.

If you feel we might be a fit for you, feel free to sign up or message me with any questions.

Also, we understand the appeal that federation has for some folks. I'm not trying to push the idea that being standalone is better. If that's not for you

We totally get that and hope you find a lemmy server that better suits your needs.

Thank you for your time

Based on data from https://fedipact.veganism.social/ it seems that the majority of instances blocks threads.net. I'm sure there's Lemmy instances with either approach that have slipped through the cracks as the list is a work in progress.

The percentage of users doesn't correlate to instances as the biggest instance on the Lemmyverse has roughly 3x the users of the second largest, a NSFW instance, 4x the users of the biggest "niché" instance and 5x the users of what I see as the second largest general purpose instance.

cross-posted from: https://mander.xyz/post/7593930

This is the most comprehensive analysis of the Threads situation that I have seen to far. I recommend giving it a read.

Yeah really, excellent article!

The Fediverse is currently divided over whether or not to block Threads. Here are some of the things people are worried about, some opportunities that might come from it, and what we need to do to prepare.

((I'm not an expert, I've been reading up on things as much as I can. If there's an error, I'll happily correct it!))

TLDR:

• Nearly all of us distrust Meta and have the same broader goals
• We need to pick the best move to go against powerful companies like Meta
• Defederation may not be the right move, and it might even help Meta move forward (and more easily perform EEE)
• There are other options that we can spend our energy on
• It doesn't matter for Lemmy (yet), this is more a conversation for Mastodon, Firefish and Kbin

We've been getting a LOT of posts on this, but the misconceptions make it harder for us to decide what to do. If we're going to try and protect the Fediverse against large, well funded companies like Meta, figuring out the right action is important. We need to actually look at the options, consider the realistic outcomes, and plan around that.

I'm willing to bet around 95% of users on Lemmy and Mastodon CHOSE to be here because we understand the threat Meta/Facebook poses, and we want to do something about it. That's not in question here.

So in that sense, please be kind to the other user you are replying to. The vast majority of us share the same goal here. When we disagree, we disagree on the best path forward and not the goal. Wanting to stay federated DOES NOT mean the user wants to help Meta or thinks that Meta is here for our benefit.

Misconception: Defederation will hinder Meta's EEE

Not necessarily, and it might even help the EEE. Here's a link to some history of EEE, what it means, and some examples: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish. I'd recommend at least skimming it because it's interesting (and because this isn't the only fight)

Assuming Meta is doing an EEE move, they're in the embrace stage. That’s not about us embracing them, it’s about them embracing the protocol, which they can do whether we stay federated or not.

Defederation can tell newcomers that the defederated instance is an island, and they’re better off joining the place where they can talk to their friends and see the content they want. We saw this early during the Reddit exodus with Beehaw, where many users hopped instances away from Beehaw.

Meta can more easily embrace if more people actively use their platform. They can more easily extend if we're not around to explain why extending is a poisonous action. Being federated can allow us to encourage users to ditch Meta’s platform and join an open one (ex. Mastodon, Firefish, etc.)

Misconception: Defederation is the only move

Defederation is the first option that comes to mind. It sounds simple, it is loud and newsworthy, and it can be done with the click of a mouse. But if it is a bad action, then what are the good actions?

1. Don't let them have a monopoly over the use of ActivityPub. Grow the other platforms: The extend stage only works when the platform gets a near monopoly over use of the standard. That brings up the first action. If there are enough users, services and resources on things like Mastodon/Lemmy, then Meta (or any other company) can't just extend the spec without causing their users to ditch Threads to stay connected to the content they want to see.
   • Reach out to organizations in your area or line of work. Help them join Mastodon or other relevant Fediverse platforms. I'm sure the for-profit companies put money into this process, so brainstorm and reach out
   • Add your Fediverse accounts to the bio of your other accounts, and share posts from the Fediverse elsewhere

As long as there is a healthy community away from Meta (ex. what we have right now), then they can't extend & extinguish.

2. Protect the Standards and share why it is important

• Share posts from experts about strict adherence to standards, support regulatory and legal advocacy (interoperability requirements etc.), and educate other users about the risks.

(I didn't want to say more here because I'm not an expert, I'm happy to edit more points in)

Misconception: We should still defederate because of Privacy Risks

Not necessarily (and likely not at all?)

Meta is notorious for gathering data and then abusing that data, so this is an issue to consider. However, the way that activitypub works, the outgoing data is publicly available. Defederating with Meta doesn't prevent that, and federating doesn't give them any more data than they could get otherwise.

Lemmy instances need to decide

This is a big point: It doesn't really matter for Lemmy right now, one way or another.

It's more of an issue when data start coming IN to Lemmy from Mastodon and Meta's Threads. See below

Legitimate risks from Federation with Meta, and more effective ways to counter them

• Algorithmic Amplification: Meta's history of using algorithms that prioritize engagement can amplify harmful or divisive content. These algorithms are not public like it is with Mastodon and other FOSS platforms.

• Misinformation and Content Moderation: All Fediverse platforms will have to work on content moderation and misinformation. Platforms like Meta, focussed on profit and advertising, will likely moderate in a way that protects their income. Those moderation decisions will be federated around.

• Commercialization and User Exploitation: Meta's for-profit nature means it's incentivized to maximize user engagement, at the expense of our well-being.

Counters:

• Promote user control over their feeds, and develop USEFUL but safe and open algorithms for the feeds
• Flag content and users from risky platforms, with a little warning icon and explanation (ex. 'Content is from a for-profit platform, and it may ___')
• Implement features so that users can opt in or opt out from seeing content from risky platforms. In particular on explore/discover/public feeds, so it doesn't affect content the user is following.
• Develop strict community guidelines that can get Meta (and other companies) sent into the 'blocked by default' bins mentioned above.

Final point: Evaluate things critically. Don't even just take my word for it. I doubt Meta or other groups care enough about Lemmy yet to spread disinformation here, and every post I've seen promoting defederation feels like a good faith attempt for something they believe in. But it's still worth thinking about what we're supporting.

Sometimes what feels like a good move might not help, and could even make things worse.

cross-posted from: https://lemmy.world/post/9799372

What's Meta up to?

1. Embrace ActivityPub, , Mastodon, and the fediverse

2. Extend ActivityPub, Mastodon, and the fediverse with a very-usable app that provides additional functionality (initially the ability to follow everybody you're following on Instagram, and to communicate with all Threads users) that isn't available to the rest of the fediverse – as well over time providing additional services and introducing incompatibilities and non-standard improvements to the protocol

3. Exploit ActivityPub, Mastodon, and the fediverse by utilizing them for profit – and also using them selfishly for Meta's own ends

Since the fediverse is so much smaller than Threads, the most obvious ways of exploiting it – such as stealing market share by getting people currently in the fediverse to move to Threads – aren't going to work. But exploitation is one of Meta's core competences, and once you start to look at it with that lens, it's easy to see some of the ways even their initial announcement and tiny first steps are exploiting the fediverse: making Threads feel like a more compelling platform, and reshaping regulation. Longer term, it's a great opportunity for Meta to explore – and maybe invest in – shifting their business model to decentralized surveillance capitalism.

This feature is particularly important as threads starts to federate. Without authorized fetch, there is the possibility of content from folks who are defederated from threads making their way over through intermediary followers.

cross-posted from: https://slrpnk.net/post/5068112

Highlights include:

0:51 Looking back on Mastodon’s epic year
3:22 Small team, big goals
4:55 The arrival of Threads/Meta: pro or con?
9:01 The way Mastodon/Fediverse is architected to provide a better social media experience
11:24 The “big win” of Meta adopting an open standard
12:10 The game-changing paradigm shift in how social media works
17:30 Why Meta is committing to Threads — a significant moment for the social web
18:10 Mastodon community’s reaction to Threads’ entry
19:24 Preemptively building walls to block Threads: self-defeating?
21:10 Tools and advice for instance owners on interoperating with Threads
26:09 Gaining momentum: who will federate next?
28:34 Bluesky
30:00 ActivityPub: the beauty of a generic protocol
38:24 User experiences in the Fediverse
41:06 “Embrace, extend, extinguish” and the XMPP comparison
50:28 Funding Mastodon through Patreon donations
53:10 U.S. nonprofit version of Mastodon and grant applications
54:23 On outside contributions to Mastodon’s code base
57:42 Hopes and dreams for the future

Eternal September or the September that never ended is Usenet slang for a period beginning around 1993 when Internet service providers began offering Usenet access to many new users. The flood of new users overwhelmed the existing culture for online forums and the ability to enforce existing norms. AOL followed with their Usenet gateway service in March 1994, leading to a constant stream of new users. Hence, from the early Usenet point of view, the influx of new users in September 1993 never ended.

Made by Nume MacAroon at Veganism.social https://veganism.social/@nm

There's a common false dichotomy about #Threads: cut them off, or leave it to user choice.

I can't speak to other software, but Mastodon offers a third option: limiting Threads. This can be done for all users of a server.

- You can follow Threads accounts after clicking through a warning.

- People who don't follow those same people won't see their posts.

- You have to manually approve followers _from_ Threads.

Basically, it puts Threads in quarantine, without cutting off all connections.

I like that option for our server, social.coop, and it's the one we voted to implement earlier this year.

We know that Threads already hosts bad actors (e.g., LibsOfTikTok). We know some reasonable folks have set up shop there and will continue to flee there from X.

This option makes it clear that Threads is not a safe space, while allowing limited connections.

Every instance will implement the option that makes sense to them, of course.

social.coop/@eloquence/1115888…

Año 2023. Todo Internet está bajo el control del imperio GAFAM. ¿Todo? No. Porque algunos pequeños pueblos se resisten a la opresión. Y algunos de esos pueblos comenzaron a agregarse, formando el «Fediverso».

cross-posted from: https://lemmy.ml/post/9347983

What is Lemmy?

Lemmy is a self-hosted social link aggregation and discussion platform. It is completely free and open, and not controlled by any company. This means that there is no advertising, tracking, or secret algorithms. Content is organized into communities, so it is easy to subscribe to topics that you are interested in, and ignore others. Voting is used to bring the most interesting items to the top.

Major Changes

This release is very large with almost 400 commits since 0.18.5. As such we can only give a general overview of the major changes in this post, and without going into detail. For more information, read the full changelog and linked issues at the bottom of this post.

Improved Post Ranking

There is a new scaled sort which takes into account the number of active users in a community, and boosts posts from less-active communities to the top. Additionally there is a new controversial sort which brings posts and comments to the top that have similar amounts of upvotes and downvotes. Lemmy's sorts are detailed here.

Instance Blocks for Users

Users can now block instances. Similar to community blocks, it means that any posts from communities which are hosted on that instance are hidden. However the block doesn't affect users from the blocked instance, their posts and comments can still be seen normally in other communities.

Two-Factor-Auth Rework

Previously 2FA was enabled in a single step which made it easy to lock yourself out. This is now fixed by using a two-step process, where the secret is generated first, and then 2FA is enabled by entering a valid 2FA token. It also fixes the problem where 2FA can be disabled without passing any 2FA token. As part of this change, 2FA is disabled for all users. This allows users who are locked out to get into their account again.

New Federation Queue

Outgoing federation actions are processed through a new persistent queue. This means that actions don't get lost if Lemmy is restarted. It is also much more performant, with separate senders for each target instance. This avoids problems when instances are unreachable. Additionally it supports horizontal scaling across different servers. The endpoint /api/v3/federated_instances contains details about federation state of each remote instance.

Remote Follow

Another new feature is support for remote follow. When browsing another instance where you don't have an account, you can click the subscribe button and enter the domain of your home instance in the popup dialog. It will automatically redirect you to your home instance where it fetches the community and presents a subscribe button. Here is a video showing how it works.

Authentication via Header or Cookie

Previous Lemmy versions used to send authentication tokens as part of the parameters. This was a leftover from websocket, which doesn't have any separate fields for this purpose. Now that we are using HTTP, authentication can finally be passed via jwt cookie or via header Authorization: Bearer . The old authentication method is not supported anymore to simplify maintenance. A major benefit of this change is that Lemmy can now send cache-control headers depending on authentication state. API responses with login have cache-control: private, those without have cache-control: public, max-age=60. This means that responses can be cached in Nginx which reduces server load.

Moderation

Reports are now resolved automatically when the associated post/comment is marked as deleted. This reduces the amount of work for moderators. There is a new log for image uploads which stores uploader. For now it is used to delete all user uploads when an account is purged. Later the list can be used for other purposes and made available through the API.

Cursor based pagination

0.19 adds support for cursor based pagination on the /api/v3/post/list endpoint. This is more efficient for the database. Instead of a query parameter ?page=3, listing responses now include a field "next_page": "Pa46c" which needs to be passed as ?page_cursor=Pa46c. The existing pagination method is still supported for backwards compatibility, but will be removed in the next version.

User data export/import

Users can now export their data (community follows, blocklists, profile settings), and import it again on another instance. This can be used for account migrations and also as a form of backup. The export format is designed to remain unchanged for a long time. You can make regular exports, and if the instance becomes unavailable, register a new account and import the data. This way you can continue using Lemmy seamlessly.

Time zone handling

Lemmy didn't have any support for timezones, which led to bugs when federating with other platforms. This is now fixed by using UTC timezone for all timestamps.

ARM64 Support

Thanks to help from @raskyld and @kroese, there are now offical Lemmy releases for ARM64 available.

Activity now includes voters

• Previously, site and community activity counts were only based on people who commented, or posted. Those counts now include anyone who voted on a comment or post as well. Thanks to @Ategon for this change.

Upgrade instructions

Follow the upgrade instructions for ansible or docker. The upgrade should take less than 30 minutes.

If you need help with the upgrade, you can ask in our support forum or on the Matrix Chat.

Pict-rs 0.5 is also close to releasing. The upgrade takes a while due to a database migration, so read the migration guide to speed it up. Note that Lemmy 0.19 still works perfectly with pict-rs 0.4.

Thanks to everyone

We'd like to thank our many contributors and users of Lemmy for coding, translating, testing, and helping find and fix bugs. We're glad many people find it useful and enjoyable enough to contribute.

Support development

We (@dessalines and @nutomic) have been working full-time on Lemmy for over three years. This is largely thanks to support from NLnet foundation, as well as donations from individual users.

This month we are running a funding drive with the goal of increasing recurring donations from currently €4.000 to at least €12.000. With this amount @dessalines and @nutomic can each receive a yearly salary of €50.000 which is in line with median developer salaries. It will also allow one additional developer to work fulltime on Lemmy and speed up development.

Read more details in the funding drive announcement.

I know there is mobilzon but mobilzon is a meetup.com clone whereas evite is different.

Evite you can create an event and invite people via email or send them a link. They can rsvp and add it to their calendars.

Come of these features are covered by mobilzon but not quite. Evite doesn't require you make a group or add people to the group as members. It's a little more atomic. Honestly I think it's a good deal more flexible than the meetup/mobilzon design pattern.

Default instance blocks should largely replace defederation

Since what content users might want to see is quite unlikely to match which servers the admins tolerate, choosing instance on the Fediverse can be quite complicated, which is inconvenient and off-putting for new users.

For this reason, and simply that the Fediverse is stronger united, I believe defederation should ideally be reserved for illegal content and extreme cases. If Fediverse platforms would allow instances to simply block the rest for users by default, the user experience would be the same, unless they decide otherwise.

@fediverse #fediverse #defederation

https://www.threads.net/@zuck/post/C0zXcQmxO77

cross-posted from: https://lemmy.world/post/9483559

PeerTube is a decentralized and federated alternative to YouTube. The goal of PeerTube is not to replace YouTube but to offer a viable alternative using the strength of ActivityPub and P2P protocols.

Being built on ActivityPub means PeerTube is able to be part of a bigger social network, the Fediverse (the Federated Universe). On the other hand, P2P technologies help PeerTube to solve the issue of money, inbound with all streaming platform : With PeerTube, you don't need to have a lot of bandwidth available on your server to host a PeerTube platform because all users (which didn't disable the feature) watching a video on PeerTube will be able to share this same video to other viewers.

If you are curious about PeerTube, I can't recommend you enough to check the official website to learn more about the project. If after that you want to try to use PeerTube as a content creator, you can try to find a platform available there to register or host yourself your own PeerTube platform on your own server.

The development of PeerTube is actually sponsored by Framasoft, a french non-for-profit popular educational organization, a group of friends convinced that an emancipating digital world is possible, convinced that it will arise through actual actions on real world and online with and for you!

Framasoft is also involved in the development of Mobilizon, a decentralized and federated alternative to Facebook Events and Meetup.

If you want to contribute to PeerTube, feel free to:

• report bugs and give your feedback on Github or on our forums
• submit your brillant ideas on our Feedback platform
• Help to translate the software, following the contributing guide
• Make a donation to help to pay bills inbound in the development of PeerTube.