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.
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).
Great information, even cooler to see someone's got some code working alongside it, I might have to adapt it to Go if it's fairly reasonable to understand given my relative lack of experience with Unicode (heh as I'd mentioned and is probably obvious given your knowledge on hand).
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.
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.
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...