Natanael

Bad terminology choice, I meant the cert issuer. Need to revise the language later. I was thinking of it in terms of who verifies your IRL identity. The issuer can only issue the cert after you met them and they checked your documentation, etc

More like getting a TLS domain cert from a CA both sides recognize, but yeah

Zero-knowledge proofs still require that third party but only once, to issue it initially. Then the user can issue their own proofs locally

Correct, as a cryptography nerd I can assure you that you MUST at minimum have a trusted verifier which met you in person at some point (such as whatever office you get your physical ID card at) and they have to have your information.

And then you’re trusting both Secure Element hardware and fancy cryptography where both must be flawless in order to protect the end user’s side of it, all while the end user now carries much more personal information with them than before

Not with that attitude timescale

yesno

Flash the tech sucked.

Flash content editors and communities sharing info about how to use it is where it was at. That was what was driving the creativity.

There were lots of programs for making Flash content though, and there was a lot of knowledge about how to make stuff in it. There isn’t the same culture of remixing stuff now. More interactive web games are also more server dependent even for elements where they don’t need to be, unlike tons of old standalone flash games

You can still softlock preventing progress in many, unless you’re in a fully free mode

This is why icons should be vector images, rendered into a bitmap for display only once the app knows the DPI and scaling

15 proxy states typing

The post you replied to comes from a different instance than your own, so does my answer. When you’re logging into your instance, the view of their and mine posts are both remote to you.

Sometimes in Mastodon you’ll only see the specific post that you’re opening a link to directly, not other posts before or after. This tries to fix that.

It’s illegal on licensed HAM channels, but legal on unlicensed channels like the 2.4 and 5Ghz ranges

Don’t ask me why the distinction still remains

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.

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.

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.

https://peergos.org/

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.

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

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.