Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcoming Rocket.Chat to Matrix

matrix.org

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Welcoming Rocket.Chat to Matrix

#71

Post by quaintdev »

preseinger wrote: post #59
walrus01 wrote: post #26

Earlier quoted context omitted.

> Rocket.Chat is basically selfhosted slack. What would this accomplish that self hosting synapse doesn't? It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or n…

> It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or not federate. Having attempted to do exactly this recently, let me assure you that while it may be technic…

> it is practically infeasible.

> Try to turn federation off, and you're in a no-man's land of untested and unpredictable behaviors.

This is wrong. I have been using non federated server for over a year and I hardly faced any issue.

Re: Welcoming Rocket.Chat to Matrix

#72

Post by geekgonecrazy »

etc-hosts wrote: post #70

I tried to run rocket chat behind nginx, Android mobile clients updated correctly for a few minutes after original sync, and then it would break and remain broken unless I restarted rocket chat. Desktop web clients worked always. It's probably a websockets issue. I tried running behind haproxy and traefik, same problem. I tried following some advice I got from a maintainer in their forums, same problem. I went back t…

Sounds exactly like a websocket issue. Typically a matter of making sure you have the right options on the proxy block.

Here is a recent example for nginx that handles websockets: https://github.com/geekgonecrazy/rocketchat-matrix-federatio...

Re: Welcoming Rocket.Chat to Matrix

#73

Post by Arathorn »

preseinger wrote: post #67
Arathorn wrote: post #65

Earlier quoted context omitted.

What? Almost every statement here is wrong. There are tonnes of unfederated Matrix servers out there, and E2EE and SSO is completely orthogonal to federation. History retention does apply to encrypted events. And Synapse only tends to use lots of resources when federated into large public rooms (these days). I’m terrified at what must have gone wrong such that you ended up drawing these conclusions :s

I'm conveying my personal experience with the software. > There are tonnes of unfederated Matrix servers out there, No way to know for sure, but it certainly isn't a well-supported configuration. > History retention does apply to encrypted events. > Note that message retention policies don't apply to state events. https://github.com/matrix-org/synapse/blob/develop/docs/mess... > And Synapse only tends to use lots of…

> > There are tonnes of unfederated Matrix servers out there,

> No way to know for sure, but it certainly isn't a well-supported configuration

It really is. By default we develop against unfederated servers (synapse running on localhost). Of the synapses we host at EMS probably 30% are unfederated. It is completely supported.

> Note that message retention policies don't apply to state events

Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

> Synapse used 30-50% of 1 CPU and ~1GB memory at idle with 1 room and 0 connected clients.

Then something was going really weirdly wrong. It should idle at Very strange.

Re: Welcoming Rocket.Chat to Matrix

#74

Post by tcfhgj »

godelski wrote: post #50
TheNewsIsHere wrote: post #45

Earlier quoted context omitted.

> Unlike Signal it has always been completely open source. Honest question: when was Signal closed source, as Signal? I’m not familiar with this. I know it’s roots are in the old Moxie Marlinspike OpenWhisper apps, but that’s a long time ago and the last I looked, Signal open sourced all their code.

There's gripe from people because they didn't update the GitHub repos for the server code for a bit. Client side code was always up to date. There's also another complaint (imo this one is more legitimate) that Signal only allows messages to be passed through their servers. I don't think the parent is really arguing in good faith tbh.

For a year

Re: Welcoming Rocket.Chat to Matrix

#75

Post by Freie_Messenger »

Let's hope Rocket.Chat don't limit federation but use/allow open federation to all Matrix servers and also use and enable the XMPP bridge too. This will give both protocols a boost. Btw: Will they drop the "old" federation?

https://www.freie-messenger.de/en/sys_team/#rocket-chat

Re: Welcoming Rocket.Chat to Matrix

#76

Post by Freie_Messenger »

ducktective wrote: post #12

Can someone explain in layman terms what Rocket.Chat is? Is it a Matrix client like Element? Is it a protocol?

Rocket.Chat is made for workgroups (“groupware”) and can be seen as open source alternative to “Slack”. Open source teammessengers are Matrix, Mattermost, Rocket.Chat and Zulip:

https://www.freie-messenger.de/en/sys_team

Re: Welcoming Rocket.Chat to Matrix

#77

Post by Freie_Messenger »

Arathorn wrote: post #73
preseinger wrote: post #67

Earlier quoted context omitted.

I'm conveying my personal experience with the software. > There are tonnes of unfederated Matrix servers out there, No way to know for sure, but it certainly isn't a well-supported configuration. > History retention does apply to encrypted events. > Note that message retention policies don't apply to state events. https://github.com/matrix-org/synapse/blob/develop/docs/mess... > And Synapse only tends to use lots of…

> > There are tonnes of unfederated Matrix servers out there, > No way to know for sure, but it certainly isn't a well-supported configuration It really is. By default we develop against unfederated servers (synapse running on localhost). Of the synapses we host at EMS probably 30% are unfederated. It is completely supported. > Note that message retention policies don't apply to state events Correct. State events are…

Here are a few tips to reduce resource consumption (german): https://www.freie-messenger.de/en/sys_matrix/#eigener-server

Re: Welcoming Rocket.Chat to Matrix

#78

Post by mistermann »

phoe-krk wrote: post #8
mistermann wrote: post #3

A new implementation of the same thing, now on a different platform. Is it just me or does it seem like there are certain places where there is little innovation?

You can only reinvent text chat in so many ways before you converge to the de-facto standard most people are using nowadays.

If the goal is simple text chat (communication that uses text) - but text can be used in a wide variety of ways!

If some of the many who have reimplemented the same thing on a new platform instead set out to create something new, maybe something new would appear on the scene.

Re: Welcoming Rocket.Chat to Matrix

#79

Post by phoe-krk »

mistermann wrote: post #78
phoe-krk wrote: post #8

Earlier quoted context omitted.

You can only reinvent text chat in so many ways before you converge to the de-facto standard most people are using nowadays.

If the goal is simple text chat (communication that uses text) - but text can be used in a wide variety of ways! If some of the many who have reimplemented the same thing on a new platform instead set out to create something new, maybe something new would appear on the scene.

> If some of the many who have reimplemented the same thing on a new platform instead set out to create something new, maybe something new would appear on the scene.

They do, and novelties do appear. But then they usually fail to gain traction because they require users to migrate to them. Hence, interoperability wins in the long run.

Re: Welcoming Rocket.Chat to Matrix

#80

Post by preseinger »

Arathorn wrote: post #73
preseinger wrote: post #67

Earlier quoted context omitted.

I'm conveying my personal experience with the software. > There are tonnes of unfederated Matrix servers out there, No way to know for sure, but it certainly isn't a well-supported configuration. > History retention does apply to encrypted events. > Note that message retention policies don't apply to state events. https://github.com/matrix-org/synapse/blob/develop/docs/mess... > And Synapse only tends to use lots of…

> > There are tonnes of unfederated Matrix servers out there, > No way to know for sure, but it certainly isn't a well-supported configuration It really is. By default we develop against unfederated servers (synapse running on localhost). Of the synapses we host at EMS probably 30% are unfederated. It is completely supported. > Note that message retention policies don't apply to state events Correct. State events are…

> Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

E2EE-encrypted message are persisted by Synapse as state events.

Or, maybe more precisely, if I set a message retention policy of X days, rows in event tables associated with E2EE-encrypted rooms, which are created when messages are sent to that room, and which are older than X days, are not removed.

Post reply on HN