At least you got yourself into the contributing mindset. Tackle the next issue!

Wikipedia is a good example. It is annoying when they ask for the $3 every year, but it's true that a small contribution like that across the many users can keep a free/libre project sustained. Things like Usenet used to be part of your ISP bill anyhow, so a small monthly/annual amount to your instance host makes sense to me. Of course, we pay ridiculous amounts to our ISPs without services like this nowadays, so it does hurt a little

Sorry, I should have included that info. You got me thinking, however, and I made the decision to defederate from lemmynsfw.com. I'm not against the communities it hosts, but I don't want to deal with any of the content hosting legal questions that come with it (or at least minimize it where I can). There do appear to be some posts that make it in to the 'random' microblog section that are NSFW, I will look into what I can do for those.

Good idea, I just looked however and they've changed the instances page to: https://fedidb.org/software/kbin. So any server that has federated with any other listed is on there, I believe. More Kbin instances out there than I thought!

There are ways to write links in such a way that they should keep you on your instance, but I'm not too familiar with them. I wonder if it would be possible to "precheck" links that load on a page, and if any point to content that can be federated, kick off the process of pulling that content in. Then when the user clicks that link, it would take them to the content on their home instance, where they can interact. That way users wouldn't need to deal with formatting links a certain way, it would just happen automatically (if your home instance software supports it).

Thanks for the great work on this @ernest, and every contributor who's dove in and made a PR.

Very true, if you don't mind losing your post history. A simple way to migrate subscriptions would be great for those folks that make a new account every once in awhile anyway.

That might be android only, I'm not sure. I remember seeing a pull request about it having to do with something in the PWA manifest.

Thanks for reminding me of that! I haven't been around since the old old forum days, but from my time on Minecraft server Enjin forums, I definitely remember arguments going on, outside of the main discussion, and every once in awhile you'd get a 'settle down you two' from someone. The tree format kind of takes the 'one big room, many conversations going on' vibe away.

On Lemmy that is. Kbin I believe replicates everything (unless I set my server up wrong). My server at the moment pulls in around 1.5 GB a day it seems. There is a pull request open on the kbin git repo for a feature to auto-remove old media. Personally I'd like the ability to turn on/off media replication. If an instance wants a complete copy in case of defederation/disconnection somehow, they can opt in and mirror all media that comes in. Most servers should just link to the original image source on the originating instance though.

It's not, unfortunately. The main issue I see with implementing that is all of your existing posts/comments would still link to your old account on other instances. So either your old instance would have to forward requests for your account to the new instance, or maybe ActivityPub has some way to push that update out and update your account's home across the fediverse. I don't know enough about it unfortunately.

You are welcome to create multiple accounts in any case. Suppose that defeats the purpose of the fediverse though.

Well said, thanks for this info! I was in the camp of thinking "of course the money goes to Wikipedia's upkeep" but I never examined it closely enough.

That's a good breakdown, thanks! The bad thing is that I could see these issues happening even unintentionally, with the fact that we have a few large instances vs. many smaller ones. So far we seem to have everyone running the same code, straight from the repositories (at least functionality wise). For my own kbin instance though, I have technically changed things. I changed some code to make a custom logo appear nicely, I've added some padding here and there, etc. I have also thought about implementing an automatic job that clears posts tagged with 'nsfw' or other related things in the microblog feed.

I might implement that, and then submit it to the kbin devs if it works well. There's no guarantee that other admins/devs would do that as well. If they implement a feature that makes their community more popular, they would seem to have incentive to keep it private. And that's where stuff like Meta comes in. If they implement rigorous content filtering, I doubt that would make it into the actual AP protocol. It would be the differentiating factor between using their 'safe' instance, vs. going rugged on an independent instance.

They could say "we implement the ActivityPub protocol as specified" and they wouldn't be wrong. They would just have some extras added onto the top to make their experience more polished. Easy to do when you are a for-profit and have plenty of devs. They would just argue that those are the features that make their interface different, like kbin and lemmy are different.

The only way around it is for communities to agree that they will run the software as released, maybe with only cosmetic changes. Any improvements to functionality should be submitted to the devs so that the wider community can benefit.

That's the one--thanks!

That'll be slick!

Bummer. Yeah, I think kbin.social hasn't gotten those changes added in yet. I've just been pulling the new updates once/twice a day onto my instance. It has broken things a couple times though so I get why the larger instances are waiting for actual 'releases' of kbin.

This is the problem we are having with fast growth on a few select communities. The largest servers are being bogged down simply because the software has not been tuned for these large types of instances yet. ActivityPub works best (in it's current state) by spreading users over smaller/medium sized instances. Folks need to take a look at other instances (and I agree it is hard to find them for a newcomer). You can look at https://fedidb.org/ to look at instances that have been indexed running kbin, lemmy, and other software.

Joining a smaller instance means that your server is not being bogged down by tens of thousands of other users trying to pull updates at the same time. You can still see the content from other instances, and in many cases it is more reliable because your smaller instance actually has the resources to handle pulling in the posts you want to see. In the future I am sure instances like lemmy.world will be able to handle the traffic smoothly, but for now the best way to ensure stability is to join a smaller instance.

(Plug for my instance: https://remy.city, a general purpose Kbin instance. I set it up for personal use but anyone is free to join me in using it. I have defederated from the more alt-right communities like lemmygrad and exploding-heads, and from lemmynsfw.com because of content hosting concerns. I'm open to suggestions on others.)

Good point. Nothing against the larger instance owners of course. If my little instance got super popular somehow (like being recommended in guides on how to join lemmy/kbin), and thousands of users got in per day, I could see issues happening just like this. I don't know the ins and outs of tuning this software for performance at scale, and I know I couldn't learn it fast enough if my instance faced very fast growth like lemmy.world has.

I think admins are going to need to turn registrations off periodically, as they scale their hardware (and their knowledge) to run it for more users effectively.

That's something I want to get into. I want to set up that self hosted software, forget what it's called, but you can integrate with IoT devices just like you can with a mainstream assistant service like Google Home.

What I really want to do is automate my blinds, which are the chain loop type, so I can say "house, open the living room blinds" like they did in Smart House, the Disney channel original movie (or maybe that was Home Alone 4, but we don't talk about that one). I found a little motorized device that integrates with these chain blinds but it was a bit pricey. Of course if I tried to make it with my own Arduino etc it would be an ugly mess.

Don't they know not to use the window-git AUR package? It's a development build and could be unstable/unsafe.

The problem is that if I want to communicate with Meta users, then my content gets copied onto Meta's servers, just because of how the fediverse works. Everything is a local copy first, then gets federated. So if I reply to someone who is a Meta user, in order for them to see my comment it must get copied to Meta servers. The only way to stop this is to defederate with them (which means the server you are on would not send anything to Meta servers).

In your browser, if you go into the menu there should be something like 'Install', 'Add to Homescreen', something like that.

On chrome it is add to homescreen, but there is also a pop-up at the bottom that gives an install button. The browser menu should be the easiest spot though.

It creates a shortcut on your homescreen and allows the site to run in full screen mode, so it acts like a native app.

Wow, similar thing for me, I have a 'bicuspid aortic valve's which means the aortic valve in my heart is a bit funky and doesn't push blood through as it should. And that makes the FAA also seem me medically unfit. I think there is a process to get a medical exemption, but with the cost of getting a license so high already, I just decided to stick with MSFS. I get to 'fly' a 737 like I wanted as a kid, learn all about it, but I'm not shelling out thousands and years of my life (okay, maybe I am shelling out some money but I like pretty airports!)

A community can be made of very few people. It just takes a desire to keep it going!

The thing about federation is that every server basically copies any content that the users on it want to see. So if a comment/post is made on lemmy.world, lemmy.world sends out an update to every other server on which a user is subscribed to the thread/community/user. So each instance that has a subscribed user ends up having to process the new comment/post. If a Meta community came in with say, a million users, now every instance has to process the comments for all those users (that is, if folks on those instances want to see that Meta content).

It is a bit inefficient, but it's just the way a decentralized network has to function. I could see many people thinking that any time you open a thread, the data comes in from the originating instance, i.e. that your home instance doesn't store the data you are viewing. It is unfortunately, and I think it will be a problem in the future as communities grow.

I want to get into ham radio. Just like the fediverse, it's decentralized, and it's the original way to chat across the globe!

Looks like that's been fixed actually (if your instance is up to date enough, that was merged in 5 hours ago). I had to reinstall the PWA for it to take effect.

I think that would be worth it, yeah. Of course if you are hosting it on your home network there will be some added security concerns (and that might make it better to only allow signups to friends/friends of friends/etc). The way I see it is that some instances are going to host the largest communities, and therefore those instances are going to need to handle all of the incoming/outgoing updates to posts in those communities. Right now they can't do that reliably and push updates out to all of their users' devices.

So in the long run I think having small/medium instances (say a couple hundred, not tens of thousands of users) will be the way to grow. These smaller communities can push updates to their smaller user count reliably, and then have more resources to handle federated content coming in and going out. I think scaling for the incoming/outgoing federation requests would be easier than for direct user activity. Federation stuff can be queued and then spread over time, but user requests cannot be.

I'm in the process of getting those working--I've had some issues with the captcha plugin so far.