Over the past few weeks I have been working on mechanisms for making friends and instant message work across the Hypergrid. These social functions have been a goal since the beginning of the Hypergrid. The big rearchitecture work we did in OpenSimulator 0.7 that strengthened security was also meant to support these functions, but, of course, we weren’t really sure how well the new architecture would hold when these functions were actually implemented. Well, now I know — it handles it just fine. Let me explain how friends and IM work over the HG, the challenges, and the current limitations. Keep in mind that these new functions are still experimental, and subject to changes and improvements.

[UPDATED 6/2/2011] Added pictures!

Here’s a base case scenario. You run your own OpenSimulator VW, and you visit OSGrid with an Hypergrid teleport. Once you get to OSGrid, you meet someone there — maybe from OSGrid, maybe from some other VW –, and you want to add that person to your list of friends. People in your friends list acquire certain rights over your information shadow, and vice-versa: they may be notified when you login/logout (and vice-versa), they may change your objects (and vice-versa), they may see you on the map (and vice-versa), etc. An entry on your list of friends is a persistent reference to a user, so you can easily IM them, see their profile, etc.

Up to now, it wasn’t possible to hold references to users in other services. With these changes, that has become possible. An HG friendship establishes 2 pairs of data, each stored in each user’s user services. That data is “signed” with a random number known only to the 2 services and the simulator where the friendship was established, so that, even if the user services (hg friends, to be precise) are exposed to the Internet, no one but the holders of the signature can manipulate the friendship data. Here lies warning #1: don’t make friendships in worlds that you don’t trust — instead, ask the person to come to your world, or vice-versa, and establish the friendship there.

Independent of that, HG friendships established while you are Hypergriding require an additional confirmation step once you return to your world. Here’s a typical interaction: you go elsewhere, you ask someone to be your friend (or vice-versa), the viewer will tell you that the friendship was established. When this is done within your world,  the interaction ends there. With HG friendships, once you return to your world, or login the next time, you will be once again prompted for confirmation of the friendship. This is so that your friends list won’t get spammed with bogus entries sent by malicious components. Once you confirm that second time in your home world, the friendship is finally established.

Your HG friends can, by default, see your logins and logouts of the virtual world — to some extent, and this is where things are still work in progress. So far, they will be notified if they are in their own worlds. However, they will not be notified if they are elsewhere — not yet, at least.

This starts to show the really interesting challenges of these social functions done in a decentralized architecture: you can “move,” that is, your client doesn’t have a communication channel with one single server over your entire session; instead, your client “moves” from server to server. Keeping track of where people are (that is, which server their clients are talking to) is a major challenge! — especially without central servers. But I’ll come to this further down when I explain IM over the Hypergrid.

Another interesting aspect of the design of friends over the HG is the rights to edit each others’ objects. Within one world, once you give someone the right to edit your objects, that right holds for all regions of that world indiscriminately. With the Hypergrid, we have the option to differentiate between the worlds, and give rights to edit objects per world. In other words, if we are friends and I build things in your world, I can give you the right to change my objects in your world; but I may very well not give you the right to change my objects in my world. (or vice-versa). Right changes affect only the world where the action takes place: if I change rights in my world, those new rights will be stored in my world only, they will not be disseminated. When you HG-TP to a new world, you will be notified of the rights that you currently have over your friends’ objects there, if different from those in your home world.

This is a subtle semantic change. I like the more expressive capabilities, but I understand that people coming from walled-garden worlds may be somewhat confused by these extra options. We’ll see how this design decision fares as we go along.

One thing that is still work in progress: rights to change objects in 3rd-party worlds.

Now… Instant message.

The base case is very simple: you are in your world, your friend is in her world; you IM her, she IMs you back. Works. Simple. It works because the reference to your friend includes the URL of her world, so your world can forward the IM appropriately. And vice-versa.

Scenario #2: you jump to your friend’s world, you IM her and she IMs you back. No problem, that’s a local IM. Works. Simple.

Scenario #3: you go back to your world. Your friend IMs you. Not so simple! Your friend’s world needs to detect that you aren’t in her world anymore and needs to find out where you are. Your friend’s world fails once, but has a reference to you, including your world’s URL, so that’s what it uses to forward the IM.

Scenario #4: you HG-TP to a 3rd world. Your friend IMs you. More challenging! Now your world needs to find out where you are. Your User Agent service knows that, and forwards the IM to the world where you are.

Scenario #5: in that 3rd world, you IM your friend back. This is really challenging! — because that world knows absolutely nothing about your friend. No worries, it still works in this case. It works like this: that 3rd world knows about you, so it asks your world if it knows about the user you are trying to IM. Basically, all that world needs is a URL to deliver the IM. Prompted with that information request, your world first looks if the user is a co-resident of yours; if it is, it sends the URL of your world; if it’s not, as is the case in this scenario, your world checks if the requested user is a foreign friend of yours, which is the case here. Having found it, it sends the URL of your friend’s world to the 3rd world, so that the IM can finally be delivered.

Scenario #6: in that 3rd world you meet someone, and you start IM-ing with that person, who is not in your friend’s list. Then you go back to your world and you send an IM to that person in the window that is still open. Oops! — this won’t work! — at least for the time being. The reason it won’t work is because your world knows absolutely nothing about that person: it’s not a co-resident, it’s not visiting your world and it’s not in your friend’s list. Your world has no means to find the URL of that person’s world to send the IM to. Work in progress…

Note that throughout these IM interactions your location in the Hypergrid is known only to your user services; it is not disclosed to the worlds with whom you are IM-ing. Those other worlds simply forward the IMs to your world, and it’s your world’s responsibility to forward them to wherever you are. This is an important privacy-preserving design decision.

As I said, HG friends and IM is still work in progress. Use with caution, and be ready to go down to your DB and delete records in the friend’s table if things go awry. If all testing goes well, it will be in 0.7.2.