Mama told me not to come.

She said, that ain’t the way to have fun.

  • 0 Posts
  • 7 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle


  • Exactly, and this is my main complaint about Lemmy and Mastodon, they’ve prioritized resiliency of the network but not resiliency of user data. If an instance goes down, all communities hosted there are frozen in time, so I’m not getting updates from other community members from different instances. The platform is decentralized, but the data isn’t.

    Plebbit looks to be similar, but at the community level instead of an entire instance. I don’t know what happens if a community owner disappears, but I imagine it’s similar to Lemmy.

    They day they’re not using DHT

    I thought they’re using IPFS, which I believe uses a DHT under the hood.

    I’m working on my own P2P reddit alternative, and I’m using a DHT. If they’re using something else, that’s potentially concerning. I haven’t looked into Plebbit a ton though, I’ve just seen it mentioned a few times, but then I’m a bit of an outlier since I’m playing in the same space.


  • Lemmy is not decentralized; it’s federated. “Decentralized” and “federated” are not synonyms,

    This isn’t quite accurate. Lemmy is decentralized, but it’s not distributed. It’s decentralized because the source of truth for a community isn’t your instance, but your instance caches content for that community locally.

    They’re not synonyms, true, but federated systems are typically (always?) decentralized, and rarely (never?) distributed.

    Plebbit seems to be a weird mix of both. Communities are centrally managed, but the data seems to be distributed, at least upon creation (everything probably makes its way back to the creator for moderation).

    DHTs and distributed ledgers are notoriously difficult to design well, often suffering from syncing lags and block delivery failures

    I haven’t looked into it too closely either, but it seems the blockchain is only used for name resolution (seems to be used for community names), so updates should be fairly infrequent.

    I assume they’re using a DHT for data though, probably a separate one for each community, but maybe not. Those can be updated asynchronously, so if data is cached locally, latency shouldn’t be an issue.


  • I really don’t think that would scale at all. A reasonably popular community could have tons of simultaneous posts, and if everyone needs to sync before posting, that would suck. You could probably avoid the worst of it by having posts use uuids, but you’re going to have IO issues at scale. Also, would you need the full repo cloned? That can get big, and you generally only care about recent posts.

    Also, if you’re doing the UUID thing, you’d have sort everything every time locally. That’s fine if you only have a few thousand posts, but if you get into millions or billions, it’ll get bad, especially if you’re dealing with files.

    Databases solve these problems really well. Even a simple SQLite dB would be much better than a filesystem, like orders of magnitude better.