Cryptography nerd

Fediverse accounts;
Natanael@slrpnk.net (main)
Natanael@infosec.pub
Natanael@lemmy.zip

Lemmy moderation account: @TrustedThirdParty@infosec.pub - !crypto@infosec.pub

@Natanael_L@mastodon.social

Bluesky: natanael.bsky.social

  • 0 Posts
  • 101 Comments
Joined 3 months ago
cake
Cake day: January 18th, 2025

help-circle


  • No, it doesn’t scale “quadratically”. That’s what going viral on Mastodon does to a small instance, not on bluesky. Pretty much everything scales linearly. The difference is certain components handle a larger fraction of the work (appview and relay).

    Both a bluesky appview and a Mastodon instance scales by the size of the userbase which it interacts with. Mastodon likes to imagine that the userbase will always be consistent, but it isn’t. Anything viewed by a large part of the whole Mastodon network forces the host to serve the entirety of the network and all its interactions. So does a bluesky appview, in just the same way, but they acknowledge this upfront.

    Meanwhile, you CAN host a bluesky PDS account host and have your traffic scale only by the rate of your users’ activity + number of relays you push these updates to. Going viral doesn’t kill your bandwidth.











  • Bluesky is federated in terms of that you can swap out arbitrary components and let anything talk to anything. Any app can talk to any appview, that appview can talk to any feed generator and moderation labeler for you, all three of these can talk to any (and multiple!) relays, etc.

    This isn’t 1:1 federation, there’s no reason for one feed generator to talk to another, no reason for an appview to talk to another, no reason for two PDS account hosts to talk. Users on different appviews rely on their respective appviews having at least one shared relay to be able to see each other, and that relay can be swapped out. Every other component look at trusted moderation labelers for flagging content and takedowns - and they all choose independently who they trust. Every PDS just wants to talk to one or more relays to make their users’ posts visible.

    So you can have a pair of users on the exact same set of infrastructure (most regular bluesky users), but you could also have 2 users sharing nothing but the bluesky relay (or another relay) and still talking to each other.

    Since it very heavily relies on domains for readable addresses (using a DID directly is possible but annoying) it’s kinda hard to use in isolated physical networks. Technically you could make an app host its user’s repository and hold a copy of the signing key and publish it locally, but you’d lose a lot of thread visibility unless the app archives everything to republish. Or else you can have a separate offline only lexicon for posting locally, I guess, imitating scuttlebutt.


  • Go away.

    Even I2P uses supernodes, that doesn’t make it centralized because you don’t depend on them.

    You don’t need ultra purist single-type-node mesh like scuttlebutt to be decentralized.

    Bluesky is federated, where the federation has multiple layers and EVERY layer can be run independently and interconnected to other nodes.

    You can even connect to MULTIPLE! An appview can talk to many relays, a PDS account host can talk to many relays, anybody can subscribe to multiple separate feeds generators and moderation labelers hosted wherever, using any app, etc.

    Beyond that, you still have not addressed that you said a blatantly self contradicting statement; that people self host relays, but also they don’t self host relays because that is costly and the self hosted relay code available to the public is experimental and mainly used for reasons tangential to the core function of a production ready relay.

    Your inability to read remains YOUR problem, not mine.

    My point is exactly this - it’s feasible to maintain your own private relay by mirroring the content you want, imitating both Mastodon and scuttlebutt.

    You can choose to share a community relay - or not.

    Running it for an audience of yourself is reasonably cheap. Running it for a worldwide audience is where bandwidth gets expensive. That’s why people run private ones.

    Not capable of synchronizing with the original? Lmao. It’s literally content addressed, you can synchronize with every relay separately, swap arbitrarily between public appviews, regardless of who runs what and where it gets data from. It’s maximally capable of synchronization. It even beats nostr and scuttlebutt because you can VERIFY you have fresh and complete data (Merkle trees yay).

    Pretty sure Whitewind pulls in data themselves directly when users use self hosted atproto accounts, maintaining its own relay index. Don’t think they make it publicly accessible though

    Not having gatekeepers is what matters the most. You can run all infrastructure yourself and still interact with bluesky users (need to use DID:Web, but that’s a minor point)




  • Almost anything where memorization is the primary skill is going to be dominated by people with specific interest, rather than general high intelligence (certainly doesn’t exclude it, but it’s just statistics). Gotta look for something frequently requiring novel problem solving and adaption to filter for high probability of high general intelligence.

    Then there’s also a lot of games requiring very narrow intellectual ability. Being able to parse a specific ruleset, or doing a specific kind of math fast, without needing to be able to handle anything novel. You’ll certainly find some “interesting individuals” around those kinds of games.