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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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
Decreasing the surface of attack. In this case: only text posts allowed, there’s barely any legitimate reason to allow image posts here anyway.
Proper tools so mods can upstream rule violation to the admins. I’m almost certain that admins can see the IP of the posters, they should use that info to ban the posters alongside it. Perhaps in some situations the mods could even be granted temporary rights to see the IP of the posters? (Just an idea.)
Proper tools so mods have an easier time spotting potentially problematic content.
Sadly they all depend on the software, and Lemmy isn’t exactly known for having good mod tools.
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.
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.
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.
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.
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).
deleted by creator
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?