~singpolyma/cheogram

Fix questioned parse
List all modules
Remove trailing spaces

Especially since they mess up iMessage reactions
Merge branch 'tapback'

* tapback:
  Support bidirectional reactions ("tapbacks") compatible with iMessage
If command name starts with an emoji, display at the front of the line

Makes all the leading emoji "icons" line up with each other which is more
visually pleasing when they are present.
Support bidirectional reactions ("tapbacks") compatible with iMessage

The syntax for iMessage compatible reactions (also at least one-way compatible
with Android) is:

	Liked “original message”

The use of fancy quotes, full quote of original message body, and limited
actions makes it fairly unlikely to clash with user-generated content.  We
extend the iMessage set with one more Reacted with <emoji> to

When we get a reaction from the XMPP side, we send a message like this.
However, the XMPP side only gives us a message ID so we need to store message id
to full body text mapping temporarily in order to enable this.  This commit puts
it in Redis with a one hour timeout.  That means reactions after 1 hour will not
work, it also means quite a large increase in redis storage for this feature.

When we get text like this from the SMS side, we convert to a reaction.  We
leave the body untouched, which breaks Movim but we have  PR for that:
https://github.com/movim/movim/pull/1137

In order to generate the reaction, we need a message ID but all we have is the
body content of the original message.  So we store a sha1-of-body to message ID
mapping for all outbound messages to facilitate this.  This commit puts this in
Redis with a 1 hour timeout.  Again, incoming SMS reactions after 1 hour will
not work (but the fallback message will come through as before instead) and it
also means quite a large increase in redis storage for this feature.
Merge branch 'register-node'

* register-node:
  Just one kind of registration
fix data uri escaping, as per spec now
URI escape % and ? for blurhash data URI
Fix errors from group text porcelein

They come from the bare domain of the route, but we want them to come from the
porcelein address because that's where the original message will have been sent to.
Merge branch 'fallbacks'

* fallbacks:
  Preserve extended addressing for group text
  Never treat extended addressing as incoming SMS to the DID
  Declare the body is a fallback for one synthesized to go with OOB
Preserve extended addressing for group text

Still use the porcelein, but preserve the extra metadata as well, rewriting sms:
URIs to jid at the gateway, rewriting jid to be at the gateway (instead of the
sgx), and adding ofrom of the "actual" sending JID (since we deliver from the
porcelein JID instead of the correct sender).

Add fallback element to describe the extra text we add to the body for the
sender.  Modify any existing fallback elements to have correct indicies in the
face of our changes.

These transforms run after cacheOOB now so that the fallback sometimes added
there can be correctly updated, and so that the body we add does not cause
cacheOOB to think it should not synthesize a body when needed.
Never treat extended addressing as incoming SMS to the DID

If the cheogram backend and the direct-message-route of some users match, prefer
to go to the group text code rather than processing as an SMS command.

Ideally this should check if the addressing has a to jid that goes somewhere
other than us, but in practise we don't support group text to the DID anyway so
this is sufficient for now.
Declare the body is a fallback for one synthesized to go with OOB
Merge branch 'blurhash-sims'

* blurhash-sims:
  Add SIMS with blurhash thumbnail
Advertise support for extended addressing on the component
Log the oob that caused the error
Fix presence subscription after register
Just one kind of registration

We used to have registration (to migrate from SMS-based groups to XMPP-based
groups) but really no one has ever used it and it relied on a weird abuse of the
IBR protocol that I wrote as a protoXEP but no one liked.  We later added "set
direct message route" command which eventually came to be called Register as
well, so now we have two things called regsiter, one using IBR which no one uses
and one using a command which everyone uses.

These days the proposal for how to do multi-step registrations in the sopranica
world (and maybe XMPP everywhere, slidge seems into it) is to use an ad-hoc
command with node jabber:iq:register instead of that old protoXEP no one liked.
So let's use that for our registration, which will just be the direct
message (and calls, etc) registration, remove the old kind of "registration"
which no one ever used anyway.

We still should support IBR though, one because people might expect/try it on a
gateway, and two for things like de-register and check-if-registered.  So make
it use the "Redirect" use case from the XEP to redirect anyone trying to
register to the ad-hoc command.  Return <registered/> if there is a route set or
do not return it when no route is set, for check-if-registered.  Remove IBR is
the same as setting a blank route: it unregisters with the route and removes the
route setting.

Ad-hoc bot users can still type just "register" even though the actual node for
the command is jabber:iq:register now.
Next