SchildiChat / schildichat-desktop

Matrix client / Element Web/Desktop fork
https://schildi.chat
Apache License 2.0
379 stars 44 forks source link

Feature request: display bridge icon or text next to user #164

Open NathanC opened 1 year ago

NathanC commented 1 year ago

I'm using a lot of bridges: Whatsapp, Signal, Discord, and soon SMS.

I enabled the bridges visibility in the labs, and it's awesome! However, what would be more awesome, is having it visible in the user list and by user names in messages.

Right now, some bridge like Signal add a (Signal) message after it. This could be entirely replaced by a signal icon by the name! I think bridges are a huge selling feature of Matrix, and first class support of visual distinction between bridge users in the client would be incredibly valuable.

You can even add the option to regex on the name and strip out suffixes like (Signal) until the bridges catch up.

SpiritCroc commented 1 year ago

Since @su-ex is responsible for desktop, I'll reply general speaking while also considering this feature for Android.

In general, I like this feature. However, it kind of feels copying Beeper-original features to me if we did that. We'd also need to include icons for every known bridge, which adds some small, but not negligible extra maintenance to us. Bridging itself is not a Schildi-specific feature in a way as it is to Beeper. So I think it doesn't align too much with SchildiChat goals, but I may reconsider that depending on what other (most importantly @su-ex ) think.

I don't think regex-ing names is a good idea. Your bridge configuration usually allows you to specify freely what name to put where, so if you want to remove the "(Signal)", this is best done from the bridge config. (Note clients can still detect the bridge by some bridge event that clients usually do not render).

NathanC commented 1 year ago

Thanks for your quick response!

Regexing the name isn't the core point, we can drop that part for now. And all the matrix clients are evolving together-- the idea of Matrix being a bridge between disprate closed gardens isn't something Beeper invented, nor one I would think they'd want to exclusively lay claim to. I've never used beeper, so this idea wasn't even based on it (though I'm now installing it to test). I'm just basing this request based on what I see in the desktop client-- when I look at the bridge, it already has the bridge name (Signal) and the bridge icon as part of the info it presents:

image

Perhaps it's not basing that on some spec, but it works in practice for the three bridges I have, and the information is being fetched/inferred somehow.

But in short, what's the harm? If I add in this feature myself (I'm a React developer) and bury it in some deep advanced setting, and it's useful to me and keeps me using Schildichat (which I really like so far), wouldn't it be good to add? It could fall back to an icon of a Bridge or something for ones where the icon can't be inferred, and optionally users could provide their own. It can be added incrementally.

I think now is the absolutely critical time for this. I migrated to Matrix and made my home server specifically because Signal dropped support for SMS. I'm planning on building out an SMS bridge for myself (unless I can find some way to use Beepers). Having a unified system for messaging is a huge draw to this system, and frankly one of it's absolute killer features. And once its seamless, the barrier to joining Matrix drops sharply for a lot of people, and they're going to choose clients that don't disconnect them from other ecosystems.

Happy to discuss any of these points!

SpiritCroc commented 1 year ago

I wouldn't mind adding it as contribution, even if it isn't hidden in settings :) To clarify, I'm part-time working on Beeper Android, that's why I'm a little careful to not copy too much from them - but if the feature initiates from the community, that's totally fine for me, and I'm sure @su-ex would be happy to accept contributions, as long as they don't lead to too many merge conflicts for future upstream merges.

NathanC commented 1 year ago

Ah, that's understandable! I think beeper absolutely has its place-- I'm far more likely to get my non-technical friends to use a polished service geared towards unified chat if that's what they're interested in. When I mentioned Beeper to a friend of mine earlier, I explicitly said that hybrid closed source/open source companies are healthy and should be supported, especially ones that give back to the community.

That being said, there's no reason why open source clients can't use the same general pattern, no need to exactly copy the interface, and frankly these are pretty natural conclusions from using Matrix with bridges. A poor man's version of this already exists with suffices like (Signal)-- this is just an image instead of an out of place text string.

Even things like sending SMS directly to contacts via the app (transparently bridging to the SMS bot instead of requiring the user to start a conversation by messaging a bot) are killer features that I have no idea if Beeper supports, as I've never used it (though I'd infer they probably do). They would be fairly easy to add.

Anyhow, it sounds like we're on the same page overall, with being open to contributions? I know maintaining software like this is a thankless task and I'm not trying to just throw work at you guys. You mentioned about the changes not leading to too many merge conflicts-- I'm guessing that's because you're a fork from Element's UI? Is there any overview of the considerations that need to be taken for changes to the fork?

SpiritCroc commented 1 year ago

Yeah, we regularly merge new Element versions into SchildiChat, so we always try to keep our own footprint on Element's code low to ease upstream merges. So never delete huge blocks of upstream code but rather comment them out if necessary, put into new/Schildi-specific files what's possible, etc... sometimes even inconsistent indented code blocks are better than having to deal with merge conflicts, depends on the case.

I'll leave it to @su-ex to decide if that's something he would like to deal with for maintenance :)

btw, for identifying bridges, you'll likely want to check the "uk.half-shot.brige" or "m.bridge" state event, and check it for the "protocol"/"id" field.

NathanC commented 1 year ago

Very interesting, seems like a very difficult workflow tbh, I have a lot of respect for you guys keeping it up with such high quality.

As for identifying bridges, do you know how it's currently being done in the "bridges" section of the room settings? image

It seems like the information is somehow inferred directly from the room, so whenever I'm rendering the room in a list I could just extract the value as a function of room, and render the icon as a small badge whenever rendering the user name. I'm not familiar with how state events work or anything yet, so I'll dig into it and definitely look up those events.

SpiritCroc commented 1 year ago

I don't know the desktop code, but it's most likely this:

btw, for identifying bridges, you'll likely want to check the "uk.half-shot.brige" or "m.bridge" state event, and check it for the "protocol"/"id" field.

You probably want to read into state events and get used to /devtools ;)

NathanC commented 1 year ago

👍 for context, I'm brand new to Matrix, just set up my homeserver and the bridges today, so a lot of these thoughts are just my initial impression and definitely need refining as I learn more about the ecosystem.

This is the best setup I've been able to get so far in terms of

image

And it works pretty well! The People tab on the left isn't great tbh, since I usually want to bucket DMs + small group messages (for SMS group messages or discord group messages or matrix rooms with a few friends). The logical distinction to me seems to be (DMs + small group chats on matrix or brides) | (large matrix rooms + discord servers), as opposed to the current distinction in the UI between ( DMs ) | ( Rooms ). Actually one of the main reasons I switched to SchildiChat is that it allows for removing the distinction between rooms and people when viewing a space.

Anyhow, the largest issue with the way I did it above is that when I view the top level "Personal" space, it's hard to distinguish between the different bridges, especially in a way that looks nice. Hence creating this feature request. While having a nicer UX for it on my phone is my ultimate goal, I figured desktop would be an easier place to start given that it's React and not a full native app-- it can also be a proof of concept.

SpiritCroc commented 1 year ago

If you make something for desktop that's so great that I get annoyed about Android not having it, that might motivate me to help with the Android side :upside_down_face:

su-ex commented 1 year ago

I've no leeway to implement something like this myself right now, but I'll gladly accept a contribution (indeed preferably written in a "merge-efficient" way so it doesn't break too often). This would indeed be great for making bridge rooms easily distinguishable. 👍🙂