Comment on Plebbit is a peer-to-peer Reddit alternative that allows you to self host and own your own community

• sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨month⁩ ago

  Right, plebbit seems to use ENS to connect a name to a place. If the name doesn’t point to a place but instead a distributed collection of posts, you don’t need a domain name system.

  just use a database

  A DHT is a distributed key value database. I’m modeling everything in terms of structured keys using existing data structures.

  Moderation is the hardest nut here to crack, and that’s pretty much the entire point of this experiment: can I build a distributed trust system? I’ve read a few papers on approaches that could work, and this transitive trust system should do okay. The idea is that I trust user A by X%, A trusts B by Y%, so I should trust B by something less than both X% and Y%. To get a decent result, I need enough data to make it work well, but not so much that computation is slow.

  I think it’s feasible. If it works, we don’t need centralized moderation, which solves a ton of problems in current social media networks.

  source

  • Boomkop3@reddthat.com ⁨1⁩ ⁨month⁩ ago

    Note: we don’t have centralized moderation here either. We’re talking in two completely different instances. Just like plebbit would have

    source

    • sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨month⁩ ago

      It’s still centralized in the sense that there are specific individuals who have moderation power. If you think of each instance as a so separate thing altogether, it’s the same as Reddit.

      source

      • Boomkop3@reddthat.com ⁨1⁩ ⁨month⁩ ago

        I’m on reddthat.com and you’re on sh.itjust.works. These individual instances have their own moderation setups. There’s no central or overarching system here. We’re on two seperate websites. That’s the idea, a bit oversimplified.

        But yes, you could go local only, but wouldn’t that kind of defeat the point? I want to be able to switch instances, and talk to friends on other ones. That decentralization brings the huge benefit of not having a u/spez situation

        source

        • -> View More Comments
  • Boomkop3@reddthat.com ⁨1⁩ ⁨month⁩ ago

    No, it does not “seem”, it explicitly states.

    A hash table is a way of storing data, I suppose you could call it a very primitive database. But that’s not the common usage of the word database. Hash tables are used in database indexes, hence why I called it “reinventing the wheel”.

    The naming system is still a central part of any network, even if decentralized in design. So it will need some sort or central moderation.

    One issue with ens though, is that the control over it is more centralized than dns. But without regulation, it’s worse than the existing solution.

    source

    • sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨month⁩ ago

      it does not “seem”

      I haven’t used the service or reviewed the code, I’ve only read the whitepaper and read the website. Early stage projects like this have a habit of stating this things that aren’t yet true, hence the uncertainty.

      Hash tables are used in database indexes

      It sounds like you’re limiting your definition of “database” to relationship databases, there are a lot of other types of databases out there. The most common use case for Redis, for example, is as a key value store, and a hash table would be a perfect way to implement that. I’ve used redb in this project, which is a disk based key value database.

      The naming system is still a central part of any network

      Sure, but DNS systems are authoritative, meaning there’s only one right answer to a given query. This requires synchronization across the network, which creates a ton of complexity.

      If we can avoid that synchronization, the design gets a lot simpler, which makes it more robust. In my design, I’m specifically avoiding mandatory deletes and updates, so the only operations my “database” needs to support are creates and reads. Communities are just topics you can post to, and moderation is just client-side filtering. The tricky part is getting the client side filtering good enough to not give spammers and trolls too much visibility.

      Some nice parts about this:

      • users can leave the network, create posts and comments, and later sync up when they rejoin
      • air gapped networks can still sync transparently through sneakernet (i.e. sneaking content behind national firewalls)
      • any portion of the userbase could leave and the network in unaffected (no dead communities)
      • content lives as long as someone cares to store it since no users can delete anything, while unpopular content goes away

      source

      • Boomkop3@reddthat.com ⁨1⁩ ⁨month⁩ ago

        Let’s hope it’s not true yet or ever. Did you mean relational? And no, that’s not what I said.

        The current dns system works, and has it’s flaws. But ens is not an improvement, it’s worse.

        source

        • -> View More Comments