Thank you for laying it all out there. It sounds like you’re doing it the right way 🙂
Well I didn’t want to have a bio, but Lemmy doesn’t let me null it out, so I guess I’ll figure out something to put here later.
Thank you for laying it all out there. It sounds like you’re doing it the right way 🙂
Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.
It’s kind of interesting to watch in open source which projects survive and which get forked and essentially made irrelevant. It basically becomes a referendum on the vision of the original individual or team and how well they’re serving the collective user base. If they aren’t accepting PR’s and competently managing development, they’ll likely be forked. So I’m glad to see that folks are making progress with mbin and I can’t help thinking that its entire existence is probably due to individuals not being able to agree on a roadmap for the platform. If anybody has any info on any drama that led to this, I’d be curious to read about it.
Who is Dream and, more particularly, what’s the connection to those sneakers?
I see, well I guess the real question is whether it can be improved at the server/protocol level and my answer is I don’t know. There’s some handshaking that clearly has to occur between your instance and the other instance to load the initial community state and I don’t know where that process can be optimized. I think I’ve seen people mention tools that have been created to automatically subscribe a dummy account on your instance to all the communities on the largest instances to kind of bootstrap the process for other users, but I don’t have a link to such a tool handy.
Edit, and there’s never going to be a guarantee that your server can talk to their server until you try clicking the link because the other server could be overloaded, down, or blocking your server.
What you’ve described is exactly how it’s supposed to work. Once a user has subscribed to an external community from your instance, it should load immediately for any users afterwards.
Why not? Plasma is much more usable out of the box for many users including myself. GNOME’s out of the box experience is really lacking IMHO and requires me to install and configure several extensions just to get what I consider to be a functional UI. I know they have this vision for how they want people to use their OS, but that vision is not aligned with how I actually want to use it. The best way distros can vote against the design choices of GNOME is by making something else the default. The problem I have is that I generally prefer GNOME’s app suite to KDE’s, so that makes the decision a bit more complicated for me.
Personally, I think it’d be nice if you could self-host just the bridge instances and connect them with beeper yourself, so that the part that isn’t e2e encrypted is running on software you can validate and hardware you control.
I 100% agree this would be a great solution. That’s what I thought this page was going to be at first until I kept reading and realized it’s just a config guide for the Matrix Ansible setup. I wish they didn’t say “self host Beeper” on that page at all because self hosting Matrix has absolutely nothing to do with the Beeper service other than their devs built the bridges that they’re showing you how to set up with Matrix.
Beeper’s server set up is actually a lot more complicated than just standard Synapse at this point. When they say you can “self host Beeper” that’s really not accurate at this point at all. All of their 3rd party chat bridges are dynamically spun up on a per user basis with hungryserv and those servers operate in parallel with a synapse server for Matrix interoperability all behind a roomserv server. Here’s a presentation that one of their lead developers created regarding their new architecture.
What do you mean by nefarious exactly? I don’t get the impression that it’s evil…
I’m honestly trying to figure out how the hell Meta is going to make money on this venture. The genie is out of the bottle for the Fediverse. If they try to show ads on Threads, people will presumably just get an account on a Mastodon instance and follow who they want from Threads…
Are you installing from scratch, docker, or Ansible? I know in Ansible the default nginx config has been wrong for a week or so, but just got fixed this morning.
TOTP support will be coming very soon: https://github.com/liftoff-app/liftoff/pull/56
Still needs to be reviewed, but keep tracking this over the next couple days.
I’m hoping the Fediverse unites behind the Fuck Meta position. Not just no, but Hell no.
deleted by creator