4 ms·

Hello, I'm Timo and I started the Conduit project a few years ago. Feel free to ask some questions.

by timokoesters 3y ago

Corsome 3y ago
Do you use Conduit daily yourself? I'm wondering if it's stable for daily use.
- timokoesters 3y ago
  Yes, I use my Conduit instance for all my development work and also host a big Discord bridge on it (for https://veloren.net https://veloren.net, which was mentioned in another comment).
  - 3np 3y ago
    Very nice! Sounds like AppService/bridge support is on par with Synapse at this point (and maybe has been for quite a while?) - any gaps to be aware of in that department?
    - timokoesters 3y ago
      Most bridges should just work, some require messing around a bit, also see https://news.ycombinator.com/item?id=36939480 https://news.ycombinator.com/item?id=36939480, I haven't debugged this yet. You can find some bridge documentation here: https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.md https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.m...
- nani8ot 3y ago
  I've used Conduit for about a year now with bridges and it works flawlessly. It doesn't have all features but a recent release added Spaces and end-to-bridge encryption (not as big of a deal when selfhosting server + bridges, but great nonetheless), so I'm not even sure what is still missing.
MayeulC 3y ago
Is there a migration path for Synapse users?
- timokoesters 3y ago
  No, currently you have to start a completely new server. At some point after reaching a stable Conduit release we will hopefully be able to create migration paths.
3np 3y ago
Thanks for checking in! Any thoughts on matrix-p2p aka pinecone which is now being developed against dendrite? Any thoughts on "p2p-ifying" Conduit in the foreseeable future? https://github.com/matrix-org/pinecone https://github.com/matrix-org/pinecone https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pinecone/ https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
- timokoesters 3y ago
  P2P sounds great and I'd love to implement it when it is ready. I think Conduit is pretty well suited for this. But it will still take quite some time until Matrix is ready for p2p clients, it needs some significant protocol changes: https://arewep2pyet.com/ https://arewep2pyet.com/
Arkanosis 3y ago
Hi Timo! I've been using Conduit for 10 months now and I love it. Thank you so much for it! I've two questions: - Is there any concern to have with regards to its future when you finish university? You seem to be by far the most active contributor and I'm worried the project is still dependent on how much time you can afford to put into it; - What is the best way for a Rust / Linux developer to do a first impactful contribution to Conduit? With 155 open issues on GitLab at the moment and no problem really standing out for me as a user, I don't know where to start :p Thanks! BTW I hope you land a great job; I'd happily recommend you where I work, but we don't have any office near Dortmund unfortunately… Feel free to reach out to me if Dortmund / remote is not a requirement.
- timokoesters 3y ago
  Thank you for the kind words! 1: I can't say how much time I will have for Conduit, but I think the project is in a good shape and I think it can reach a stable release without me working full time on it, but of course it will take longer. 2: I think a good way to start is to hang around in the Conduit Matrix room and see if any issues pop up. Often these are relatively simple things like "these logs should have more details" and are a good way to get started. I will also use this opportunity to link my LinkedIn profile: https://www.linkedin.com/in/timokoesters/ https://www.linkedin.com/in/timokoesters/
  - Arkanosis 3y ago
    Thank you for your answer. 1: That's a relief :) 2: I've just joined `#conduit:fachschaften.org`; we'll see if I can help somehow.
rjvs 3y ago
Hi Timo, is there a document somewhere that describes how Conduit compares feature-wise to Synapse or to the Matrix spec? It’s not clear to me if the goal to develop a fully-featured matrix server, or if there is some subset of scale or functionality that you’re aiming for; could you comment on that?
- timokoesters 3y ago
  Hi, the goal is to create a fully-featured server that works seamlessly with all Matrix clients. The one notable exception is that we will not implement support for "outdated" room versions, which means that there are some rooms that are unjoinable because they are too old, those should be upgraded to a more recent room version. I'm also prioritizing features needed for smaller instances, instead of things like user management or horizontal scaling.
sydbarrett74 3y ago
Timo, Thank you and kudos for all of your hard work on this. I will definitely be checking your project out. :) -sydbarrett74
treyd 3y ago
What would you say is your biggest frustration with Matrix's design as a protocol? I have some of my own opinions writing bots and such but I'm curious about the perspective of a homeserver implementatiom maintainer.
- timokoesters 3y ago
  I think the model of having all events form a giant graph is overengineered. They tried to cope with this by introducing things like "fast room joins", but I think they are flawed and treat the symptom rather than the cause of the problem. Servers should only replicate the very core part of a room and fetch remaining information on demand. But I'm working together with the Matrix team to improve this in the future. I think most other things in the spec are necessary complexity. It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on, but they allow Matrix to have a lot of great features. What problems did you encounter writing bots for Matrix?
  - treyd 3y ago
    The impression I got from using Ruma's bot SDK library was that bot clients needed to keep around a lot of state involved in syncing the room to handle new messages properly. Which largely lines up with what you said, although maybe it's possible I could have gotten away with a more lightweight solution since I wasn't making a stanalone client? > It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on Another impression I got was this was kind of an excessive amount of duplication (and other duplications) that could have been avoided had a bit more forethought been put into the protocol design, especially with how these features interact with the e2ee.

Hello, I'm Timo and I started the Conduit project a few years ago. Feel free to ask some questions.

Corsome 3y ago

Do you use Conduit daily yourself? I'm wondering if it's stable for daily use.

timokoesters 3y ago
Yes, I use my Conduit instance for all my development work and also host a big Discord bridge on it (for https://veloren.net https://veloren.net, which was mentioned in another comment).
- 3np 3y ago
  Very nice! Sounds like AppService/bridge support is on par with Synapse at this point (and maybe has been for quite a while?) - any gaps to be aware of in that department?
  - timokoesters 3y ago
    Most bridges should just work, some require messing around a bit, also see https://news.ycombinator.com/item?id=36939480 https://news.ycombinator.com/item?id=36939480, I haven't debugged this yet. You can find some bridge documentation here: https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.md https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.m...
nani8ot 3y ago
I've used Conduit for about a year now with bridges and it works flawlessly. It doesn't have all features but a recent release added Spaces and end-to-bridge encryption (not as big of a deal when selfhosting server + bridges, but great nonetheless), so I'm not even sure what is still missing.

MayeulC 3y ago

Is there a migration path for Synapse users?

timokoesters 3y ago
No, currently you have to start a completely new server. At some point after reaching a stable Conduit release we will hopefully be able to create migration paths.

3np 3y ago

Thanks for checking in! Any thoughts on matrix-p2p aka pinecone which is now being developed against dendrite? Any thoughts on "p2p-ifying" Conduit in the foreseeable future? https://github.com/matrix-org/pinecone https://github.com/matrix-org/pinecone https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pinecone/ https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...

timokoesters 3y ago
P2P sounds great and I'd love to implement it when it is ready. I think Conduit is pretty well suited for this. But it will still take quite some time until Matrix is ready for p2p clients, it needs some significant protocol changes: https://arewep2pyet.com/ https://arewep2pyet.com/

Arkanosis 3y ago

Hi Timo! I've been using Conduit for 10 months now and I love it. Thank you so much for it! I've two questions: - Is there any concern to have with regards to its future when you finish university? You seem to be by far the most active contributor and I'm worried the project is still dependent on how much time you can afford to put into it; - What is the best way for a Rust / Linux developer to do a first impactful contribution to Conduit? With 155 open issues on GitLab at the moment and no problem really standing out for me as a user, I don't know where to start :p Thanks! BTW I hope you land a great job; I'd happily recommend you where I work, but we don't have any office near Dortmund unfortunately… Feel free to reach out to me if Dortmund / remote is not a requirement.

timokoesters 3y ago
Thank you for the kind words! 1: I can't say how much time I will have for Conduit, but I think the project is in a good shape and I think it can reach a stable release without me working full time on it, but of course it will take longer. 2: I think a good way to start is to hang around in the Conduit Matrix room and see if any issues pop up. Often these are relatively simple things like "these logs should have more details" and are a good way to get started. I will also use this opportunity to link my LinkedIn profile: https://www.linkedin.com/in/timokoesters/ https://www.linkedin.com/in/timokoesters/
- Arkanosis 3y ago
  Thank you for your answer. 1: That's a relief :) 2: I've just joined `#conduit:fachschaften.org`; we'll see if I can help somehow.

rjvs 3y ago

Hi Timo, is there a document somewhere that describes how Conduit compares feature-wise to Synapse or to the Matrix spec? It’s not clear to me if the goal to develop a fully-featured matrix server, or if there is some subset of scale or functionality that you’re aiming for; could you comment on that?

timokoesters 3y ago
Hi, the goal is to create a fully-featured server that works seamlessly with all Matrix clients. The one notable exception is that we will not implement support for "outdated" room versions, which means that there are some rooms that are unjoinable because they are too old, those should be upgraded to a more recent room version. I'm also prioritizing features needed for smaller instances, instead of things like user management or horizontal scaling.

sydbarrett74 3y ago

Timo, Thank you and kudos for all of your hard work on this. I will definitely be checking your project out. :) -sydbarrett74

treyd 3y ago

What would you say is your biggest frustration with Matrix's design as a protocol? I have some of my own opinions writing bots and such but I'm curious about the perspective of a homeserver implementatiom maintainer.

timokoesters 3y ago
I think the model of having all events form a giant graph is overengineered. They tried to cope with this by introducing things like "fast room joins", but I think they are flawed and treat the symptom rather than the cause of the problem. Servers should only replicate the very core part of a room and fetch remaining information on demand. But I'm working together with the Matrix team to improve this in the future. I think most other things in the spec are necessary complexity. It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on, but they allow Matrix to have a lot of great features. What problems did you encounter writing bots for Matrix?
- treyd 3y ago
  The impression I got from using Ruma's bot SDK library was that bot clients needed to keep around a lot of state involved in syncing the room to handle new messages properly. Which largely lines up with what you said, although maybe it's possible I could have gotten away with a more lightweight solution since I wasn't making a stanalone client? > It's annoying to work on logic for threads, spaces, read receipts, read receipts in threads and so on Another impression I got was this was kind of an excessive amount of duplication (and other duplications) that could have been avoided had a bit more forethought been put into the protocol design, especially with how these features interact with the e2ee.