Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Please don't post about US Politics. If you need to do this, try !politicaldiscussion@lemmy.world
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, and toxicity are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com.
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
Is there a way AskLemmy and other major communities could prevent new users from making posts in the future?
Like an account has to be over a month old to post for example. Maybe that could help prevent these kinds of disgusting attacks
I don't know if Lemmy has a moderator tool available that could do something like that though.
I don't quite like that idea. It's something I really hated on Reddit. It just discourages new people from joining. Besides, you could self host an instance with accounts claiming to be made in 1970.
Unfortunately there aren't many great options right now. No one likes it, but people posting CSAM are the ones to blame there. They quite literally ruin it for everyone because they're butthurt about something happening they didn't like
Do we know what they are butthurt about? There is never an excuse for what they are doing, but I’m curious what happened to set it off if a reason I known
Nope, they're too cowardly to use their actual accounts and are making them anonymously. All we know is that rather than being mature about a mod action and simply leaving and creating an account elsewhere they decided to do this.
Gotcha. Thanks.
Good point. I didn't think about how easy that would be to fake.
That said I would still prefer it to some subreddit's cryptic karma requirements. If it worked I mean.
And here's the spot where I point out that using a blockchain for recording accounts would be a good technological fit for a decentralized system like the Fediverse, and then get pilloried for being a "cryptobro" or whatever.
Seriously, all that you'd need to use the blockchain for would be a basic record of "this account holder has this name on that instance" and you get all sorts of unspoofable benefits from that. No tokens, no fancy authentication if you don't want it, just a distributed database that you can trust.
How would that help? A spam bot could just make lots of blockchain wallets.
what are the benefits? I struggle to come up with any benefits.
The issue that was being discussed was blocking accounts from posting if they were younger than a certain age. The blockchain has an unspoofable timestamp on its records.
I see. I'm not convinced that proving the account creation date makes much of a difference here. Obviously the instance records when you sign up, so you would only need this to protect against malicious instances. But if a spammer is manipulating their instance to allow them to spam more, you have a much bigger problem than reliably knowing their account creation date.
It's a matter of trust. A random instance can always lie and you can only determine "that was a malicious instance that was lying to me" in hindsight after it's broken that trust. Since a malicious instance-runner can spin up new instances almost as easily as creating new fake accounts you end up with a game of whack-a-mole where the malicious party can always get a few bad actions through before getting whacked. Whereas if user account creation was recorded on a blockchain you don't need to ever trust the instance in the first place. You can always know for sure that an account is X days old.
A malicious instance-runner could still spin up fresh instances and fake accounts ahead of time, but it forces them to do it X days in advance and now if they want to keep attacking they have a longer delay time on it. A community that's under attack could set the limit to 30 days, for example, and now the attacker is out of action for a full month until their next crop of fake instances is "ripe." As always with these sorts of decentralized systems there's tradeoffs and balances to be struck. The idea is to make things as hard for malicious users as possible without making it harder for the non-malicious ones in the process. Right now the cycle time for the whack-a-mole is "as fast as the attacker wants it to be" whereas with a trustworthy account age authentication layer the cycle time becomes "as slow as the target wants it to be."
Thank you for writing the explanation! I still think that this doesn't need a blockchain. Instances could broadcast user creation, so each instance could validate user age on its own (or ask other trusted instances when they first "saw" that user).
Fundamentally, blockchain solves the problem that there is no central source of trust, but in the Fediverse people necesarily trust the instance that they sign up, so a blockchain can't add much in my opinion.
This specific situation isn't about the users trusting their instance, though. This is about your instance trusting what other instances are saying. If I wanted to run a community that had a rule prohibiting accounts that were less than 30 days old from posting, and someone with an account on another instance posts there, who do I check with to find out how old that account is? The instance the account belongs to could be lying.
Having a shared database that everyone's keeping a copy of and broadcasting updates to could solve that, but there's going to be a bunch of fiddly problems you'll need to solve. If you discover that your database has differences from some other instance's database, who's "authoritative?" How do you stop it from being spammed, forcing every instance owner to maintain gigabytes of useless fake records? Once you've solved all those problems I think you'll discover that you've ended up building something that's essentially your own blockchain, since this is exactly the sort of thing that blockchains were created for in the first place. So might as well use an existing one that's done all the hard work for you. Not to mention that the more people that are using the same blockchain the more secure against tampering it gets, everybody using it contributes to its security.
More generally, there are some situations where it would be nice if you didn't have to trust your own instance either that using a blockchain to record account information would allow for. For example, you could generate and attach a public/private key pair to your account. Someone else could then look it up and use it to send you a private message that's end-to-end encrypted in a way that even the admins of your instance wouldn't be able to read or tamper with. As far as I'm aware the Fediverse doesn't have a private messaging protocol built into it at all, let alone one that's end-to-end secure. Or if your instance abruptly shuts down you could use that key to add a note pointing to your new account on some other instance, without needing the old instance runner to do anything. This sort of thing would require support to be built into Fediverse clients, it's not simple, but if the clients are well written the user doesn't need to worry about any of that complexity themselves.
Instead of preempting criticism/downvotes, perhaps it would help to more clearly describe what kind of implementation of blockchain you mean?
If it would still involve some questionable consent mechanism that either consumes a large amount of energy (Proof-of-Work) or may benefit larger stakeholders (Proof-of-Stake), then even setting aside the cryptocurrency associations, I'm not sure it's necessarily worth it. However, if I'm not mistaken, there are implementations that may not require those, but may still provide the sort of benefit you're suggesting, aren't there?
I've elaborated in some of the subsequent comments. I guess I wanted to "test the waters" a bit, if I got a strong negative reaction for simply mentioning a blockchain-based solution I would have sighed and moved on.
Proof-of-stake doesn't benefit larger stakeholders any more than it benefits smaller stakeholders, the common "rich-get-richer" objection is based on a misunderstanding of how the economics of staking actually operates. Since every staker gets rewarded in exact proportion to the size of their stake the large stakers and small stakers grow at the same relative rates. It's actually proof-of-work that has an inherent centralization pressure due to the economies of scale that come from running large mining farms.
That wasn't what I was referring to, but I should have phrased that part of my comment better. When I wrote that it may benefit larger stakeholders more what I had meant was that, by my rough understanding, larger stakeholders have more influence or sway over the consent mechanism. It's been awhile since I looked into it last, so I can't remember the details exactly, but that's what I recall of what I read.
It wasn't the rich-get-richer problem, so much as the rich-hold-outsized-influence problem. Similar but distinct.
It may be counterintuitive, but stakers don't actually have influence over the consensus mechanism. It's actually the other way around. Consider it this way; the stake that a staker puts up is a hostage that the staker is providing to the blockchain. If I stake a million dollars worth of Ether, I'm basically telling the blockchain's users "you can trust me to process blocks correctly because if I fail to do so you can destroy my million dollar stake." I have a million dollars riding on me following the blockchain's rules. That's literally why it's called a "stake."
The people who are actually "in charge" of which consensus rules are in use are the userbase as a whole, the ones who pay transaction fees and give Ether value by purchasing it from the validators. If some validators were to go rogue and create a fork that was to their liking but not to the liking of the userbase, the rogue validators would be holding worthless tokens on a blockchain that nobody is using. You can see the effects of this by the way the blockchain is continuing to update in ways that are good for the general userbase but not necessarily for the validators - MEV-burn, for example, is a proposal that would reduce the amount of money that validators could make but there's no concern that I've seen about the validators somehow "rejecting" it. If the userbase wants it the validators can't reject it without losing much more than they could hope to gain.
Ironically, proof-of-work is more vulnerable to this kind of thing. If a proof-of-work chain were to fork and a substantial majority of the validators didn't agree with the fork then they could attack it with 51% attacks. The forked chain would need to change its PoW algorithm to stop the attacks, and that would destroy all the "friendly" miners along with the attackers.
Validators in a PoS blockchain could also launch attacks at a contentious fork, but they'd burn their stake in the process whereas the validators that did what the userbase wanted would keep theirs. So there's a powerful incentive to just go along with the userbase's desires.
I’m not saying you’re wrong but why would this be the first time blockchain stopped illegal activity instead of facilitating it? It like 15 year-old tech and hasn’t made a significant impact outside of niche projects like cryptocurrencies.
To the first, there are a vast number of legal applications for blockchains.
To the second, it's not the same tech as it was 14 years ago. There have been a lot of advancements over that period.
If you trace ActivityPub's lineage back to its origin, it's 14 years old too - it started as OpenMicroBlogging in 2009. It then became OStatus, which became standardized as ActivityPub. It's barely the same thing any more. The same thing has happened with blockchains, the version of Bitcoin that launched in 2009 is nothing like the cutting-edge stuff like Ethereum is these days.
Putting aside that this use case doesn’t meet the five requisites for block chain use, the fediverse in general and Lemmy is already struggling with too much data being stored and moved.
Searching for "the five requisites for blockchain use" isn't finding anything relevant, what requisites do you mean?
This wouldn't be storing more data, it would be storing existing data. It would just be putting it somewhere that can be globally read and verified.
How do you store data in a decentralised way without have many redundant copies? The decentralisation of Blockchain is from many machines maintaining their own copy of the entire history. The entire xo dept I herebtly stores more data. Your suggestion is to literally store more data, claiming it won't store more data only suggests you don't know how blockchain works.
And that's not even including any overhead of implementing a Blockchain in the first place. Or the fact you'll be storing data on literally every user even if they never interact with your instance, pr even if their instance is entirely blocked from yours. And there's no way around that, if you do manage to selectively store some subset of users then when you do need to include that data you're trusting the subset of maintainers who do have that user's data which, initially, is only the user's home instance so we're back to square one.
Yes, my point is that that sort of thing is exactly what blockchains are for. They handle all of that already. So there's no need for Fediverse servers to reinvent all of that, they can just use existing blockchains for it.
As someone (who’s not a fan of the fediverse) put it to me:
Fediverse is web2.5, worst of both web2.0 and web3.0.
I think there’s something to that. So instilled in the fediverse’s makers is web2.0 that I’m not entirely sure their solutions can be trusted in the long term.
It makes sense that down the line, when bitcoin and crypto hype finally settles into knowing what’s actually useful, some sort of cryptographic mechanisms will become normal in decentralised tech. BlueSky may make this mainstream.
That'd be nice. Personally, I think the tech is just about ready - Ethereum has solved its environmental issues with proof-of-stake, and has solved its transaction cost issues with rollup-based "layer 2" blockchains. At this point I think the main obstacle is the knee-jerk popular reaction to anything blockchain-related as being some kind of crypto scam. I'm actually quite pleasantly surprised that I haven't been downvoted through the floor for talking about this here so perhaps there's a light at the end of the tunnel.
I personally have the knee-jerk reaction. I don't understand anything you're saying about blockchain. I've heard of farcaster (if you haven't you might be interested) and nostr (ditto) but don't know how they work.
The lack of mega downvotes, I'd guess, comes from the fact that people here appreciate the value of decentralisation and also can imagine from experience that a better system is possible than the relatively clumsy "let's just send copies and requests everywhere".
In the end I don't know. But I can see the decentralised social web being where cryptographic technology finds its mainstream landing (BlueSky, like I said, being an interesting space to watch as its the middle ground on that front).
I could try explaining in more accessible terms, if you like. I actually enjoy discussing this stuff but I don't want to derail the thread or sound like I'm evangelizing.
I think solutions like this are best handled entirely on the back end, the general user wouldn't even need to know a blockchain was involved. The blockchain would just be a data provider that the instance software is using behind the scenes to track stuff. Just like how a general user has no need to understand how the HTTPS protocol actually operates, they just point their web browser at an address and the technical details are handled behind the scenes.
If you wanna explain stuff ... go ahead! I'll read it! You may find yourself writing something that belongs in its own post (perhaps just in a technology community) which you can then link to here.
Gladly. Though bear in mind that although I'm a professional programmer, I haven't programmed anything for blockchains specifically before so my understanding is at the "very interested outsider" level. :)
Regarding proof-of-stake:
Early blockchains relied on proof-of-work as a way to ensure that the people validating them were being honest. They had proof-of-work algorithms where you had to do an enormous amount of computation to validate a block. Anyone who wanted to produce a fake block would have to do a similarly enormous amount of costly work, so you could be reasonably sure that the blockchain was secure on account of it costing way too much to break that security. This had the downside of wasting an enormous amount of electricity, though. Lots of people who hated cryptocurrency hated it because of that.
A year and a half ago, though, Ethereum switched to an entirely different system called "proof of stake." Under proof of stake you don't have to prove that you spent a lot of resources to validate a block. Instead, you put up a bunch of money (in the form of Ether) and stake it on the validity of the blocks you produce. If you produce a block that isn't valid, your staked money is taken away and destroyed. This reduced the energy usage of the Ethereum blockchain down to just the routine cost of running ordinary servers. Folks who haven't been keeping up with cryptocurrency developments often aren't aware of this, though (and Bitcoin is still running on proof-of-work, which doesn't help. But Bitcoin has fallen way behind other modern cryptocurrencies in a lot of ways, IMO it's surviving purely on name recognition at this point).
Regarding "layer 2":
Every blockchain from Bitcoin onward has faced something called the "blockchain trilemma." Security, capacity, and decentralization: pick any two. Security means "how much can you trust the data that's on the blockchain to be correct?" Capacity is "how many updates to that data can be done per second?" And decentralization is "how much can the blockchain's management be spread out among independent users?"
If you do something that increases one of those three aspects then it necessarily requires decreasing one or both of the other two; it's impossible to increase all three of them. This trilemma is kind of like a law of physics in computing science, anyone who says they can break it should be treated a bit like someone claiming they've invented a perpetual motion machine.
Since we've long had stuff that sacrificed decentralization for capacity (credit card companies, for example, processes thousands of transactions per second but it does so by running everything themselves) blockchains have focused on boosting security and decentralization. As a result, blockchains had a low transaction capacity - sometimes just a few transactions per second. When there's a low supply of something then high demand means its price shoots up, so whenever a blockchain got popular its transaction fees would go through the roof and it would lose a lot of usefulness (other than market speculation on its price). Blockchains with low transaction fees were either not being used for much in the first place or were compromising on their security or decentralization to accomplish it.
Ethereum has come up with a mechanism that doesn't exactly break the trilemma, but sidesteps it. The main Ethereum blockchain remains devoted to having high levels of security and decentralization, but it's been updated to support a new type of transaction called a "rollup." You can think of a rollup as being a summary of a whole bunch of other transactions that happened on a parallel chain. If you and I were to be exchanging tokens back and forth between us a whole bunch, for example, we wouldn't need to post all of those transactions directly onto the Ethereum blockchain. Every once in a while we could just post a rollup that tells the main blockchain "since the last update FaceDeer has given a net total of 0.1 FaceCoins to maegul and maegul has given a net total of 28 MaeGold to FaceDeer". There's a bunch of fancy cryptography going on with rollups that allows the main chain to validate that this is legit without having to know all the details of how it happened. The rollups "inherit" Ethereum's security and decentralization through this mechanism. Since rollups are acting like a kind of secondary blockchain that's sitting on top of the foundational blockchain, they're referred to as "layer 2."
So that means that although Ethereum transactions are still expensive, you can cram an almost arbitrary amount of activity into each one. That can make rollup transactions cheap enough that an instance owner would only need a couple of dollars' worth of Ether per month to support their instance's use of the blockchain to record data, which would likely be a lot less than their electricity bill or bandwidth costs
Ran out of characters in this response. Hope that was helpful/interesting. :)
Thanks!!
Thanks!
FWIW, I was vaguely aware of ethereum’s movement to proof of stake. But not very aware! Thanks!!
No problem. I split my comment in two because I ran into the 5000 character limit, BTW, in case you didn't see the other half.
Are new instances automatically federated? If not, then it seems like making an instance, then hosting content enough to be federated, would be an awful waste of time and money, as I'd expect an instance like that would be quickly defederated.
Somewhat. All the communities have to be looked up manually by users, and followed to continue federating the content into that instance.
But for this purpose the answer is yes. At least as far as I know, you can immediately start posting to other instances. Otherwise private instances would be of no use.
I don't like it either. Age/karma requirements work under an inherently flawed idea, that you're guilty (i.e. a shitposter) unless proved contrariwise (by using an old or karma-ful enough account), and damn easy to avoid if you're determined to shit on a community.
IMO better ideas revolve around
Sadly they all depend on the software, and Lemmy isn't exactly known for having good mod tools.
Just the IP bans don't sound good. CG-NAT, VPNs, public networks, school networks, etc.. makes a lot of people share the same IP.
I'm aware that IP bans inconvenience users who did nothing wrong. But I feel like this can be alleviated:
But... well, we're back into "lemmy needs better built-in mod tools" territory.
Then hosts need to ban VPNs.
They need to use cookies that attach a unique identifier to each machine to enforce bans per machine. Hash the cookie so it can't be edited. If a user clears their cookies, they need to put in a special private key to get back into their account.
Or just make users scan in ID or pay with a credit card to gain membership.
None of those ideas are perfect but they are needed for better ban enforcement overall anyway.
What about new users and new instances requiring manual approval for posts?
Maybe. Some discussion going on at the moment about how to handle it.
Understood. Is that an option for moderators though?
Like I said I don't know if Lemmy gives you that option or if you'd need to setup some kind of bot or an instance level option.
That would need to be a bot. The problem is that the spammer would just move on to the next community (which they have just done by moving to askLemmy@lemmy.ml I just put a tool up that automatically notifies a bunch of admins, mods and community team members when a post get's reported more than 3 times, so please report the posts if you see them.
That's smart. Glad to hear something like that exists
Preventing any posting in general might be a bit too restrictive IMO. However I think new users, or users using VPNs probably should not be allowed to post images in general so freely.
I believe lemm.ee has a minimum account age limit before users can upload directly to the instance, and dbzer0 scans all user uploaded images for anything that could be questionable.
Perhaps there should be additional restrictions on stuff linking to images outside of lemmy? I blocked the domain within moments of it appearing on my feed, absolutely disgusting
You'd have to generate a blacklist and maintain it, but also avoid bad faith mods and admins
i thought dbzer0 already had a tool for this