Draft informational spec to offer guidelines for Relaynet service providers

[gnarea]

Executive summary

Relaynet apps will look and feel like regular Internet apps when the Internet is available, but building them in such a way that they tolerate delays will have profound implications on the UX and, to a lesser extent, the implementation. For this reason, we should write an informational spec to guide Relaynet service providers -- Or, alternatively, document such guidelines on the website.

Is your feature request related to a problem?

Yes. Relaynet service providers can't rely on apps being able to communicate in near real-time, so they'll need guidance in addition to easy-to-use endpoint libraries.

Describe the solution you'd like

The following should be part of the guidelines:

• All Relaynet apps are inherently offline first, so UX designers should be mindful of that and employ offline first best practices.
• Developers should embrace asynchronous messaging and not try to shoehorn RPCs on top of Relaynet (that can still be done but should be avoided unless integrating a legacy system). Quoting an excerpt from the Enterprise Integration Patterns book (page 54):

  (...) thinking about the communication in an asynchronous manner forces developers to recognize that working with a remote application is slower, which encourages design of components with high cohesion (lots of work locally) and low adhesion (selective work remotely)

• Authentication:
  • First-party applications can rely on Relaynet's built-in authentication, without the need for bearer tokens, etc.
  • MFA should be compatible with DTNs. Consequently, one-time passwords mustn't be time-based (OTP) or challenge-response-based, but they can be sequence-based (HOTP).

[gnarea]

Done earlier this month: https://awala.network/service-providers/