We present here a convention for linking to users across social networks.
Social networks have evolved into a category of their own. They are not like most Web sites in the traditional sense and even when considered modern Web apps, they are a special type of application. They have become our new digital personas. Email used to be our online persona. Blog URLs (especially when coupled with OpenID) have also served that purpose. Instant messenger IDs and online forum handles have been also serving as our partial online identities. Social network personas combine elements of all of these: Personal blog/comment URLs, email, discussions and real-time chat.
We often see people including their Twitter usernames ( e.g. @rajivpant ) as contact info on presentations, business cards and email signatures. This has helped make Twitter even more popular. There is a need for a simple, short and consistent way to refer to a user on any social network.
We propose three alternative options. A. @username@socialnetwork , B. socialnetwork:@username and a third option as conventions to link to users across social networks. Why? Because Twitter has already made the @username widely popular. These conventions are backwards compatible and extend the existing convention to include other social networks.
Option A. @username@service
On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as @rajivpant@twitter and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. @rajiv.pant@facebook , @rajiv.pant@linkedin , @rajiv.pant@google and @rajivpant@tumblr
Option B. service:@username (URL format)
On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as twitter:@rajivpant and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. facebook:@rajiv.pant , linkedin:@rajiv.pant , google:@rajiv.pant and tumblr:@rajivpant
Option C. sn:username@servicedns (Unified URL format)
A third option, and one that we originally proposed is to have social network URLs like sn:[email protected] where sn:would be a universal social network protocol handler that would be distinct from the email URL syntax of mailto:[email protected] . It would avoid the need of per-site handlers like twitter:@rajivpant on iOS that are becoming common.
One benefit of having the @ (or + in Google+) at the beginning is that the text editor can start to autocomplete the name for you. It would still continue to do that. However, when you type @@, it would first give you a list of other social networks and then could even show you names from your connections on other social networks if you have authorized it!
In your contacts (e.g. MacOS Address Book), you could then enter someone’s social network addresses using the @username@socialnetwork or the sn: URL format. When someone clicks on an @@ or sn: link, the URL handler would first look to see if there is registered custom app for that domain name (e.g. Twitter client on MacOS or iOS) and then launch that app. If no app is registered for that social network’s domain, it would map it to an http: URL like https://twitter.com/rajivpant , https://www.facebook.com/rajiv.pant or https://profiles.google.com/rajiv.pant
This would avoid social network specific URL formats like twitter:@rajivpant proposed by option B.
For brevity, the URLs could simply be in the format @username@twitter , @username@facebook , @username@linkedin and @user.name@google If such shorter forms are adopted, then each social network’s brand name could be registered via a system of registries or it could default to .com if the full domain name isn’t specified. We could also have shortcuts like @rajiv.pant@fb or fb:@rajiv.pant since Facebook owns the fb.com domain at the fb: URL schema on iOS.
Either way, a number of people have agreed that this problem needs to be solved. Which option do you prefer, A, B, or C?