111–120 of 124 posts
Earlier quoted context omitted.
1. ChatOps is still a feature of GitLab https://docs.gitlab.com/ee/ci/chatops/ and supports multiple chat platforms. GitLab doesn't need to own the chat to make chatops work. 2. GitLab contacted Matrix. I think 3. and 4. have answers in https://matrix.org/blog/2020/09/30/welcoming-gitter-to-matri...
I believe that grandparent wanted us to listen to the interview (:
I really like to use IRC on the terminal via Irssi. Can Irssi be used to access this matrix thing? If not, is there some nice matrix command line client in the Debian repos? Or maybe someone could just make an IRC server which is a bridge to matrix?
Matrix is based on an open documented protocol, which means it welcomes multiple implementations. There are several terminal-based clients, which you can see on their current client list, and I wouldn't be surprised if more appear over time: https://matrix.org/clients/ There are also Matrix-IRC bridges that already exist: https://matrix.org/bridges/#irc
Earlier quoted context omitted.
The reply issue is pretty hard to solve, since sometimes the extra text is useful, sometimes it isn't. Perhaps if there has been N minutes or X lines of chat since the message being replied to, then include the extra text, otherwise don't. The template should be changed to something like this though: bar: re "hello about something longis...", hello! bar: re "short hello", hello! Those are the main ones, a few more: I…
> Directing a message at a specific person on the channel sometimes posts their full Matrix URL on the IRC side, rather than just using their IRC nick: [bar](https://matrix.to/#/@bar:matrix.org): hello This one is a client-side bug, not a bridge bug. > Directing a message at a specific person on the channel sometimes posts their full name on the IRC side, rather than using their IRC nick: Bar Baz: hello This should o…
Hmm, in IRC clients or Matrix ones? Which clients?
> This should only be a thing when mentioning non-IRC users. Is this actually a problem?
Yes, because it makes it harder to follow the conversation from the IRC side because the full name from the Matrix side isn't available on the IRC side and even if it were present in the IRC "real name" field, it would still be hard to map from real names to IRC nicks, which is why IRC users never address each other using their real names, only their nicks.
This is great news. I've used Gitter for communication in some open source projects, and have always found certain things painful. My favorite points from the article are; - Improving iOS and Android apps. At least in the iOS case, the experience is abysmal (the web interface is similarly so) - Replacement of the matrix-appservice-gitter bridge. I've used the Matrix Gitter bridge for some time now but there's much le…
Although I was well aware of Matrix for years, that particular intention behind it somehow never got through to me.
Earlier quoted context omitted.
Right. The point is, if a competitor who was a for-profit company was willing to federate with Element, as a first-party contributor not just reluctantly "I guess you can use our integration API's for that and we won't stop you... yet" -- that would be watershed moment in hopes of federation/integration instead of silos being a thing. That is indeed not what happened. It's just an acquisition. It does not actually gi…
The Matrix.org blog post isn’t really me trying to wave a hand over it - it’s just that the Element, Gitter and GitLab ( https://about.gitlab.com/blog/2020/09/30/gitter-moves-to-ele... ) and Changelog stories fixate on it being an acquisition, and I wanted to dwell on the impact for Matrix. The reality is that bridging a big existing network is a significant undertaking and nobody has done it before (other than possi…
Earlier quoted context omitted.
Please, please fix the years-old notification bug where you can't turn off email notifications for every single comment without leaving the channel. "Only email me when I'm mentioned" actually emails you for every message instead.
If you use the "Announcements" settings, you will see this behavior but is also described in the notification modal as an oddity. This is tracked by https://gitlab.com/gitlab-org/gitter/webapp/-/issues/1205 which is a huge pain in our notifications that I want to address. If you use the "Mute" notification setting, you will only get emails for messages the mention you which sounds like you're after.
Earlier quoted context omitted.
Right. The point is, if a competitor who was a for-profit company was willing to federate with Element, as a first-party contributor not just reluctantly "I guess you can use our integration API's for that and we won't stop you... yet" -- that would be watershed moment in hopes of federation/integration instead of silos being a thing. That is indeed not what happened. It's just an acquisition. It does not actually gi…
The Matrix.org blog post isn’t really me trying to wave a hand over it - it’s just that the Element, Gitter and GitLab ( https://about.gitlab.com/blog/2020/09/30/gitter-moves-to-ele... ) and Changelog stories fixate on it being an acquisition, and I wanted to dwell on the impact for Matrix. The reality is that bridging a big existing network is a significant undertaking and nobody has done it before (other than possi…
Admittedly, I'm a fan of the matrix protocol and the Element client...but i have friends still living on slackland, etc. If what you're hoping for would really would happen, well that would be so awesome!
The problem with Matrix is their focus on Electron-based client. Official native client would have been better .
If you granted Gitter access to Gitlab, you granted it full read access to everything in your Gitlab account. This is because Gitlab does not yet support restricted access grants [1]. Soon https://element.io will have that full access. Now is a good time to check your Gitlab access grants: https://gitlab.com/profile/applications [1] "Support restricting OAuth tokens to specific projects and groups " https://gitlab.co…
Absolutely - at Element we categorically have zero desire to have access to anything in your GL accounts. On the other hand, for the same reason, we’re not going to exploit that :/
With only as many rights as necessary, of course. No app needs full account access, all the time. Make the various parts differently authenticated layers.