Pretty much in the title. Maybe you wouldn’t even use it, but would like to simply see it exist for the sake of having a federated alternative.

For me, it’d be the following:

  • LinkedIn
  • Meetup
  • Tiktok

I am on the first two, but would prefer a federated alternative. I’m not on Tiktok, but would like to see a federated alternative.

I’ll admit these might not be a good idea. But as a thought experiment, I’d be curious about the community weigh in on what you all think this might look like.

  • I Cast Fist
    2•5 months ago

    That’s useful for “real life” data, so to speak, stuff that should be immutable, save for a few occasions, like correcting errors; but my question was geared towards internet content. Taking your example of Wikipedia, if the service suffers from a wave of trolls, as it exists today, it can roll back the changes. With a blockchain? That’s significantly harder, especially if useful edits happened in the meantime.

    There’s also this problem:

    you don’t have to store the data itself on the chain, the chain data can just “point to” off-chain data which you can take down or modify at will.

    Supposing this Wiki doesn’t store any of the content, then the endpoints become the targets, which beats the whole purpose of the blockchain resilience/immutability. An endpoint that can’t be reached is useless, one that has been compromised is even worse. You can trust the blockchain, but not the endpoint. And if the endpoint is where the “real stuff” is at anyway, why even bother with a blockchain?

    • @[email protected]English
      3•5 months ago

      Taking your example of Wikipedia, if the service suffers from a wave of trolls, as it exists today, it can roll back the changes. With a blockchain? That’s significantly harder, especially if useful edits happened in the meantime.

      I’m not convinced we need a Wikipedia that runs on blockchain, but for the sake of it being an interesting question, I’ll answer it. Firstly, having a revision history is not bad. If you go to any wikipedia page, you can see most of the edits made, even those made by trolls, and the moderation decisions around those edits. This is good for transparency. When a user visits wikipedia, they see the “authoritative version” of that page, but the revision history is available to them if they want to read it. So with blockchain, you can roll back changes by changing which set of data is the “authoritative version” and you can have revision history, they are both important features.

      There are a few types of data that are so harmful we can’t have them, even in the revision history. For this kind of problem, we reduce immutability (as referenced before by using pointers instead of storing data on-chain), or we can prevent that data from being put into the chain in the first place. An example of a way to do this is to require that every new block (every revision to a wikipedia page) be approved by a set of users who have reputation >x. Maybe that means a moderator has to sign off, or 10 regular users with at least one approved edit, you can set the threshold however you like and assign reputation however you’d like. As a user’s reputation is recorded on the blockchain, any node can easily verify their reputation amount.

      Supposing this Wiki doesn’t store any of the content, then the endpoints become the targets, which beats the whole purpose of the blockchain resilience/immutability. An endpoint that can’t be reached is useless, one that has been compromised is even worse. You can trust the blockchain, but not the endpoint. And if the endpoint is where the “real stuff” is at anyway, why even bother with a blockchain?

      The purpose of the blockchain in this wikipedia example is to:

      • Establish a single authoritative version of wikipedia that the entire globe can see and submit edits to (unlike a federated version where you have multiple versions of wikipedia hosted different places). This is “single authoritative copy administered by people you can’t trust to be good actors” is the essential problem blockchain solves.
      • Censorship resistance or resistance to “attackers” may not be an important thing for a wikipedia clone. Resistance to attack depends on your threat model, who the attackers are, what kind of resources they have, how you can resist those attacks, etc. Right now, Wikipedia is a single centralized entity and has done quite a good job at resisting attacks aimed to force them to make editorial decisions they don’t want to (mostly because of their reliance on the protections provided by the US legal system. If that system collapsed for some reason, their attack resistance might drop significantly). So if we clone wikipedia and make it decentralized, I think one could increase that security, but I’m not convinced that’s needed in the first place.
      • It doesn’t matter if the data is ultimately stored at some endpoint, the blockchain is less about storage of data and more about arranging the data in order and establishing a single authoritative copy. It’s the medium through with users administer the data.
      • “You can’t trust the endpoint”, this is true but maybe not in a way that matters. It’s true that the endpoint can send you bad information, but you can verify if the information is good or bad based on a cryptographic hash from the blockchain. Endpoints can have a reputational score on-chain and if they aren’t doing their job properly, they can cease being used as an endpoint at all. There could be multiple endpoints for any given piece of data for redundancy and to protect against a scenario where an end point, maliciously or not, becomes unreliable. Also, there are decentralized data storage options out there with varying degrees of usefulness for this application: torrents, IPFS, Filecoin, jstor, etc.