The introduction pattern allows one cloud to introduce two clouds to each other. This is useful for sharing and delegating and forms the basis for social products in SquareTag.
SquareTag gives everything a cloud that can store data and run programs. These clouds have an independent identity and exist apart from the person who owns and controls them. For example, my truck has a cloud that is separate from my cloud. Data about my truck is stored on and apps run on its own cloud. I have an owner relationship with my truck's cloud, giving me what amounts to superuser authority over it.
SquareTag also allows each cloud to create multiple, independent channels that other clouds can use to interact with it. Channels can have one ore more attributes and form the basis for intercloud relationships. These relationships are why we call SquareTag a social product platform. The relationships allow interactions between me, my friends, and the things we own.
One of the reasons that my truck needs it's own cloud—rather than merely storing its data in my cloud—is that it needs relationships that are independent the ones I have with it. For example, my wife is also an owner of my truck. She needs the same rights and privileges with the truck's data and applications that I do. If the truck's data and apps were stored in my cloud, authorizing someone else, like my wife, to share them is messy. Moreover, I might want to share the truck, with attenuated rights, with others. I may sell it someday and want to pass on its cloud to the new owner. The modeling and implementation are much easier if the truck exists independently in cyberspace—the same way that it exists independently physically.
Suppose my neighbor Tom wants to borrow my truck for the weekend. I not only want to give Tom the key to the car so he can use the physical vehicle, I also want to share the truck's cloud with Tom so that he can have access to some of the data and apps that the truck's cloud provides. Perhaps he's going to buy gas or perform some maintenance and needs to record that. Or maybe he needs access to the GPS information streaming from the truck's OBD-II port and into the truck's cloud. Or maybe, in the future, the truck's cloud is what controls its door locks and ignition.
That presents the basic problem: I need to share the truck's cloud with Tom's cloud in a way that he can make use of it. Tom needs a relationship with the truck. Since I already have a relationship with the truck and with Tom, I'm going to introduce the truck's cloud to Tom's cloud. I call this the introduction pattern. The following digram and description show how this is accomplished.
SquareTag is built on top of CloudOS. CloudOS handles all of the cloud interactions necessary for the introduction pattern to work.
- The relationships in the diagram labeled (1) exist at the start of our scenario. Anything that is going to be introduced needs at least one existing relationship with sufficient rights to perform the introduction.
- Tom's cloud (with whom I have a pre-existing relationship) asks for an introduction to my truck. This could be specific (i.e. Tom knows the truck's well-known channel) or more general. Of course, Tom could ask for the introduction out of band or I could have initiated the introduction on my own.
- My cloud creates a new channel to the truck's cloud with the correct relationship attribute, in this case borrower, and sends it to Tom.
- Tom uses the channel I've sent him to create a relationship with the truck using the subscription pattern.
Tom and my truck now have a full-fledged relationship with a relationship attribute of my choosing. Tom can use that relationship to do anything that the borrower channel attribute allows.