Instead of having to enter both username and email address on sign-up, users should only be required to provide the email address. Sync could auto-generate the username e.g. by hashing the email address. To support existing users, the email address field in the setup wizard will also have to accept existing usernames (based on whether the value contains an @ character). There's one follow-up for the server: We'll have to support changing the email address which means changing the username.

If we use SHA1 and express it in base32, the end up with 32 char long usernames, incidentally the max allowed length.

(In reply to comment #0) > There's one follow-up for the server: We'll have to support changing the email > address which means changing the username. Filed bug 592933.

Implement Utils.encodeBases32 and Utils.sha1Base32 as per RFC 4648.

The Weave.Service.account property now holds whatever the user entered for email address/username. If it only contains characters valid for usernames, it is assumed to be a username. Otherwise it's SHA1 hashed and base32 encoded. The special tab mangling (to avoid broken Basic Auth headers) is now obsolete.

Consolidate email and username in the UI.

Removing bug 592933 as a hard dependency.

Backwards compatibility fix: Fall back to Service.username if Service.account isn't set.

Also update error messages mentioning user name (now mention email address where appropriate).

Comment on attachment 473569 [details] [diff] [review] Part 1 (v1): Utils.encodeBases32 and Utils.sha1Base32 >- sha1: function sha1(message) { >+ bytesAsHex: function digest(bytes) { function bytesAsHex(bytes) >+ do_check_eq(Utils.encodeBase32("Bacon is a vegetable."), the perfect test.

Comment on attachment 473936 [details] [diff] [review] Part 2 (v2): Account name mangling logic in Weave.Service >diff --git a/services/sync/modules/service.js b/services/sync/modules/service.js >- checkUsername: function WeaveSvc_checkUsername(username) { >+ // For backwards compatibility with the Firefox UI. please be specific about what versions of the UI have this dependency, so that when we drop support for < 4.0 final, we can excise this.

Part 1: http://hg.mozilla.org/services/fx-sync/rev/eb4a384e1ea2 Part 2: http://hg.mozilla.org/services/fx-sync/rev/cfa3a19d7333 Part 3: http://hg.mozilla.org/services/fx-sync/rev/a5e775604a56

verified with recent nightly minefield builds