BadAtNames
I have worked on non-trivial (aka took 10-12 people over a year to even deliver an alpha) greenfield projects, where I literally made the first check-in into the repo.
The only 500+ line PRs I raised was auto generated boilerplate code, or renaming something.
I don’t understand the optimism of devs who spend weeks writing code without bothering to test anything they’ve written. Unless you’re writing utterly trivial BS, how does one have this level of confidence in their code? And if you did bother to stop and test, why on god’s green earth would you not raise a PR? Why wait till you have thousands of lines of code before asking for feedback?
No. It depends on their home instance.
A few may go out of their way to make it easy - there is nothing stopping a Lemmy instance from requiring government ID to sign up, after all. A few may go out of their way to make it hard - there is nothing forcing a Lemmy instance to collect any data about a user. Most big instances will probably be at the same level of difficulty as tracing someone from their email address - their servers are probably logging IPs and locations, which will be a starting point for tracing identities, but not guaranteed to be “easy” by any means.
Lemmy does not have anonymous voting - https://lemmy.eus/post/182574
Each instance decides what to show on its homepage and its own moderation rules, so you are free to build (or find, if one already exists) an instance that attempts to prevent the kind of manipulation you are worried about.
Bengali daal - a thin lentil soup, served over rice. Rice and dried lentils are one of the cheapest things you can buy in my country (& probably worldwide) - and this recipe uses very limited ingredients. The spices it uses - Indian bay leaf and kalo jeera - are not expensive in Bengal, and pretty basic/versatile, used in all sorts of dishes. But they’re also optional - only daal, salt, water and green chillies are mandatory for making a decent daal!
I think it’s not helped by the fact that most early adopters are “techies” who enjoy talking about the underlying tech.
The average user doesn’t really need to understand this whole fediverse thing to sign up and use Lemmy. We could just have a website with a big sign up button that randomly (to load balance) selects an instance from a whitelist and signs the user up there to get them started. But instead we have GitHub docs with detailed comparisons of various instances, and long discussions about underlying protocols and what the federation means and how that’s different from centralized platforms.
I think the original analogy works better.
If an EU country goes rogue, other EU nations can’t just isolate it and bar it’s citizens from entry. There is no expulsion from the EU AFAIK. But Lemmy instances can block another instance fairly easily and unilaterally - like how nations can refuse visa to citizens of a rogue nation. And Lemmy instanced are expected to federate with most other instances, just like countries are expected to grant visas to most other countries - unlike joining the EU, which is a whole big process and all EU members have to agree (there are no vetoes in Lemmy federation).
But most importantly, the EU members are required to act as one in many circumstances - most laws apply across all EU members, EU negotiates trade deals as a block, etc. That is not true for Lemmy instances. Each is completely independent and makes its own laws - and must only comply with some very loose principles (which boil down to “don’t be a total jerk”) to not be isolated from other instances. This is much closer to the kind of independence countries have, than EU members.
I feel like people are overcomplicating this (& it doesn’t help that most early adopters are techies, who enjoy talking about things like federation protocols)
One doesn’t need to understand the Fediverse in order to use it. That’s like trying to understand the mechanisms of internal combustion engine because I want to drive a car. I mean, that is fun and there are not-too-esoteric scenarios where the knowledge might even be helpful, but it sure as hell isn’t necessary!
Migration was a breeze once I stopped worrying about the internal combustion engine.
You’re on the lemmy.world instance, so you can reach the admins by emailing info@lemmy.world, or posting in the support forum !support@lemmy.world
Now to answer whether there’s a difference between being promoted and doing it yourself - In this case, it’s suspected that session tokens were compromised. You know how when you enter some events, they vet you/your ticket once at the door and then put a stamp on your hand? If you go out and want to get back in, you don’t have to do the whole verification song and dance again, just show them your stamp? Well, that’s pretty much what a session token is - Lemmy vets your password once when you log in, and gives an unique session token to whatever browser or app you used to log in. That way, when you reopen Lemmy, you don’t have to enter your password again.
Now that token is compromised, you have to assume a hacker has your unique token. When you logged yourself back in, Lemmy did the whole validation process again and gave your browser/app a new, unique session token - that’s just how logging in works. But the important question is, did it invalidate the old session token when you logged out? Otherwise the hacker can still show the old token and pretend to be you.
Now if your browser/app prompted you to log-in today, you can be sure that your browser/app tried to get into Lemmy and was denied access. That means you can be sure your old stamp/token is now invalid. Logging out and in yourself doesn’t give you the same guarantee - you will have to check Lemmy code (or run some experiments) to know if logout does actually invalidate the old token. I haven’t validated Lemmy’s code, but I will say most half decent software will invalidate your token when you log out. If you want an extra layer of protection, change your password as well - even the software devs that forget to invalidate tokens on logout usually remember to invalidate them on password changes.
Ya, I mean Instagram is no bastion of privacy, I’m sure - but most managers wouldn’t be thrilled to learn their employees were accessing the production database for fun. It’s less a “but you violated our customer’s trust” and more a “you idiot, why you tempting fate, we are generally one typo away from the whole thing crumbling down anyway!”. And surely no company bothered to build a nice tool that’ll let their employees peruse the DM list of a random user - we can barely get them to build us actual monitoring infrastructure till something breaks! So one would have to put in some effort into gathering this information. Running background checks for some random friend - the risks and effort doesn’t feel like it would be worth it. It seems more likely the girlfriend peeked at OP’s Instagram client herself, or just took a guess, and made up “a source working at Instagram” as a plausible excuse.