cross-posted from: https://sh.itjust.works/post/15086952
Hello sh.itjust.works community,
Many of you have been eager to get an update about when the sh.itjust.works instance will get it's upgrade to the latest version of lemmy. Here's a update along with a tentative timeline.
In December 2023 I purchased a new server for this community. It took me awhile but I eventually made the time to get it racked at the local datacenter. For the sysadmins lingering and those interested here are the specs:
- Dual Xeon 2.9Ghz CPUs (32 cores total)
- 256GB ram
- 4 x 1TB SSD in raid 10 (with room to add 6 more disks)
- 10gbit networking
While I'm ready to proceed with the upgrade, I've decided to first migrate this instance over to the new hardware. Here are two reasons.
- Those of you who have been around long enough may remember that I've been running this instance on "borrowed" unused resources that were available at the time. There are no more resources available for this instance to grow.
- There are reports that the latest version of lemmy may use more resources. Given we are among the bigger instances, should I end up in a situation where I need to increase resources to keep things fast I'll be restricted.
Here's the tentative timeline:
Task Date Expected Downtime Migration to new server Tuesday February 27 2024 @ 8:00PM ET 90 Minutes Upgrade to V19.3 Thursday February 29 2024 @ 8:00PM ET Up to 120 Minutes
- If anything major goes wrong on the 27th I will revert back the changes and bring the instance back up on the current server.
- If anything major goes wrong on the 29th I will revert back using an earlier snapshot. If that fails, I will restore from a backup.
During these two planned events those who want to provide moral support or who want to get periodic updates are more than welcome to join us on our matrix channel
Update February 29 2024
We've successfully completed the upgrade to v1.9.3. I'm happy to announce that we did it in an astonishing 27 minutes, a whole 93 minutes under what was expected. The extra leg work that was done over the last few weeks combined with the better hardware definitely played a part. Looking over the processes, it looks like the service responsible for images is still doing some work so it's possible that you will come across some broken images. I'll be keeping on eye on that over the next bit and make adjustments if needed. Thank you all for the support and to all of you who kept me company on our matrix channel. Have a good evening.
Update February 27 2024
We've successfully completed the migration. I'm happy to announce that this instance is now running on its new hardware dedicated solely to this community! We experienced just under 40 minutes of downtime which is a whole 50 minutes less than expected. Please give this instance a chance to catch up what it missed but we should be good within the next 30 or so minutes. Thank you
I am seeking Lemmy instances that federate with three specific instances but do not federate with one other specific instance. I prefer these instances to have more than 50 users to ensure a vibrant community but not be among the top 10 largest instances to avoid contributing to network centralization. Once I compile a list of instances meeting these criteria, I plan to assess their ping to identify the most responsive one.
Does anyone know of a website or an easy method to identify instances that meet these criteria?
Just wanted to share this interview we just put out with Jaz Michael-King, the guy that founded IFTAS. They're doing some really wild stuff trying to wrangle in harassment, spam, objectionable content, and CSAM, and are looking to provide tooling for the Fediverse, as well as trauma resources and training for moderators.
Really fascinating interview, I learned a lot by talking to him.
Hi everyone, I’m one of the administrators of the Lemmy feddit.it instance - my nick is @poliverso@[email protected]
Together with our fellow administrators, based on some impact assessments, we have decided not to operate any preventative block against Threads, but I am not aware that we are still federated. I noticed that your instance is federated to Threads instead, but I don’t understand how this was possible. The strange thing is that, from your instance, it is still not possible to view those dozen Threads accounts that are currently “federable”. So I wanted to ask you: is there a way to force federation?
Thanks in advance for your feedback, sorry for the inconvenience and best wishes for a happy holiday!
cross-posted from: https://lemmy.dbzer0.com/post/15112791
Hey y'all. I've been working on this little project ever since the recent spam wave started. This is a very basic Python automoderator bot which will monitor the comments and posts federated into your instance for specific regex instances and then automatically report, delete, ban etc.
The Bot setup is very simple, as you can just chuck its docker-compose entry into your existing lemmy one. You just need to fill in the relevant environment variables.
The bot works by constantly polling your incoming reports, posts and comments, and matching them against provided regex.
I wanted to keep things simple for admins, so the bot configuration happens via a simple PM syntax. The README goes into details on this. But you basically send a message like this to the Bot to add a new filter
threativore add comment filter: `trial period` reason: `Spam comment` action: `REMOVE` description: `Known spam string`
All bot controls work the same way. Eventually I want to add a UI to it.
The bot is built with collaboration in mind. So you can add more people to help you maintain your filters (even if they're not admins), you can add users whose reports will be treated more seriously, and you can even mark users as "ham" (i.e. known not spammers) to prevent them ever being filtered.
This is just the very first release and I have a lot of ideas to improve it in the future. Here's some stuff in my roadmap which should make the threativore a much more collaborative/crowdsourced process between multiple instance admins and the larger userbase. Stay tuned.
PRs and suggestion are welcome.
PS: The bot is already active on https://lemmy.dbzer0.com, so you can check the modlog for its actions.
I know there are a ton of iOS apps for Lemmy. But what are they missing? What experiences would you like? It could be quality of life or big and ambitious features Many of you often have really good ideas and feedback, I’m looking forward to responses.
Interesting post about BlueSky’s underlying federated protocol (AT Protocol)
There's another wave of discourse about The Bad Space on the microblogging side of the fediverse, so here's my article from a couple of months ago.
If you're familiar with Fediseer, there's some discussion of similarities and differences in Compare and contrast: Fediseer, FIRES, and The Bad Space
cross-posted from: https://slrpnk.net/post/7026921
This sounds like something Lemmy would also really benefit from.
As Bluesky begins to open up more and more, it's felt more pertinent to try to wrap my head around it. To help in this, I decided to write out my rough understanding of it from its documentation, in the hopes that it may help others and myself with any corrections from misunderstandings.
As Bluesky themselves note, the architecture is laid out in Personal Data Servers, Relays, & App Views. The intent is that each of these may be deployed and/or developed independently of Bluesky, with some caveats to each.
First & foremost, which is somewhat glossed over, is the notion that ordinary people will have the knowledge or interest in deploying their own Personal Data Servers. This isn't really touched on from what I've seen in their documentation, despite it being touted as such a major benefit of the architecture.
Second, which is recognized in their documentation, is that due to the high volumes of data involved, there are likely to be fewer Relays deployed instead of many. See the following:
The federation architecture allows anyone to host a Relay, though it’s a fairly resource-demanding service. In all likelihood, there may be a few large full-network providers, and then a long tail of partial-network providers. Small bespoke Relays could also service tightly or well-defined slices of the network, like a specific new application or a small community.
This inarguably undercuts much of the benefit of it as a distributed network given that Relays are what may enable much of the transfer of data across the network.
It is noted that this may be avoided via server-to-server networking, so we'll have to see how that shakes out given it's mentioned almost as an afterthought.
Third, data portability across a distributed network is absolutely an achievement, but it must be scrutinized. Their language concerning PDSs itself indicates they expect them to be as prone to ephemerality as existing fediverse instances, see:
We assume that a Personal Data Server may fail at any time, either by going offline in its entirety, or by ceasing service for specific users.
Data portability then is reliant on a few crucial details:
Clear communication of the need to safely store recovery keys and backups.
Retention of recovery keys in some way (people never lose recovery keys, right?).
Device safety/stability to ensure access to your Authenticated Transfer client's backed up data, and sufficient storage for said backup.
From that last section note the following about PDSs, "...or by ceasing service for specific users", and then see their documentation on PDS Entryways.
Bluesky runs many PDSs. Each PDS runs as a completely separate service in the network with its own identity. They federate with the rest of the network in the exact same manner that a non-Bluesky PDS would.
To enable this, we introduced a PDS Entryway service. This service is used to orchestrate account management across Bluesky PDSs and to provide an interface for interacting with bsky.social accounts.
What's noteworthy here is that in creating Bluesky Social, they've essentially created a model that I foresee others building on the AuthTransfer protocol emulating. Many everyday people won't be spinning up their own PDSs, in the same way that few people spin up their own fediverse instances. Essentially instead of PDS Entryways, what may emerge may be AuthTransfer Entryways/Gateways for whatever variety of apps may eventually be built on it.
Similar to different fediverse platforms, you may then eventually see AuthTransfer platforms that pair together Entryway services with an App View as Bluesky itself is presently doing. Arguably this may make the AuthTransfer network no more decentralized (they go back & forth on describing their approach as decentralized and distributed) than the ActivityPub network is.
In some cruder ways, however, these are already in play on the fediverse. Custom feeds exist here on Lemmy via different communities and instances. More topic-focused instances (on Lemmy as well as other fediverse platforms) in particular can collaboratively produce distinct local and federated/all feeds. To a limited degree similar may be said of "composable moderation" with community moderation and user/instance blocking.
Mastodon even permits the sharing of one's mute/block lists, albeit admittedly somewhat clunkily.
Altogether the AuthTransfer protocol definitely makes some interesting improvements, but not without some awkward tradeoffs that they seem to be trying to talk around instead of speaking more plainly about.
Addendum, as I wasn't sure if I was about to hit a character limit:
The idea of regular people spinning up a Personal Data Server is already pretty laughable, but it's accentuated by the idea that they might also go out of their way to pay for a domain name to sort of establish(?) their identity across the AuthTransfer network. Many will likely simply have names like around here as @name.atentryservice.tld.
Also there's a kind of weird disconnect throughout the documentation from the idea of people perhaps wanting to operate multiple handles/identities for different platforms, or different purposes on the same platforms. A lot of thought seems put into owning/maintaining a singular identity, but not as much to multiple identities.
i think it might in theory
cross-posted from: https://midwest.social/post/9006187
Over the past week or so there has been a serious spam problem hitting mastodon and rest of the fediverse especially misskey over on the japanese side of things and the story behind it is absolutely wild.
Given how Reddit now makes money by selling its data to AI companies, I was wondering how the situation is for the fediverse. Typically you can block AI crawlers using robot.txt (Verge reported about it recently: https://www.theverge.com/24067997/robots-txt-ai-text-file-web-crawlers-spiders). But this only works per domain/server, and the fediverse is about many different servers interacting with each other.
So if my kbin/lemmy or Mastodon server blocks OpenAI's crawler via robot.txt, what does that even mean when people on other servers that don't block this crawler are boosting me on Mastodon, or if I reply to their posts. I suspect unless all the servers I interact with block the same AI crawlers, I cannot prevent my posts from being used as AI training data?
cross-posted from: https://discuss.online/post/5484255
February 22, 2024 Bluesky writes:
Up until now, every user on the network used a Bluesky PDS (Personal Data Server) to host their data. We’ve already federated our own data hosting on the backend, both to help operationally scale our service, and to prove out the technical underpinnings of an openly federated network. But today we’re opening up federation for anyone else to begin connecting with the network.
The PDS, in many ways, fulfills a simple role: it hosts your account and gives you the ability to log in, it holds the signing keys for your data, and it keeps your data online and highly available. Unlike a Mastodon instance, it does not need to function as a full-fledged social media service. We wanted to make atproto data hosting—like web hosting—into a fairly simple commoditized service. The PDS’s role has been limited in scope to achieve this goal. By limiting the scope, the role of a PDS in maintaining an open and fluid data network has become all the more powerful.
We’ve packaged the PDS into a friendly distribution with an installer script that handles much of the complexity of setting up a PDS. After you set up your PDS and join the PDS Admins Discord to submit a request for your PDS to be added to the network, your PDS’s data will get routed to other services in the network (like feed generators and the Bluesky Appview) through our Relay, the firehose provider. Check out our Federation Overview for more information on how data flows through the atproto network.
With the advent of Reddit going public and selling user data an opportunity has arisen. I still consume Reddit from time to time and noticed in the threads about these things that a lot of displeased users were there. But when they ask what alternatives there are, lemmy is barely mentioned at all. So if you're still on there, this is a chance to educate others about the fediverse and alternatives.
I'm a fan of the Fediverse, but what are the major issues we faced right now because of the limitations of the #ActivityPub protocol? Recently, decentralize social networks are at their peak, big players are trying to be part of it, and is constantly in the news.
I have been on the Fediverse for quite a few years, and since alternatives were popping up I tried to learn how they work (it's not like I'm an expert, but I have a general idea), with #BlueSky opening up federation and alternatives like #nostr for what I've read, they are strong in what ActivityPub still lacks.
One thing that comes to my mind right now is how your identity is tied to the instance you are, thus making portability harder. In nostr for example, your identity is not tied to any relay, and Bluesky has domain names as username, which is pretty cool, and for what I read from Bluesky blog, it seems like portability works great since all your posts will still be in your profile. In ActivityPub (or at least in mastodon) moving an account actually means only your followers, and your handle has the instance on it, tying your account to the instance. How could this be handled? I mean, if you are self-hosting your own instance, there is no problem, but the mast majority of people do not host their own instance.
Another thing may be, quote posts. I read from one of the mastodon team they are trying to make it to the protocol instead of the "weird" implementation each software does with the URL at the end, which is a good thing since I feel like every software kind of have their own way of doing things instead of trying to make it to the protocol.
Anyway, want to listen what are your proposal to these problems and what other things you think we could learn from these other protocols. If you spot any mistake, feel free to correct me.
Follow #introduction #introductions #followfriday
Trunk — https://communitywiki.org/trunk
Fediverse — https://fediverse.info/explore/people
Fedi Directory — https://fedi.directory/
A really interesting look at the recent spam wave.
The good news is that there are some straightforward opportunities for significant short-term safety improvements. If fediverse funders, developers, businesses, and "influencers" start prioritizing investing in safety, the fediverse can turn what's currently a big weakness into a huge strategic advantage.
It's about people, not just the software and the protocol
It's also about the software
And it's about the protocol, too
Threat modeling and privacy by design can play a big role here
Design from the margins – and fund it!
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
If you want help with making a lemmy bot, then head over to [email protected]!
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.