Skip Navigation

User banner
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)N
Natanael @ Natanael @infosec.pub
Posts
0
Comments
319
Joined
8 mo. ago

  • UK government trial of Microsoft's M365 Copilot finds no clear productivity boost

    Jump

  • Tools that decrease accuracy should not be provided to government employees

  • Android’s most beloved launcher may be done for good

    Jump

  • I'm using it without updates

  • The sunscreen scandal shocking Australia - the world's skin cancer capital

    Jump

  • Dual wield and use one to surf

  • Trump Suffers Jobs Numbers Disaster After Firing Stats Chief

    Jump

  • They can push for things like altered definitions and thresholds, etc, even if they're not authorized to pick their own numbers directly, etc.

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • A discoverable non-banned account. Not from "ghost accounts". If a server creates a massive amount of accounts to use them to vote, you can see that a small server has a disproportionate amount of registered accounts too, which probably will be otherwise inactive. Then you can reject votes from that server.

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • The very very short TLDR is that anonymization is very hard, but there's auditable cryptographic voting schemes which preserves anonymity by using anonymous cryptographic commitments and one of a bunch of different techniques to count encrypted votes (homomorphic encryption, threshold encryption, etc).

    You could set it up so you know which server each set of votes comes from but not which users on the server. You could also make it prove each vote comes from one real account and that no account voted twice. You could even make use of commitments plus ZKP to prove banned accounts can't vote!

    It sounds complicated because it is complicated. And somewhat inefficient. But it's possible. And it would be fully encrypted and anonymous voting.

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • They're implementing E2E encrypted social stuff. Voting privacy and encryption is linked.

    Especially when you have users across multiple servers and both want voting privacy AND being able to deal with vote manipulation. You need stuff like pseudonymous commitments per account attested to by the hosting instance, etc. The only thing that's simpler but still private is having instances just digitally sign a total vote tally, which also means you can't detect vote manipulation on other servers at all.

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • It's doable with E2E encryption, but lots of social stuff in large groups requires coordination which is incredibly hard to with a server that has no knowledge of what the data is because it can't index anything, etc.

  • Big Surprise—Nobody Wants 8K TVs

    Jump

  • The same argument goes for audio too.

    6K and 8K is great for editing, just like how 96 KHz 32+ bit and above is great for editing. But it's meaningless for watching and listening (especially for audio, you can't hear the difference above 44khz 16 bit). When editing you'll often stack up small artifacts, which can be audible or visible if editing at the final resolution but easy to smooth over if you're editing at higher resolutions.

  • Republican Says They’re Being “Threatened” if They Vote to Release the Epstein Files

    Jump

  • You broke your links while posting here

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • Currently Lemmy is leaking likes via the API even if they only should be available to the user's host and community host server

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • On Mastodon, your instance doesn't receive posts until somebody on your instance interacts with the account posting it (following the poster, browsing directly to the post, etc).

    Feeds with recommendations requires fetching stuff in advance to not be slow and janky. Basically the feed service would need a bot account on your instance and retrieving all popular posts, given the current architecture. Having thousands of these bots across every instance do this would cause a significant performance hit on smaller Mastodon instances when one of their users posts something popular. So you need something different, like a server plugin where the bot fetches the content once and tells all participating Mastodon servers about their cached copy, so they don't all have to hit the hosting instance. But that's a security risk with the Mastodon design.

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • Doing it this way is why small instances gets hammered when a user's post goes viral.

    And as for moderation bluesky also carries information with the top post from the post author and allows hiding replies too, etc. This gets enforced on the appview side, so the posting user's PDS is unscathed if it goes viral.

    Bluesky is built to assume a handful of big relay (remember that a relay can merge in contents of another) and a bunch of appview and a ton of PDS servers, feed generators, moderation labelers, etc.

    Realistically, the relay network will likely end up voluntarily adopting a tree topology - hobbyist communities would run small relays bundling all activity from members' PDS servers, then a larger relay in front gathers everything from a ton of smaller relays and makes it available to appviews

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • No it doesn't. If other people on bluesky servers want to see your content then obviously it will go through bluesky servers, but if you connect to a 3rd party relay and use a separate appview like zeppelin.social and use DID:Web for account ID then nothing involving the bluesky servers was used and it still behaves like native

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • They fixed the large cache needed to validate all traffic on your own relay. Now the cost is mostly bandwidth and whatever CPU power you want to spend on indexing

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • How decentralized Bluesky is compared to the Fediverse.

    Jump

  • The PLC registry is the only such thing, and also it's not a blocker because you can use the DID:Web scheme to manage your own account identity