Handle Group Jingle Messages
The old jingle handling was constructing a message, and then passing it through
part of the message processing system to try and get a resulting message that
would go out to the backend.
But not all the logic lived in that part of the processing pipeline. The group
logic, in particular, lives on the ingress side where I get a message from the
user, and translate it into a message with multiple receivers.
So, to try and bring these together I've instead pulled the receiver apart from
the XMPP bits a little. So now there's a new thread that just pulls from XMPP
and puts on a channel, and the actual handling logic pulls out of that channel
and processes it.
That logic barely changed at all.
But what that means is that our Jingle code can now produce a message that
looks like the user sent it directly, and then push it in the front of our
pipeline, as though the user sent it directly. Rather than the half-and-half
approach from before.
Hopefully this kind of approach also avoids future issues where we want to
produce something and want it to work in all cases. There's nothing about
Jingle in particular in the fix, really.
Accept an Error to Backend Presence Request
We didn't want the backend servers to be required to support these kinds of
requests, but if we don't handle error on these then the client will never see
numbers as online.
Update Dhall to Newer Version
Some classes changed names, others changed types.
All in all it was a relatively straight-forward port.
Terminate Jingle Sessions After Transfer
The spec for Jingle claims either side can terminate the session, but suggests
that the receiver should, since it knows when it's received things.
The current code expects the sender to do it, and Conversations expects the
receiver to do it, leading to both sides waiting for the other to do something.
So to fix that, Cheogram needs to send a session terminate once the upload is
At some point this logic, and the optional "received" that's already there,
should live inside the Jingle library, since they're related to the Jingle
session which this code otherwise knows nothing about.
But that day is not today! Today I just want to see this work, and make sure it
doesn't break anything else. Then we can figure out how to move it inside.
Once I had three things there, I put them in do-notation since I felt that was
clearer than what was there, with the ">>) $" thing.
I also considered putting them all in a sub-notation, since they're all being
lifted right now, but decided that would make it harder later, since I'm
planning on pulling this stuff out into the library at some point.
So no need to make things _too_ clean! Gotta feel the hurt!
Ignore message from ourselves
If a message is coming in from our own DID, do not process as that would lead to
Better URL block for whispers
Command-only commands work
That is, if the command returns completed immediately with a note, the
note is returned to the user. Anything else is treated as an error.
Refactor help command to stop using the -and-then resource hack
Only assume nickname for phone number if isE164
Show bot-style help from the ad hoc commands
Start sending some statsd stats
Try new group text porcelein format
Process even if it already exists
Only query for disco once
Instead of every time we get told a resource is online. If we already think it
is online, then assume we already queried and just leave well enough alone.
Cuts CPU usage to normal from insane in production.
Do not report errors that come back from presence discovery
Store presence and caps/disco info in redis
Seperate out mapping for SIP URIs so SMS targets don't get caught
Allow calls from blocked caller id
Hardcode sip.cheogram.com for now
Should this be configurable per-user or just per-instance?