Feature request: disable certain chat features for bridges

[NathanC]

I'm planning on building an SMS bridge. For sms, things like Reactions and replies don't make sense-- it would be good to have a flag that optionally disables certain features for certain bridges. That prevents interacting with the bridge in a way that isn't supported.

Along with this, if presence is not supported, a small question mark in a circle could be presented instead of the "not present" circle.

Basically more native support of switching between different bridges with minimal context switching :)

[SpiritCroc]

This is again a feature that Beeper already has. But since there is no spec-ed way of a bridge to tell the client what it supports, this would be a client-side whitelist for known bridges, and out of scope for SchildiChat. If you want this kind of feature, better spec it first, so it makes more sense to support from a general-purpose matrix-client.

Did you know that Beeper has an SMS-Bridge built into their Android clients? It uses this library: https://gitlab.com/beeper/android-sms - probably better to use this one than building an SMS bridge from scratch?

[NathanC]

Yeah, I agree this makes more sense as a spec.

I have seen that bridge, but I couldn't see how to set it up. I'll definitely look more into it before creating my own. But using Beeper's service isn't an option: I'm using my own homeserver and privacy is important to me, I don't want to hand over all my bridges (as they aren't end-to-end encrypted) to a third party. Beeper's interface seems so much less customizable and powerful than SchildeChat's from what I've seen.

[SpiritCroc]

That's correct, Beeper is currently targeted at a different user group then self-hosters and tinkerer optimizing their own setup (of which I'm part of).

The bridge might need building into a proper app - there was a plan to provide a bare-bones app for using the bridge, but not sure if it is functioning at the current time.

[NathanC]

Yeah, I'm definitely not expecting most people to make their own bridges or anything.

I'll definitely look more into that bridge and see how it's working. I was initially planning on contributing to matrix-sms-bridge (I actually wrote this proposal for that repo up earlier and just posted it), and making a standalone app that interacts with the bridge. But I'd like to avoid reinventing the wheel when possible, and I'm quite new to Matrix so missing a lot of fundamental understanding of bridges and such.

[SpiritCroc]

Even without my Beeper background, I can comfortably say that Beeper bridges (note that the mautrix-bridges are basically Beeper bridges) tend to be the best ones out there (there are great and paid developers behind them after all...) :laughing:

But I'm not really using SMS nowadays, so can't really share experience about that.

[su-ex]

I think we agree that this is currently the wrong place and needs to be specced out first?!

[NathanC]

Just leaving this here for future reference:

• related discussion here:
  • https://github.com/matrix-org/matrix-appservice-irc/issues/701#issuecomment-430657757
• that spawned an existing spec proposal that has been moved to a spec issue:
  • https://github.com/matrix-org/matrix-spec/issues/389

Looks like more work needs to be done, but I'm happy there's something tracking it! I'm learning more about Matrix right now (toying with making a personal markdown journal backed by a matrix room, as an experiment and way to better learn the spec). I'm definitely planning to try and contribute some PRs to SchidliChat once I learn a bit more about the protocol and ecosystem.

Thanks for putting up with all the issues I've filed. I'm really enjoying using your client, it's great software.

[SpiritCroc]

toying with making a personal markdown journal backed by a matrix room, as an experiment and way to better learn the spec

That sounds cool, make sure to post about it in This Week in Matrix once there is something to share :)