
FIXME
* after sending a message, the server closes our connection. I still have no
	idea why does this happen, and the tcpdump shows a perfectly normal
	server-side close:
	# we send the message
	13:23:04.801809 200.43.178.12.32995 > 64.4.12.150.1863: P 59:214(155) ack 668 win 7504 <nop,nop,timestamp 640283 26318947> (DF)
	# they send us the ACK for our message
	13:23:05.146703 64.4.12.150.1863 > 200.43.178.12.32995: P 668:675(7) ack 214 win 16731 <nop,nop,timestamp 26319385 640283>
	# we send the tcp ack
	13:23:05.146773 200.43.178.12.32995 > 64.4.12.150.1863: . ack 675 win 7504 <nop,nop,timestamp 640318 26319385> (DF)
	# they send fin!
	13:23:05.150125 64.4.12.150.1863 > 200.43.178.12.32995: F 675:675(0) ack 214 win 16731 <nop,nop,timestamp 26319385 640283>
	13:23:05.154031 200.43.178.12.32995 > 64.4.12.150.1863: F 214:214(0) ack 676 win 7504 <nop,nop,timestamp 640319 26319385> (DF)
	13:23:05.445055 64.4.12.150.1863 > 200.43.178.12.32995: . ack 215 win 16731 <nop,nop,timestamp 26319389 640319>
	


TODO
* in the client, do a better stdin reading (ie. like micq)
* group support (part is in place (eg. gid)) (do we really want this?)
* blocked and allowed lists
* multi-user chat handling (part in place, the ugly sb.emails[0])
* higher level callbacks
	I'm not that sure about this one.. it would be really nice to have ALL
	the protocol encapsulated and then call upper-level callbacks if the
	user just don't want to care about, for instance, message parsing.
	But, OTOH, maybe it's not worthy.
* tidy the code a little bit and get rid/improve debug()
* put docs with the basic api


