Hey everyone,
Inkscape has hosted our own chat services at chat.inkscape.org since 2018, we've been using the open source server RocketChat in order to provide the project communication for both internal use and for interacting with users and answering their questions.
The Rocket Chat upstream organisation has recently become hostile to it's users and admins, developing all sorts of covert design patterns to push self-hosted instances into signing up to expensive per-user licenses and proprietary extensions.
It's also sending information about our server back to rocket chat themselves.
The most recent upgrade has left us with a difficult and problematic path ahead as we can't really continue to use rocket chat as a server software. But this has to be a community wide discussion as the service is the most used internal communication channel and is used by many people and many teams for lots of things.
These are the questions I need you to answer, please reply here or send me a personal email or message with your answers:
== Questionnaire ==
1. Do you think we should move away from rocket chat? This is a nominal question since I don't think we can administratively support it going forwards, but we should know your thoughts anyway.
2. Should we reverse engineer the rocket chat database in order to try and keep the history? There are no known tools of retaining the history and if we move to another chat system, our history will be wiped clean. How is history important to you or the project?
3. What replacement chat systems have you used with other projects that you think might be a good fit for our use cases? (see below)
4. Can you expand upon our use cases with the ways you current use, or know that our rocket chat is being used? (see below)
5. Any other comments?
== Use Case ==
I'm drafting a use case document to guide the decision on what to move towards. This might take us time to develop the solution so don't worry about any rash movement, for now we have time to work through the problem together.
You don't have to edit this document yourself, I'll digest answers where I can, but if you want to have a direct hand in drafting I'm inviting people to go to this document and help out:
https://office.inkscape.org/nextcloud/index.php/s/FcTg4QsdstnDeMA == Final thoughts ==
Sorry to spring this problem on the project. After talking with Marc about the way rocket chat is behaving and how their upgrade paths are causing us issues, we believe this process needs to start now.
Best Regards, Martin Owens Project Infrastructure Hat
Uhm, uhg, just uhg.
On Jan 19 2024, at 4:27 pm, Martin Owens doctormo@geek-2.com wrote:
- Do you think we should move away from rocket chat? This is a
nominal question since I don't think we can administratively support it going forwards, but we should know your thoughts anyway.
I think if we can't administratively support it, yes, of course. Sadly, I think we've spent a lot of time making it "home" which will all be lost.
- Should we reverse engineer the rocket chat database in order to try
and keep the history? There are no known tools of retaining the history and if we move to another chat system, our history will be wiped clean. How is history important to you or the project?
Personally I don't see a lot of value in it. Worst case I have the logs that I've pulled off to make the PLC minutes. I think it may only grab rooms I'm in, but I can probably adjust that. I'm not sure it could be reimported anywhere, but I could put it somewhere if people were concerned about it. I'll just need to clean it up as it includes my DMs as well.
- What replacement chat systems have you used with other projects
that you think might be a good fit for our use cases? (see below)
It seems that GNOME and KDE are both going down the Matrix route. I think Ubuntu is looking that way too. I think that has gotten much better since the last time we looked at it. SFC just set up an XMPP server. I was a bit surprised by that, but apparently XMPP is still alive in Europe. I think we should also discuss how much hosting we want to do. I'm guessing (haven't asked) that the GNOME folks would let us put rooms on their server if we wanted. I believe their server is being run by EMS, who might be willing to make a deal for us as well. Also, do we want to have user accounts or make people get something like a federated login (like matrix.org for Matrix)?
- Can you expand upon our use cases with the ways you current use, or know that our rocket chat is being used? (see below)
One thing that I'm not sure is a "use case" that I think we should discuss with this is retention. I think that data is becoming more of a liability so we should have some retention policy. I'm open on what it should be, but we should document it as we're switching to something new.
- Any other comments?
Uhg, just uhg. I think I covered that earlier though. Ted
Copying my replies from the chat here, in case they be lost:
--------
Just found this in the rocket.chat forum: " the Zulip import tool works by importing data from a Rocket.Chat database dump."
https://forums.rocket.chat/t/rocketchat-is-no-longer-a-suitable-tool-for-use... https://zulip.com/help/import-from-rocketchat https://zulip.com/help/public-access-option
They (Zulip) seem to be trying to position themselves as an alternative for rocket.chat.
--------
As much as I like Matrix, I can't really imagine our typical user going through its registration and setup process to get their user support question answered... (from my experience, even tech-savvy open source enthusiasts and people who work in tech fail half of the time trying).
What I wasn't able to figure out was whether there exists a matrix frontend that allows guest accounts (the api does allow it), and whether there are frontends that allow seeing public channels without logging in, which was a 'must have' feature and one of the main reasons we chose rocket chat over others.
Hence the looking for other alternatives.
Maren
Am 21.01.24 um 23:05 schrieb Ted Gould:
Uhm, uhg, just uhg.
On Jan 19 2024, at 4:27 pm, Martin Owens doctormo@geek-2.com wrote:
1. Do you think we should move away from rocket chat? This is a nominal question since I don't think we can administratively support it going forwards, but we should know your thoughts anyway.I think if we can't administratively support it, yes, of course. Sadly, I think we've spent a lot of time making it "home" which will all be lost.
2. Should we reverse engineer the rocket chat database in order to try and keep the history? There are no known tools of retaining the history and if we move to another chat system, our history will be wiped clean. How is history important to you or the project?Personally I don't see a lot of value in it. Worst case I have the logs that I've pulled off to make the PLC minutes. I think it may only grab rooms I'm in, but I can probably adjust that. I'm not sure it could be reimported anywhere, but I could put it somewhere if people were concerned about it. I'll just need to clean it up as it includes my DMs as well.
3. What replacement chat systems have you used with other projects that you think might be a good fit for our use cases? (see below)It seems that GNOME and KDE are both going down the Matrix route. I think Ubuntu is looking that way too. I think that has gotten much better since the last time we looked at it. SFC just set up an XMPP server. I was a bit surprised by that, but apparently XMPP is still alive in Europe.
I think we should also discuss how much hosting we want to do. I'm guessing (haven't asked) that the GNOME folks would let us put rooms on their server if we wanted. I believe their server is being run by EMS, who might be willing to make a deal for us as well. Also, do we want to have user accounts or make people get something like a federated login (like matrix.org for Matrix)?
4. Can you expand upon our use cases with the ways you current use, or know that our rocket chat is being used? (see below)One thing that I'm not sure is a "use case" that I think we should discuss with this is retention. I think that data is becoming more of a liability so we should have some retention policy. I'm open on what it should be, but we should document it as we're switching to something new.
5. Any other comments?Uhg, just uhg. I think I covered that earlier though.
Ted
Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
eHi everyone,
1. Drop RocketChat? While I don't know the details that have led to this, I am aware that things at RocketChat have been moving in an unfavorable direction for quite some time, so I blindly support dropping it.
2. Reverse engineer/import database? I am strongly against any reverse engineering. The database contains sensitive data (private messages) and I would not give consent to anybody to start messing with it. The purpose of a persistent chat is to not require people to be online 24/7 so they can get an answer but to support asynchronous communication, and that's about it. It should be dropped and not kept or archived.
3. Alternatives? While I am really interested to hear about more alternatives, my current mindset is "convince me that anything can beat a self-hosted Matrix“. It's not perfect but I don't think that anything else comes as close to suiting our needs as this. In general, this topic deserves a longer high-bandwidth discussion that needs to touch on the fundamentals: is this chat for us as in "project members", i.e. "the people who work here" and need a tool to communicate and coordinate or is it for users so they can ask for help? Because I don't think we can have it both ways and still make everybody happy with our choice. And I have some other controversial ideas.
4. Can you expand upon our use cases with the ways you current use, or know that our rocket chat is being used? (see below) I'll skip this for now.
5. Any other comments? I'll setup Matrix at home and check the anonymous/public access thing.
René
Am 19.01.2024 um 23:27 schrieb Martin Owens doctormo@geek-2.com:
Hey everyone,
Inkscape has hosted our own chat services at chat.inkscape.org since 2018, we've been using the open source server RocketChat in order to provide the project communication for both internal use and for interacting with users and answering their questions.
The Rocket Chat upstream organisation has recently become hostile to it's users and admins, developing all sorts of covert design patterns to push self-hosted instances into signing up to expensive per-user licenses and proprietary extensions.
It's also sending information about our server back to rocket chat themselves.
The most recent upgrade has left us with a difficult and problematic path ahead as we can't really continue to use rocket chat as a server software. But this has to be a community wide discussion as the service is the most used internal communication channel and is used by many people and many teams for lots of things.
These are the questions I need you to answer, please reply here or send me a personal email or message with your answers:
== Questionnaire ==
- Do you think we should move away from rocket chat? This is a
nominal question since I don't think we can administratively support it going forwards, but we should know your thoughts anyway.
- Should we reverse engineer the rocket chat database in order to try
and keep the history? There are no known tools of retaining the history and if we move to another chat system, our history will be wiped clean. How is history important to you or the project?
- What replacement chat systems have you used with other projects
that you think might be a good fit for our use cases? (see below)
- Can you expand upon our use cases with the ways you current use, or
know that our rocket chat is being used? (see below)
- Any other comments?
== Use Case ==
I'm drafting a use case document to guide the decision on what to move towards. This might take us time to develop the solution so don't worry about any rash movement, for now we have time to work through the problem together.
You don't have to edit this document yourself, I'll digest answers where I can, but if you want to have a direct hand in drafting I'm inviting people to go to this document and help out:
https://office.inkscape.org/nextcloud/index.php/s/FcTg4QsdstnDeMA == Final thoughts ==
Sorry to spring this problem on the project. After talking with Marc about the way rocket chat is behaving and how their upgrade paths are causing us issues, we believe this process needs to start now.
Best Regards, Martin Owens Project Infrastructure Hat _______________________________________________ Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
participants (4)
-
Maren Hachmann -
Martin Owens -
René de Hesselle -
Ted Gould