Replies: 7 comments 20 replies
-
Hi, @rom1dep . Appreciate the fair take. On my side I'm actually a quite ardent proponent of open-source. 99% of the applications I use are open-source, but some reason this hasn't yet translated to chatting applications. I saw that @rauenzi had a Discord server already for it and I'm OK with using it. If the team thinks it's better to switch to something else, then I'm fine with it. Theoretically GitHub is also not open, but at the same time we are using it because it happens to be convenient and it happens to be the place where everyone is. Look forward to everyone's feedback. |
Beta Was this translation helpful? Give feedback.
-
I mostly agree with @rom1dep regarding the reasons to use self-hosted FOSS, although I wouldn't oppose the use of @rauenzi 's Discord server for more synchronous communication until we have a more certain decision as a community on what tool to use. I just want to point out that, while @eliandoran example about Github is correct, the underlying tool we're using is Git, meaning that even if Github decided to close our organization and ban us, we would have locally everything needed to go on to other solution, like Gitlab. It would be a headache and perhaps more than a nuisance, but it would be possible. But when we're dealing with close tools, we are somewhat pinned to the company behind the chatting software, and thus we may be affected by any kind of changes in their policies. Discord, for instance, AFAIK has no explicit policy saying that they can't use code or anything else that users post. Perhaps maintaining a self-hosted instance of e.g. Mattermost is more work, but at least we are not vulnerable to some weird bureaucratic policy change that just blocks or erase our chat history, including decisions, code snippets, etc. That's my two cents. |
Beta Was this translation helpful? Give feedback.
-
TL;DR: IMO Matrix with bridging to other services should be the best compromise. I would like to assist in setting up that & can provide ressources to run such bridges if the majority would accept such solution. I also agree with @rom1dep & @rodrigoalexandrecosta to prefer FOSS & open solutions over centralized properiatary solutions. Also, personally, I prefer solutions allowing / embracing federations and/or bridging. Personally, I prefer Matrix, but I understand the inconvience it brings with it. I sadly have not much time to spare as of now, but otherwise would have the computational ressources and knowledge to aid in providing a bridging between Matrix and other services. Such a bridge should be possible between at least Discord, Telegram, and Matrix. A bridge to Mattermost seems to require a mostly dedicated Matrix server & a dedicated Mattermost server (at least when using this connector), but also is technically possible. I think such a solution is the best compromise as everyone use the tool which is most convinient to them (be it, e.g., Discord or a Matrix client). However, for transparency, some communities decided to disable such bridges again because it makes it harder for moderators to moderate (esp. on non-Matrix platforms where all bridged messages are issued by a single puppet account). (For notice: I haven't contributed code to Trilium yet, just used it.) |
Beta Was this translation helpful? Give feedback.
-
I understand and agree in principle with the desire to use FOSS and standardized solutions for chatting/messaging. The vast majority of what I use is open source, and I even develop multiple open source projects. However for me, usability is king and none of the existing solutions are actually good to use. As Elian said, the open source chatting sphere is really lacking when compared to closed source solutions. Hosting our own instance of some self-hosted FOSS solution to me seems like overkill for a group that hasn't even gotten off the ground yet. It adds overhead and maintenance for this group that's barely starting to form. Additionally, using such solutions will also discourage participation from active users due to the platforms being hard to use or understand or access or otherwise for the average user. For example the official Trilium gitter is fairly inactive with few members which is a poor participation rate for something as widely used as Trilium. The GitHub discussions which are slow and asynchronous were even used more than gitter. In the end, if the group (once solidified who is a part of things) decides to move forward with one of the FOSS and/or self-hosted solutions for it then so be it I'll live. I'll probably just favor using GitHub more in that case personally. |
Beta Was this translation helpful? Give feedback.
-
I share the same sentiments with everyone here - but Discord is just really, really good at what it offers. I also use Matrix, but it can be prohibitively complex sometimes (and you don't truly own your own data unless you run your own homeserver). IMO (I have a stupid opinion), to increase visibility into the "ecosystem" and to obtain more possible developer "mindshare", I think it would be a detriment if we weren't to heavily consider something like Discord. From what I've seen, tools that use Discord always gain more traction than tools that don't. Not sure if that's correlation or causation, but just my observation. I'm also a Discord weeb and prefer my partner to message me there than text messaging, but just my 2c. |
Beta Was this translation helpful? Give feedback.
-
So... are we actually using the Matrix one? I just joined, not seeing any messages |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
TLDR: The official TriliumNext synchronous discussion is happening on Matrix
@TriliumNext/everyone please use the rooms in the matrix space for synchronous chat & coordination. If you would like a new room created for a specific github team, please let @meichthys know.
Hi!
Perhaps I'm beating a dead horse here, or maybe not, but I feel it's an important discussion to have, especially at this stage :)
This discussion can be split in parts:
1- should we care (what's at play),
2- a vote for one solution or another (if warranted),
3- a validation (over a certain period of time) that the solution fits the needs of most
This would be part 1.
In my opinion, self-hosted open-source projects should favour open-source and self-hostable communication systems, as to:
Let me know what you think :)
24 votes ·
Beta Was this translation helpful? Give feedback.
All reactions