Russ

Just to chime in with my own opinion on JetBrains’ tooling, my first language was Java - admittedly its been a while since I tried Java (and other JVM languages like Kotlin) in VSCode but when I last did it was a bit of a challenge. I also did some Android development for a while and if “standalone” Java was awkward in VSCode I assume Android development would have been too (Android development in general was nightmare fuel until Android Studio came along, never really did like Eclipse all that much).

After expanding out into other languages, I have enjoyed the specialization of each of the JetBrains IDEs. VSCode always felt like a “Jack of all trades, master of none” type of experience for me personally. I have tried out Zed recently and while I think its going to be a decent editor, I still have similar issues with it that I have in VSCode (in that how well it works depends on what language you’re using).

The exception to their tooling that I haven’t really liked though is Fleet - which was their answer to creating an equivalent to VSCode. It hasn’t really seen a lot of development and feels more like the forgotten step child of JetBrains. Also the “Remote Development”/JetBrains Gateway features can be really hit or miss though thankfully I don’t need that sort of functionality often.

Subscribed from bitforged.social, thank you!

The p2p meshnet that they were referring to basically is a local/small group ISP.

As for why a single person cannot (effectively) become their own ISP? It’s complicated. Really complicated. ISPs have to pay other ISPs just like you and I do, unless they’re a Tier-1 ISP/Network. Otherwise you’re always going to be paying to connect to (and generally paying for bandwidth) another network that has access to a network that then has access to a T1 network. T1s are basically the largest networks that hold (or can directly access) the majority of people on the internet. Top of the food chain, so to speak.

So in theory, yeah, you can become your own ISP - but you’ll still need to pay and be at the mercy of other ISPs. Datacenters are typically their own ISP, but they have to pay others to get online just like we do.

I always assumed it was more or less targeting the federation of issues/MRs.

The git side of things is already distributed as you said, but if you decide to host your random project on your own GitLab instance you’ll miss out on people submitting issues/MRs because they won’t want to sign up for an account on your random instance (or sign in with another IdP).

This is where a lot of the reliance of GitHub comes from, in my opinion.

According to another user in here, blocking on Mastodon actually works. So seems like it is possible to do in the Fediverse.

I was not aware of this, but their implementation of how they do this does bring up the limitation I mentioned. The other user cannot see your posts only if you are on the same server:

If you and the blocked user are on the same server, the blocked user will not be able to view your posts on your profile while logged in.

I actually thought blocks were public already.

They’re not, well - the operator of your instance could go into the database and view it that way in the same way that they can see your email address. But aside from someone who has database access to your instance, blocks are not public. What is public is the list of defederated (“blocked” so to speak) instances for an entire instance (this can be viewed by going to /instances of any instance), which might be what you were thinking of?

And personally I don’t see how it would be an issue if people that I haven’t blocked can see who I’ve blocked.

How exactly would you enforce that, though? If your blocks were public, all the person who you’ve blocked would need to do is open a private browsing window and look at your profile to see that they’ve been blocked.

If we’re looking at blocks as being a safety feature, I would think that having your blocks broadcasted to every single instance would be classified as harmful and a breach of your privacy. This is why although an instance that you register with has to have your email address that you signed up with, they don’t broadcast it to all other instances (same with the encrypted value of your password) - because otherwise it would effectively be public.

Perhaps I’ve just got the wrong stance, but considering that you can never block someone from viewing your content with an absolute guarantee (if the blocks were broadcasted, you still couldn’t prevent someone from just simply logging out, or standing up their own instance and collecting the data anyways) I would not consider that tradeoff to be worthwhile. Not that my stance has any weight since I’m not a maintainer for Lemmy (or any of the Fediverse software), but I wouldn’t be surprised if that has at least come up to those who are developing the various Fediverse software.

Aside from the rest of the discussion that has already occurred here, I’m not actually sure how this would work from a technical perspective.

You and I are on two completely different instances, if I were to block you, how is your instance supposed to know this in order to stop you from reading my comment?

The only way I could see that working is if the list of users you blocked were federated too, and effectively made public (like votes currently are) - which seems counterproductive to the problem at hand.

Then what happens if you post in a community where someone you’ve blocked is a moderator? Or if you block the admin of another instance? If you can “cloak” yourself from being moderated by just blocking them, that seems like an exploit waiting to happen. As far as I’m aware, on Reddit blocking a user doesn’t hide your comments from them - but they can no longer reply to them, and I assume this is why that is the case. Unless that has very recently changed.

The biggest difference between Lemmy (and all software within the Fediverse - for example, I’m pretty sure Mastodon is this way as well), is that there is not one singular authoritative server. Actions like this need to be handled on all instances, and that’s impossible to guarantee. A bad actor running an instance could just rip out the function that handles this, and then it’s moot. I mean, they wouldn’t even need to do that - they’d have the data anyways.

You could enforce it if both users are on the same instance I suppose, but this just seems like it would only land with the blocking feature being even more inconsistent.