chatmail
Do not use default iroh relays
We should not use default iroh relays, but only connect to other peers that have relays if we don't have our own relay: https://github.com/deltachat/deltachat-core-rust/blob/36f1fc4f9d64520d99830c08b25e9328a28882aa/src/peer_channels.rs#L208-L210
However, disabling it now will break Rust tests because they don't connect to IMAP and cannot get the relay address from IMAP METADATA. Tests should be moved into Python deltachat-rpc-client first.
I still think we should use the default relay because communication becomes impossible if no member in a group has a chatmail server. (no relay and direct addresses => no direct connection). For us, everyone uses chatmail, so we don't really care, but I don't know how the situation is in Cuba. If you are really concerned about security, you can make sure that you yourself are on a chatmail server or disable realtime completely. @hpk42 @r10s @adbenitez
On Mon, May 20, 2024 at 06:43 -0700, Sebastian Klähn wrote:
I still think we should use the default relay because communication becomes impossible if no member in a group has a chatmail server. (no relay and direct addresses => no direct connection). For us, everyone uses chatmail, so we don't really care, but I don't know how the situation is in Cuba. If you are really concerned about security, you can make sure that you yourself are on a chatmail server or disable realtime completely. @hpk42 @r10s @adbenitez
Default iroh relays might upgrade, and break the wire protocol, thus bricking previously working released DC app versions.
So if anything, we need an own fallback relay where we control the relay server version. Discussed yesterday with @link2xt that "ir.testrun.org" might be such a central relay, configured as fallback if no chatmail-one is available. It could run on "b1" for now, or be created on a separate vm. As we are still experimental, it doesn't matter that much right now.
Breaking the wire protocol is also an issue when we host the relay server ourselves as newer versions of deltachat will probably adopt the latest protocols and thus need a new default relay server also. This leads to the solution where we create default servers for every breaking iroh version so that people can keep communicating even with older iroh versions. One problem that still remains is that every iroh protocol break will then divide the communicating users as old apps will not be able to communicate with apps that have a newer version of iroh. This can produce all kinds of errors that we need to handle because core will not know that this happened. I think our best bet in case of an iroh wire break is that we silently ship two versions of iroh. The one that works and the breaking change. We then continue to use the working version for 3 moths or a release cycle and then switch all devices to the newer iroh version simultaneously hoping that most users have updated their iroh version by then. In the other case, we can show an error message that peer channels are no longer available which should be sensible enough IMO. Anyways, I don't think Iroh will break protocol too often, right @dignifiedquire ?
An update on the current plan for the wire-protocol stability of iroh:
- We're aiming to make a 1.0 release next year.
- From that point on we'll keep wire-protocol stability for all bits and pieces.
- Before then there's bunch of changes planned, but we'll roll this out gradually while preserving backwards compatibility.
- In some 1.0 release candidate this compatibility will be dropped.
We might well end up running old relay servers for much longer, that's not decided yet.
Why bother dropping the backwards compatibility to current versions at all? There are reliability and abuse issues with the current version that can not be addressed without changing the wire protocol. While they can be mitigated to some extend they can never be entirely fixed. Keeping the current protocol alive for longer only means we are exposed to more for this for longer and that we'll have to try hard to fix issues that we know can be fixed better.
How will this not happen after 1.0? We're adopting approaches more deeply integrated with QUIC itself, and draft standards that have had more scrutiny from the QUIC ecosystem and can evolve with it. While this is not a guarantee it increases our confidence that we'll be able to keep that version current for much longer. But at the end of the day protocols eventually get replaced or evolve anyway, for example we no longer use SSL 2.0 either.
I think our best approach is to hard code a delta-hosted relay server in dc-core which is stable for as long as we want it to be. We can then for wire-breaking changes create another relay server and silently ship that new URL until most devices have the new update and then switch all devices to the newer version just as described before. @link2xt @hpk42
Let's for now close this. We don't want to depend on a central service for this, but hosting our own central relay is even worse. chatmail servers will host their own iroh-relay soon (once https://github.com/n0-computer/iroh/issues/2870 is resolved and clients are updated) and non-chatmail users will used default iroh relays.
chatmail servers will host their own iroh-relay soon
Maybe, if a user has a chatmail account (or several ones on the same server), it makes sense to use the iroh relay for this account for non-chatmail accounts also? For more decentralisation and reducing load on default iroh relays
Maybe, if a user has a chatmail account (or several ones on the same server), it makes sense to use the iroh relay for this account for non-chatmail accounts also?
Currently we don't share anything between accounts automatically. Users may not want to reveal that you are using some particular chatmail server by sending its URL in iroh header.
For more decentralisation and reducing load on default iroh relays
I think we don't put much load even if xdc updates are relayed.
Being able to set iroh relay manually in the UI and see which one is used so user can copy it from one account to another can work, but does not seem worth implementing and adding more technical options for me.
Users may not want to reveal that you are using some particular chatmail server by sending its URL in iroh header.
True
Being able to set iroh relay manually in the UI and see which one is used so user can copy it from one account to another can work, but does not seem worth implementing and adding more technical options for me.
But having a config option in Core would be nice to set it via environment.