Interfacing with servers with Roster Locking

[kousu]

Today we discovered that riseup.net is one of those servers where you can't receive messages from people not on your roster. Roster-locking ((is that the right name for this feature)) is a harsh but de facto effective anti-spam measure. Trouble is, this interacts super poorly with SMS, which has no concept of authenticated messages, and isn't meant to: the design was always to allow anyone to contact anyone.

For geeks self-hosting their own servers roster locking is a conscious choice, so for those users we can probably assume they are happy only receiving texts from "friends", but let's add a FAQ entry...somewhere...probably both on https://cheogram.com and on https://jmp.chat... reminding people about this snag.

But with a public server like riseup.net there is no way to expect users to understand why messages aren't coming through, and even if we explain I foresee this being basically a dead-end for most users: they need to manually add everyone who texts them? balderdash!

Here was my experience:

1. I asked JMP to register +14388999149 to kousu@riseup.net, which worked but only after I added +14169938000@cheogram.com to my roster.
2. I messaged from nick@kousu.ca -> +1xxxxxxxxxx@cheogram.com -> +14388999149@cheogram.com -> kousu@riseup.net and did not receive it.
3. I messaged from +1aaaaaaaaaa (on a Real Phone) to +14388999149 (incoming) but did not receive it
4. I added +1aaaaaaaaaa@cheogram.com to nick@kousu.ca and messaged it (outgoing); this worked.
5. Then +1aaaaaaaaaa messaged +14388999149 (incoming) and that worked, because step 3. authorized this.

There's a warning on the JMP sign up page about this:

If you have not yet received the verification code, please add the contact "+14169938000@cheogram.com" to your roster and then click here or press Reload to try again, or press Back to select a different JID to use.

but that only covers one number, @ossguy's company number 416-993-8000. It also wasn't that obvious how to make use of this information, which is why I think you should make the Retry Button more prominent too.

I think it would be better if we could work around this issue on our end; there's gotta be lots of servers with roster-locking enabled, and silently failing JMP with them is the sort of thing that drives people into centralized servers.

I see some solutions:

• maybe adding cheogram.com as a contact can count as consenting to receiving messages from any JID hung off it; adding cheogram.com is a part of the signup process --- though it's buggy with Gajim. This depends on the receiving side agreeing though, and I'm not sure it's spec'd anywhere, so there's some research to be done here.
  • either maybe just because this is a magic feature enabled in the remote firewall
  • or because cheogram.com advertises itself as a gateway (however that's done, I don't fully understand XEP-100) and gateways on rosters get special dispensation from the firewall
• ensure that senders are on the roster first somehow.
  • Snags: a. this requires queueing messages until we know we're on recipent's roster, in contrast to the currently nearly stateless nature of the bridge b. if someone does want to block a number how would we ensure we respect that? mod_blocklist is an option, but if a user is used to the block-unknown-users feature how; maybe in practice this is a vanishingly small percentage of usage and we should worry about dealing with it later, though. c. This goes against one of the features @singpolyma likes most: that it leaves the roster in his full, human, control
  • Designs: a. mod_remote_roster supports this; requires every admin on every server to install this extension, but maybe that's a less onerous political problem than having no spamblocks at all; in a lot of ways this looks like the "special dispensation" I mentioned above. b. by sending subscription requests from senders before sending a message
    1. before every message
    2. only for recipients that we know don't have us, a list we can inferring by listening for the <presence type='probe'> requests that happen when a client signs in
• go nag the riseup.net admins and every other admin on every other server that implemented this to implement a more fine-grained anti-spam policy, or maybe to special-case cheogram.com and only cheogram.com
• make a super super super clear and obvious FAQ explaining the interaction of your server and JMP
• make a giant special-case list of servers we know do roster locking and, upon jmp-register or other signup, send a big warning by every channel available to use with a link to a FAQ with super clear instructions.

I dunno, maybe the sort of people who use riseup.net will appreciate the opaque wall against strangers texting them. Maybe this is all a moot point, except for educating users about the features.

Myself, I think mod_remote_roster is the best option. Both prosody and ejabberd have support (though I think prosody's support is buggy, but we can patch that) and it smells the nicest and politest protocol. I would still be worried about handling if someone explicitly removes a texting contact: are they doing it to block, or just to tidy up their roster? If the former, should we support them, or recommend they use blocking instead? What if their server doesn't have mod_blocklist?

Sending subscription requests before every message has better backwards compatibility support --- i.e. it works everywhere right now, forever --- but could get super noisy if a user wants to reject a contact. It could also provides a better experience in some ways: "+1<number> would like to message you. Do you accept?"

Related: https://gitlab.com/ossguy/jmp-register/issues/12

[ossguy]

The "adding cheogram.com as a contact can count as consenting to receiving messages from any JID hung off it" point is indeed an option on some servers. For example, ejabberd has an allow_transports option now that does this:

https://github.com/processone/ejabberd/commit/dfd2045523f5c6814a460692ba902aa08dd62df8

However, this does require the user's server have it enabled. So we still need to proceed with the "go nag the riseup.net admins and every other admin on every other server" point in parallel.

[kousu]

With riseup.net, at least, having cheogram.com on your roster does not authorize messages from user@cheogram.com. So we'd need to get people to make code changes on their servers.

I think the only changes we can make fully on our side is sending a full subscription request before each message. Even using XEP-0321 means convincing server ops to install a new module.

[kousu]

Notable that ejabberd's definition of "transport" is just if the contact's server is in the roster. Which is probably a fine definition, tbh, despite almost totally sidestepping the spec in XEP-100.

[singpolyma]

They could also do disco to see if the identity has a category of gateway... but that seems like overkill for what the feature enables :)