[ADC-Ext 1.0.8] OID - Exchange Online IDs

The purpose of the OID command is to allow users to exchange information about their accounts on various online services. The name of the command has been intentionally chosen to be similar to OpenID, although its spread is broader.

A new command is preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. It also allows for more flexibility: multiple profiles of the same type; multiple identification parameters.

Parameters of the OID command:

  • Unnamed parameter in first position to designate the service this command is referring to. Known services are listed in the “Known OID services” document. Before using a new service, make sure it isn’t on that list and let ADC managers know about it.
  • Optional named parameters whose meanings depend on the service in question.

OID commands support all contexts (hub-client, client-client). It is supported in the client-client context were users to want to avoid their OID information travelling through hubs. Hubs may request OID information from clients. Clients may request OID information from hubs.

The requesting party MUST send an OID command with a service parameter only (no optional parameter). The responding party MAY answer with an OID command containing that same service parameter, and relevant optional parameters.
The responding party MAY send multiple OID commands in response to one request.
Any party MAY at any time send an OID response without any prior request.

Known services:

  • DCBase: ID is the DCBase forum member numeric identifier.
  • Facebook: ID is the public Facebook ID (that appears in a profile page’s URL), NI (optional) is the friendly name.
  • Google: EM is the Google email.
  • LoL: SU is the League of Legends summoner name; SE is the server identifier, which MUST be one of “br”, “eune”, “euw”, “kr”, “na”, “tr”, “ru” that stand for, respectively, “Brazil”, “EU Nordic & East”, “EU West”, “Korea”, “North America”, “Turkey”, “Russia”.
  • MSLive: EM is the Microsoft Live email.
  • PSN: ID is the PlayStation Network ID.
  • Twitter: ID is the Twitter profile ID (that appears in a profile page’s URL), NI (optional) is the nickname.
  • Yahoo: EM is the Yahoo! email.

I have highlighted the above as it may be a novelty in ADC. I believe such a requirement is necessary since this feature is based on so many external sources.

Updated the first post:

  • The requirement to use known services has been loosened to allow for more flexible development.
  • Added: “Any party MAY at any time send an OID response without any prior request.”
  • Removed named optional parameters; they are left to be defined by each service.
  • Renamed the parameters used by the LoL service.
  • Renamed the parameters used by the PSN service.

the LoL plugin at https://code.launchpad.net/~dcplusplus-team/dcpp-plugin-sdk-cpp/LoLPlugin implements this for the LoL service (only D-type messages).

I’ll push this in one week to ADC-Ext, in case someone have additional changes in mind.

PSN is technically SEN (Sony Entertainment Network) these days, but that is just semantics.

Some thoughts out of the top of my mind:

  • There is no way to get a client to say he wants an OID removed, I think in such case sending an empty OID for the desired network should be enough.
  • It would be great if we could get a little bit of (optional) INF like support from hubs for BOIDs/FOIDs, the idea would be the hub replaying this to connecting clients supporting the feature so clients don’t have to worry about that (I can program something like this for adch++ if needed).
  • Similarly it would be cool if clients announced support of this feature in their FOURCCs to prevent other clients from spamming clients not supporting these.
  • Also it would be cool if clients could send a propper STA code in case they are not willing to share said OID with the user/or don’t support it. This way the client would stop spamming the other client for the OID.

are you sure? i still see PSN being used all throughout http://us.playstation.com/psn/. in any case, what matters here is viewing someone’s gaming profile or getting his ID to add him as a friend. which of PSN / SEN can do that?

an OID command with empty parameters is indeed allowed, so i guess it could be the implicit way of doing that.

a problem with this is that OID handles various disctinct services; support for OID doesn’t mean support for one particular service. a feature flag couldn’t help determine if a particular OID is going to be useful to the receiver. for a service popular enough for the hub to advertise, there is no harm sending the message to everyone.

i’m wary of adding an STA code… in this case, the responding party could simply send an OID with empty parameters to signal its unwillingness to share it.


So conclusion: technically both exist but the accounts are shared, which imo means that both service names should be accepted. They got their branding all screwed up right now, because the former name has more pull with people… what will happen with the advent of PS4 is anyone’s guess but probably that is when they will try and drive in the new name on the gaming front.

Updated to clarify empty parameters and the dissimilarity with INF, which assumes continuous information updates:

I’d like a note on whether services are case sensitive. (I’d prefer case-insensitivity.)

Made services case-insensitive and rephrased the note about unlisted services to be more formal:

Changed a MUST to SHOULD in the LoL service (servers can change in the future):

Renamed OID to OIR and added a new OID command with the purpose of providing up-to-date INF-style information:

Added ONID support for OID commands and adjusted related hub-side rules:

This is now in upcoming ADC-Ext 1.0.8. See ADC-ONIDServices.txt for the services.