How can we help with getting support for Ed25519 in crypto/x509 and crypto/tls?

Not possible yet, but I have some ideas.

Our followup Karaoke system [1] can support more users by adding more servers, but we still have more work to do to support billions of users. Regardless, I think it's worth deploying these research prototypes to get a sense of what problems matter to users.

[1] https://vuvuzela.io/static/karaoke.pdf

Thanks. I just added our latest paper to the list.

Sorry! We signed and uploaded new configs, so it should be working now.

Sorry about that. I need some way to prevent someone from quickly registering many email addresses. Do you have any other ideas?

What Gmail did when they started up was to give each early user a small number of invites to hand out to others. That way someone could quickly register, say, five email addresses, but only at the cost of being able to invite five of their friends.

I don't beyond browser fingerprint+ip throttling which may be a step in the wrong direction. Does spark the idea to create a LibreCaptcha.

Registering a large number of rogue identities to exhaust the bandwidth seems to be one of the most practical attacks.

How do you consider that in the threat model of the research paper?

Our latest paper, Karaoke, achieves 6.8 seconds with 2 million active users: https://vuvuzela.io/static/karaoke.pdf

cool! does (or will) the existing Vuvuzela client use Karaoke?

It doesn't yet. I'd like to integrate Karaoke's techniques into the Vuvuzela client in the coming months.

Nice! Looks similar to Seal [1] (also written in Go). I just added a link to Pick under related work.

[1] https://github.com/davidlazar/seal

I used pwclip [1] for several years but I no longer believe that hash-based password managers are the best plan. Now I'm using Seal [2], which is like pass but doesn't depend on gpg.

[1] https://github.com/davidlazar/pwclip

[2] https://github.com/davidlazar/seal

We measured 10% improvement on ppc64.