search

LLEB-ME / gouv.fa

https://gouv.fa
0 stars 1 forks source link

Setup chat service #9

Closed doamatto closed 10 months ago

doamatto commented 2 years ago

Moving from Discord to another means would be pretty important. It would need to be:

Mobile apps are a nice plus, but not required. The API means those who want one can either make one, ask staff to make one, or commission a developer or team for one.

cyckl commented 2 years ago
doamatto commented 2 years ago
  • IRCv3
    • What features are we missing to make this happen?

I believe the only thing would be e2ee

  • Matrix

The main thing I dislike about Matrix is that the supported server isn't native code iirc. I think it's ideal to have a lightweight server if possible. If I glanced over a real means, I would be more than open to it.

cyckl commented 2 years ago

Well Synapse server is in Python but we have Dendrite which I was able to get running with quite a few bugs a year or two back. I'm sure that the project has matured a little more seeing how it's been two years since it's entered beta.

cyckl commented 2 years ago

Turns out dendrite is in the Void repo, somehow

doamatto commented 2 years ago

We could test a deployment with Dendrite. We should also establish some generally recommended clients to help newcomers to the Matrix protocol. Ideally these are native apps that are FOSS and private.

cyckl commented 2 years ago

Agreed. There are a few sticking points though:

Besides E2EE, clients also vary significantly in available features so this may cause quite a few issues. I know macOS has a nice native client called Seaglass but IIRC there is no E2EE implemented. The GNOME system has a GTK3 client called Fractal thats in the process of being rewritten and E2EE is on the roadmap.

doamatto commented 2 years ago

Due to the fact that we’re behind closed walls, federation has to remain off. We could establish a middleman on the public web to allow federation through lleb.me, but it’s still not ideal. If we can do federation without needlessly poking holes, it would be ideal.

doamatto commented 2 years ago

Too close together on mobile haha.

E2EE is a must-have for recommended clients; but by nature of Matrix, we can’t enforce it to my knowledge. Basic encryption is better than no encryption.

cyckl commented 2 years ago

Yeah, I discourage federation because of the performance penalties of constantly syncing room state with other home servers, but it isn't even really an option given our status as an intranet

cyckl commented 2 years ago

For encryption, we can always encrypt on-server since we're all sharing it, but that won't be as secure as each client generating and managing its own keys, unfortunately

doamatto commented 2 years ago

Yeah, on-server encryption is not the best solution, but it’s still a necessary: data should be encrypted at as many stages as possible be it in transit, at rest, et al.

I think we can deploy a test server and explore clients to see what we can safely recommend. If we can reach a consensus in that regard, then we can deploy officially and setup bridges for those who can’t make the switch yet. An internal bridge bot could be a nice addition as well; for Discord server admins to add to their servers that are from the LLEB community.

We should also advertise the benefits of web0 with this and outline a clear policy of handling data in the near future, since we’ll be reaching a more critical state of data handling off the bat. This policy will likely need revision once we deploy file sharing of some sort as well.

doamatto commented 2 years ago

An alternative and possibly a better fit is Ligase: built to be low latency and battle tested by fin institutes. Also in Golang.

Going to be testing iOS and macOS clients; @cyckl, do you want to look over Android and Linux? We can peruse Windows clients shortly after.

cyckl commented 2 years ago

Ligase seems to be connected to Chinese fintech, which is definitely CPC involved—so I'm a little wary about using their implementation. That being said, the current idea does have some more drawbacks:

As for actual client testing we'll probably need the home server instance running or to test off of a public home server for now until we can get our own system running. At the very least, mobile platforms can likely just use Element since both applications for iOS and Android seem to be written in their native languages (Obj-C and Kotlin, respectively)

Where should we host?

cyckl commented 2 years ago

Found a home server called Conduit—written in Rust

doamatto commented 2 years ago

seems to be connected to Chinese fintech, which is definitely CPC involved

It seems to be used by some US govt. clients as well however (namely Rancher, AWS). Curiously, their FinClip service (from my understanding, a hosted version of Matrix) is meant to be in direct competition with popular apps like 百度, 微信, and 支付寶, so it does offer some merit when a service meant to resist censorship, per se, would be connected to a govt of its history. With the help of a few translators, it seems to be a low risk, not to mention that the source code is public so we would know if there's some non-sense hidden within; if we wanted to dig around, we could. You could probably check for phone homes just by searching for URLs and IPs.

Dendrite does not support SSO yet.

Follow this PR; it'll introduce LDAP support, which is a good basis to move forward with. Whatever works, after all.

As for actual client testing we'll probably need the home server instance running or to test off of a public home server for now until we can get our own system running. ... mobile platforms can likely just use Element

I'm using the public matrix.org server for testing right now; going through a slew of iOS clients today. Element is my test list for mobile purely because it's like an official app. Obviously there isn't really such a thing for Matrix, but it's as close to one as phesible.

Where should we host?

Right now, this is a tough question. The benefits of hosting on our rented servers currently outweighs the privacy loss from not using our owned servers. Regardless, we want to lose reliance on the public Internet and use it for backups more so than serving to members. For that reason, it would be ideal to start on owned servers. I'm sure there's someway to do "relays" for audio to help with latency with those in different places in the world over time.

a home server called Conduit

I remember this one; sponsored by the DE for a bit during the pandemic. Follow this issue for the addition of OIDC support; this issue for LDAP.

It seems further research may be ideal for settling on a good server. I'll add OIDC and/or LDAP support to the requirements in the OP.

doamatto commented 2 years ago

Appears that Matrix doesn’t support bridges or bots while encrypted right now. This makes it hard to use as we should bridge Discord.

jackmerrill commented 2 years ago

I do remember seeing some kind of Discord bridge, that connects Discord and it's own chat service that's FOSS. I'll look for it and I'll update this comment if I find it.

edit: one google search and i found it lol https://fosscord.com/

doamatto commented 2 years ago

I do remember seeing this a hot minute ago. I wouldn't be opposed to deploying something like this if it wasn't for:

If there can be a valid showing or perhaps a demo that works with the official clients, perhaps we can move forward with this idea.

cyckl commented 2 years ago

We can always rely on bot / webhooks impersonating our users in-channel, since webhooks can change profile picture and nickname per-request. Just find a way to link Matrix user to Discord user. Could be part of our database schema.

doamatto commented 2 years ago

It would be easier just to use the information from Matrix to create a user. We shouldn’t rely on Discord’s API to gather profile pics, names, et al.

doamatto commented 10 months ago

Matrix has been live for awhile now.

https://synapse.farer.group/