Retrofitting Linkets with DNS

In earlier articles I described a linket. It is a Unicode string which maps to a deep link. The latter is 2 things — an id of an app in a (mobile) app store, and a network address of an instance of the app.

linket (Unicode) = what (app) + where (network address)

Whereas a domain is an ascii string that maps to a network address.

domain (ascii) = where (network address)

DNS is the way to map quickly between a domain and its address. And DNS is global, whereas linkets are just starting to be introduced. One question is, given a linket and a deep link, is there a way to store in in DNS? Yes. Start with the linket. Each symbol is a Unicode character. Converting this to ascii format was done by people working on i18n of domain names. A function called ToASCII() is used.

Domains are hierarchical. Linkets in general are not. But we can use the appId field of the deep link. An appId for an app might be

123456.where.com

Suppose the linket we want to store in DNS does not really have an associated mobile app. We can just use the appId field and put in (eg) .com.cn. So the linket is XYZ (represents 3 Chinese symbols) and the appId is .com.cn.

[ XYZ ] = .com.cn :// (blank)

and the DNS entries are

ToASCII(XYZ).com.cn

But suppose Jill is the owner of the linket [XYZ], and Ralph owns a different linket [DEF], where XYZ and DEF are Chinese symbols. And both linkets use the same app, with id 123456.where.com. The TLD of the latter is where.com. Someone clicking on either linket might have an option to find the associated domain. These could be ToASCII(XYZ).where.com and ToASCII(DEF).where.com, if those domains exist. They do not have to.

Now imagine where.com has 2 mobile apps, with ids 123456.where.com and blah.where.com. The previous steps did not distinguish between the different apps made by where.co. We extend the steps to say that the site has the domains {123456, blah}.where.com.

This assumes that the app ids were in the convenient format of {id}.where.com. In some languages like java, a reverse field format is used,like com.where.123456. But this is easy enough to detect in app id formats. A program can take an id like com.where.123456 and flip the order, to get the standard domain hierarchy of DNS.

This should work. But a deeper problem is that this might be a retrograde step. Like this early car:

It is in the format of a horse drawn buggy. Modern cars might be said to have begun once the dragging effect of horses were left behind. Likewise, representing a linket as data stored in DNS is possible. But do you really want to do this?

Remember also a difference between domains and linkets. When we have a website, that means the domain is associated with an address for at least 24 hours. (Usually much longer.) Whereas a linket with a deep link means the phone of the linket owner has an address for 1 or 2 hours.