We discussed irl that just using a #[cfg(test)] flag should be enough, no?

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

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.