ref: 56e23b4519d46be8adae6f7fa018fa35fb38140e cheogram/Util.hs -rw-r--r-- 10.2 KiB
Change JID Command

If the backend sends us a command we recognize as a JID change, we
intercept it and replace it with ours.

Ours asks which JID we want to move to and then asks that JID if it
wants to do this. When they register we ask them to confirm they want to
swap, and then send the backend the actual JID change operation.
Support passing through messages from alphanumeric senders

Some countries support these one-way SMS senders that come from ascii
alphanum+space senders.  All known SGX pass those through raw as the localpart,
so why not just allow them to and fix it up in Cheogram, since that's our whole
job is to make the SGX author's life easier.

Converts to Base10 (https://wiki.soprani.ca/TextEncodingBase10) and appends a
suitable phone-context.  Don't need to specially handle replies since these are
one-way senders anyway so any reply attempt will fail.  Adds the original
localpart as a nickname so that clients can show it rather than the Base10 gunk.
Send support contact addresses as part of help text, if available
Allow backend route to expose an ad-hoc command for registration

In case a backend requires a multi-stage registration, pass through their
command steps as part of our command flow and save if successful.  Continue to
use IBR with backends that do not list a command with node jabber:iq:gateway.
Merge branch 'cv_forward_jingle'

* cv_forward_jingle:
  Support Backend Default Sip Proxies
  Support Jingle Message Outbound
  Double Slashes
  Forward Unhandled Calls to sip.cheogram.com
  Add Resource to Presence Queries
  Allow Removing Sip Proxy
  Add Audio to Caps if SIP Proxy is Present
Add Audio to Caps if SIP Proxy is Present

This should allow outgoing calls to contacts when a user has set
themselves up to make calls.

Along the way we adjusted the way disco is handed to the backend.
Previously it would be sent with a special resource, and then that
resource would be handled inbound so we know what kind of response we've
just received.

That allowed us to be stateless, but now that we have stateful things we
want the ask the backend, it's much more useful to be able to send a
query to the backend and handle the response, if there is one, while we
still have the original request in scope.

This same technique could be used for other flows we have, but doing so
is outside the scope of this commit.
Spawn thread per inbound stanza

Especially now that some stanzas can trigger real inline work (for cacheHTTP),
either all such works needs to be made async, or we can just make stanza
handling async itself.  There's no reason not to do this, and I intended to do
it several times before, and it just never made it in before now.

As a benefit here, we log all exceptions produced by the sub-thread and do not
re-throw them, since nothing that happens handling a single stanza should crash
the whole process.  This increases our exception resiliance quite a bit.
Merge branch 'cache-inbound-oob'

* cache-inbound-oob:
  Intrument cacheOOB
  Fetch any OOB URL from route and cache in jingle store
  Set up structure to cache OOB coming from a direct message route
Set up structure to cache OOB coming from a direct message route

Does not actually fetch or cache any OOB data yet, but detects all such data and
has the right types to be able to do it. Replaces all OOB elements with new ones
and replaces all instances of gives URLs with new URLs, just no actual work is
done yet.
Merge branch 'better-thread-exceptions'

* better-thread-exceptions:
  Terminate on fatal exception
  Import forkXMPP from jingle-xmpp
Import forkXMPP from jingle-xmpp

This is a much safer version that rethrows exceptions to the parent instead of
just printing them and terminating the thread.
Merge branch 'cv_adhoc_squashed'

* cv_adhoc_squashed:
  Change Case to Select
  Add Thread to Bot Responses
  Add Text-Single Handling
  AdHoc Bot Forms
AdHoc Bot Forms

Before this when a user got back a form it was considered an error. Only
commands that returned a note could be executed.
Now, though, we see the form and try to handle it as a series of chat questions
asked to the people. This is only the first version of the technique, though,
so it has some pretty strong limitations.

First, it only supports lists because that's all the test flow I pulled out of
the spec had in it. There are obviously other field types that this will need
to support to be considered finished.

Second, it only goes forwards. There's no cancel, no returning to previous
questions, etc. It also waits forever (well, until the next restart) for the
user to finish, occupying memory in the session holder until then. We could
also maybe ask confirmation before crossing from one form to another, from the
server's perspective, since there's no guarantee that changes made aren't
immediately applied, rather than waiting for the end. At the very least we
should have timeouts and cancelling though.

Third, there's no error handling at all. It just takes things and assumes
success. That should maybe go along with cancellation, at least, but handling
it with some kind of error message and retry may be nice, if the standard and
the server command accepts it.
Better URL block for whispers
Refactor help command to stop using the -and-then resource hack
Sort discoVars

Needed at least for caps hash
Empty is "available" and should go near the top
Store presence and caps/disco info in redis
Seperate out mapping for SIP URIs so SMS targets don't get caught