5 ms·

That might be true - but how else can it work? The data has to get onto the server somehow, and the days of unsigned or unencrypted data ended with Snowden. Th

That might be true - but how else can it work? The data has to get onto the server somehow, and the days of unsigned or unencrypted data ended with Snowden. The OP was going on about storing all the data on-device and uploading it, but regardless of where it’s stored, if a bunch of people have to move, the thundering herd problem, so to speak, will still exist. Also, signature verification is not slow. I don’t know what AT uses or how good this source from 2020 is [0] nor what machine it ran on, but ed25519 verification takes about 50us for a 32 byte signature verification. That suggests this guys 50k posts will be validated in 2.5s. If we assume just a single server then that’s about 34k users per day. Or put another way, 30 servers to onboard one million people in a day. None of this seems outrageous to me. [0] https://safenetforum.org/t/ed25519-vs-bls-performance/32613 https://safenetforum.org/t/ed25519-vs-bls-performance/32613

jeroenhd 3y ago
BlueSky uses @noble/secp256k1 which performs this stuff in Javascript, with about 880* verifications per second on the Apple M2 (a chip with a relatively high IPC, likely higher than your average server). Verifying those messages will take about a minute of CPU time per user (assuming no impact from cache misses due to threads swapping in and out and processing new data). I think that's quite significant. * = https://github.com/paulmillr/noble-curves https://github.com/paulmillr/noble-curves
- doctor_eval 3y ago
  Yes, OK I agree, that is pretty bad. That’s about 1400 users per day per server using napkin maths. Definitely not the kind of scale I would have expected. But is this the only possible implementation? I suppose for the OP to have a reasonable point (that it’s “a crock of shit”), this would need to be an intractable problem.
  - jeroenhd 3y ago
    I assume a server written in native code would be faster, but I don't know by how much. The normal use case for this algorithm has to do with Bitcoin and the Bitcoin libraries aren't written for multithreaded social media servers so it's hard to say. Theoretically it could be fast, but you'll need to find someone crazy enough to implement thie protofol first.

jeroenhd 3y ago

BlueSky uses @noble/secp256k1 which performs this stuff in Javascript, with about 880* verifications per second on the Apple M2 (a chip with a relatively high IPC, likely higher than your average server). Verifying those messages will take about a minute of CPU time per user (assuming no impact from cache misses due to threads swapping in and out and processing new data). I think that's quite significant. * = https://github.com/paulmillr/noble-curves https://github.com/paulmillr/noble-curves

doctor_eval 3y ago
Yes, OK I agree, that is pretty bad. That’s about 1400 users per day per server using napkin maths. Definitely not the kind of scale I would have expected. But is this the only possible implementation? I suppose for the OP to have a reasonable point (that it’s “a crock of shit”), this would need to be an intractable problem.
- jeroenhd 3y ago
  I assume a server written in native code would be faster, but I don't know by how much. The normal use case for this algorithm has to do with Bitcoin and the Bitcoin libraries aren't written for multithreaded social media servers so it's hard to say. Theoretically it could be fast, but you'll need to find someone crazy enough to implement thie protofol first.