hey @LukeStampfli — I'm seeing PR 512 merged into MLAPI repo already.
should we make this ready to be merged and get it in now then close the tracking issue too?
do we need any adjustments on this or do you think it represents the work OK already?

hey @LukeStampfli — I'm seeing PR 512 merged into MLAPI repo already.
should we make this ready to be merged and get it in now then close the tracking issue too?
do we need any adjustments on this or do you think it represents the work OK already?

This PR has been reverted 😢. Still waiting for someone to notice this lonely RFC.

hmm, in this case, I wonder what @wackoisgod would think about this.
Andrew's team will be providing UTP transport implementation to MLAPI using our abstract transport interface.
Based on their feedback, we might have this direct way of passing connection credentials (in this case IP:Port address) on the interface.
If they'd prefer having it abstracted away and not explicit as IP:Port or any other struct-based implementation, we might reconsider.

(nothing but my 2 cents) Also, I think we could have alternatives but as you outlined in the RFC, we might want to have another interface just for non-IP:Port based connection credentials as per your example, Room & Region.
In that regard, I personally think we should not standardize this at all and leave it up to developers to configure their specific transport instance.
I'm imagining our abstract transport base to not have any connection credentials (maybe Dict? would it make sense at all?) and devs implementing UTPTransport, UNetTransport, MyRelayTransport and then configuring their specific transport instances directly but not through the transport interface: directly as ((MyRelayTransport)transport).ConnectionCredentials = new MyCustomCredentialsStruct(...);

So I agree with @MFatihMAR that we should likely make this a little more flexible because not everything could be a simple ip and port for example Relay is not its actually a string join code. I could imagine maybe there is a transport that us using HTTP long poll or something that is just a url; So I agree that we should look at something that allows for users to define their own solution if need be or at least define some data that can be interpreted by the transport.

With that said I would like to hold off on any changes to the transport right now until we can just look holistically how we want the transport to be in the future because I think there should be much broader changes in how we represent the transport and we could take into account connection data.

I agree with what both of you said. I think we need to re-explore this at a later point in time and come up with a better solution. I'll close this RFC as it has been open for way too long already.