Adoptability Polling Requirements

[andorsk]

What is your requirement for adoptability in the next v2 stack?

[jospencer-460]

I struggled with this poll question, because the adoption of the protocol should be able to be adopted broadly (a high level). Whether it is successful or not depends on time and the provision of adoption enablement strategies (bridges, interfaces, etc.)

[andorsk]

@jospencer-460 I hear you, and I'm happy to have another suggestion on how to structure this poll. I would push back a little, and contend that in order to effectively move the needle here on v2, we need to have some idea of adoption requirements and how to get there. Otherwise we end up with a spec doesn't actually get used, which is worthless IMO. How it interacts with other interfaces, bridges, etc, is important to think about when considering the larger ecosystem and driving adoptability.

As an example: If an HTTP bridge is required to get adoption into most major ecosystems, that becomes a technical requirement/focus of compatibility and potentially a key consideration for our spec. If, for our spec, building an HTTP bridge is incredibly difficult, I think we've probably made a serious design flaw, or at least, we need understand the weird position we've put ourselves in w.r.t our larger adoption goals.

[jospencer-460]

I agree. Adoptability is a significant consideration in a spec.

Having said that, we should be aligned with the TSP work. If we need to propose an interim solution (HTTP or other) because the TSP isn't defined, we can do, noting that this is an interim specification that will change to align more specifically with the TSP. Ideally, the TRP should be agnostic to the underlying technical solution (transport protocol etc.), or at least flexible to many options which might be supported by each TR.