IDRs

IDRs encapsulate the multiple identities of an individual json object within the locker into one standard string, a URI. There are two distinct categories of attributes represented, global and local. The global being what is this object's identity to the world, that it's a tweet, on twitter, with a given id, for instance. The local being that within the locker it was encountered in the mentions for a specific connected account. By using uri's, all of these attributes can be easily programmatically accessed and manipulated via standard libraries without worrying about encoding issues and compatibility problems.

tweet://twitter/mention?id=jeremie#103976138702983168

require('url').parse('tweet://twitter/mention?id=jeremie#103976138702983168',true)
{ protocol: 'tweet:',
  slashes: true,
  host: 'twitter',
  hostname: 'twitter',
  href: 'tweet://twitter/mention?id=jeremie#103976138702983168',
  hash: '#103976138702983168',
  search: '?id=jeremie',
  query: { id: 'jeremie' },
  pathname: '/mention' }

• tweet - the generic type name, specific to the service (global
• twitter - the service's generic name (global, always 'twitter' or 'Facebook' etc)
• mention - the context in which the object was discovered (local)
• id=jeremie - the account name from which the object was discovered (local, in the locker it's usually 'twitter' or 'twitter-1' for now, until we can clean this up using profiles during auth to default to the account id)
• 103976138702983168 - the unique id assigned by the service (global)

Another example IDR would be post://facebook/wall?id=630347951#630347951_10150351352017952 that would break down just like the above tweet.

TL;DR

There are an innumerable amount of things that need to be "addressed" within the locker, and not just externally, but strong internal references to the actual local storage identifiers as well. These addressible entities are not simple GUIDs either, they have a critical set of metadata that makes up their identity, most importantly the originating network, the type of entity it is on that network, and the unique identifier assigned to it by that network. Often equally important is the context in which it was discovered from that network, the common example being a tweet, from twitter, encountered as a mention. Other locally important attributes sometimes need to be tracked as well, such as the account id that the entity originated from.

All of these attributes are required to uniquely resolve a reference to an entity to the actual data, either locally (requiring the context and account bits) or globally (just the type, network, and id bits). While programmatically each of these is independently important, as identifiers they need to be stored in a consistent way as a unique string for simple KV lookups/matching. There is a standard and built-in library perfect for this job, URLs! They're also very familiar to read and the tools handle all the encoding, parsing, etc. The path and query string can also be used to carry additional attributes as needed in the future.