lancestout

There's the /.well-known/browserid [1] file that can be used to delegate a domain to another identity provider.

The main thing is that while Persona talks about email verification, the protocol doesn't require that email handling exists. Just that a server vouches for the existence of a user@host, so using MX records wouldn't be 'correct' even if it would be a useful heuristic for google apps domains.

There has been talk of using SRV records, but it looks like the .well-known/browserid file will be the recommended way to do things.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/.we...

The decision to only support Unicode 3.2 is simply because the StringPrep framework [1] (which XMPP's nodeprep and various other protocols use) is forever tied to that version of Unicode.

Current work is on the PRECIS framework [2] which uses the metadata for Unicode code points to determine how to handle them during canonicalization instead of relying on a hard coded set of mapping tables. There's still a lot of work to be done, mainly to review that the process works reliably and doesn't introduce subtle new issues. Peter Saint-Andre (one of the authors of PRECIS) has just started on a Python tool for testing how a given version of Unicode is handled by PRECIS (https://github.com/stpeter/PrecisMaker).

[1] https://www.ietf.org/rfc/rfc3454.txt

[2] https://tools.ietf.org/html/draft-ietf-precis-framework-08

This is actually goes to the point behind the http://nodesecurity.io initiative - building up the security mindedness of the node community by auditing npm modules for various vulnerabilities and making it easy to responsibly disclose vulnerabilities to module maintainers [1].

We're in the process for the first audit wave (checking for things like child_process.exec), and have already had several modules get patched.

IIRC, the npm maintainers have expressed interest at the recent node confs/meetups about incorporating security advisory information into the npm package results, to alert people about potential issues when installing modules.

[1] http://blog.liftsecurity.io/post/52010883123/security-md-imp...

Yes, it is. The very start of a session is usually synchronous (authentication, etc), but after that it is async. Request/response commands have an id value to link the request to the response so it doesn't matter if other data arrives first.

Yeah, there's http://xmpp.org/extensions/xep-0286.html which discusses some ways to mitigate the power issue, but, from what I understand, we never got much feedback from mobile developers about it. In particular there are several extensions which remove the need for a lot of network traffic (capability hashes, roster versioning, stream management to immediately resume a session that got disconnected, etc). The fun part is that 1) a lot of mobile client developers haven't implemented those and 2) most require server support, and Google never added support for them.

As for a binary serialization, XMPP traffic does compress very well already (TLS/zlib/lzw), but we have started the process on standardizing the use of EXI (https://en.wikipedia.org/wiki/Efficient_XML_Interchange).