Why inventory transactions fail, and what you can do about it

[SL blogs are shaken up by the questionnaire Pink Linden sent to Xstreet SL merchants. Among many other things, the survey asked whether merchants would pay a premium for guaranteed deliveries. As far as I know, this is the first time for Linden Lab to publicly admit that failed deliveries are a problem.]

Everything is an Instant Message. Not only if you send an IM to a friend, no, things like teleport requests, force teleports, teleport acceptance, teleport rejection, friend requests, friend acceptance, friend rejection, object IMs, busy response IMs and so on and so on. My friend Katharine Berry counted them once and came up with 40 different types of IM's in SL.

Inventory offers are - behind the scenes - IM's as well, and this is the reason why so many inventory transfers fail!

During our work on the Designer Showcase Network, Rika Watanabe and I encounterend a surprisingly high number of inventory transactions failing, and after some digging we found that this is a common problem for other delivery systems like Subscribe-o-Matic or even XStreet SL. There are a few scenarios, where failed transactions can happen:

Case 1 - Recipient is in "busy" mode

• Sender is an avatar
  Never fails, object (or notecard, texture, etc) can be found in "Trash" folder, sender gets a "... is busy" notice.
• Sender is a "Buy" object
  Never fails, bought merchandise goes to where it is supposed to go (its own folder or the matching system subdirectory)
• Sender is a scripted object (e.g. "Pay" object or "Touch" vendor or subscription system)
  Always fails! The scripted object uses llGiveInventory, which does not have any feedback functionality. A paid for-purchase will be irrecoverably lost, and what is even worse, the merchants transaction history will show no anomalies.

Case 2 - Avatar is offline - no capped IM'S

• Sender is an avatar
  Never fails, upon login of the recipient a blue box appears via which you can decide to accept or decline the delivery. An IM is generated "Xyz sent you inventory" - those IM's go to your offline email address if specified. Those IM's also count toward your IM cap.
  
• Sender is a "Buy" object
  Not possible when you are offline
• Sender is a scripted object (e.g. DSN dropbox, S-o-M or XStreet delivery)
  Never fails, upon login of the recipient a blue box appears via which you can decide to accept or decline the delivery. An IM is generated "Xyz sent you inventory" - those IM's go to your offline email address if specified. Those IM's also count toward your IM cap.

There is a limit to how many IM's an avatar can receive while being offline. I did not find an official statement as to how many IM's it takes to cap, several discussions on forums and the JIRA suggest that the cap will happen after 15 IMs. While you still get offline-IM's that you received something, what you actually find in your inventory is different:

Case 3 - Avatar is offline - IM cap limit reached

• Sender is an avatar
  Oddly enough those mostly work. Sometimes you get the blue box to accept, sometimes you don't get the blue box and the inventory offer goes straight to the matching folder. An offline-IM is being generated.
• Sender is a "Buy" object
  Can't happen when you are offline
• Sender is a scripted object (subscribe-o, XStreet dropbox, Deliverator, DSN, etc.)
  Always fails! While you receive an offline-IM, the objects are nowhere to be found and can't be recovered. What makes it even more annoying is that the transaction logs of the sending systems have no way of telling whether you actually receive the inventory offer, or not.

Inventory transfer success matrix
	Busy	Offline Non-capped	Offline Capped
Avatar sends	ok	ok	sometimes
Buy object	ok	n.a.	n.a.
Scripted Object	fails	ok	fails

The culprit in those failed cases is the unholy union of the llGiveInventory function in the LSL scripting language and the IM-based delivery system. The function only gets a recipient-ID and an inventory object, however it has no way to check whether the transaction was actually successful. It's basically a shot in the dark, and given the vulnerability with capped IM's as shown above, can only be described as incomplete.

In theory a script could check if the recipient is only, thus avoiding the capping problem. This approach has two drawbacks:

1. Scalability
   A script only delivering items when an avatar is actually online might end up with an immense backlog of deliveries and ultimately meet memory issues
2. Busy
   There is now way to find out whether an avatar is busy from within an LSL script

What can I do to avoid inventory transaction loss?

There are a few things each of us can do in order to ease the situation. In case of XStreet SL (or similar services) purchases, the easiest thing is to make sure you (or the recipient) are actually logged into SL and not-busy during the time of purchase.

For systems like DSN, Subscribe-o-Matic, Deliverator and other services that send you objects at a schedule you can't influence there is only one way to raise the success rate: avoid capped IM's!

A few methods:

• Leave "spammy" groups, e.g. groups with a lot of group notices
  A group like FashCon can easily reach your capping limit on a Saturday evening within 10 minutes because of the massive amount of group notices. In case you can't leave the group (e.g. because it is a land group), at least switch off group notices. The notices are still available in the groups archive for a while.
  
  
• Unsubscribe from lists with high activity
  I was signed up to some Subscribe-o-Matic systems where there was almost daily a new notice from the shop owner. While it is commendable that the merchant keeps such a close communication with their client base, this actually adds a lot to IM-capping. In fact lately I am very reluctant to subscribe to a SoM or Hippo-Group at all, and have unsubscribed from many as well.
  
  
• Reduce offline-messaging objects
  Many scripted objects can send their owner various status information, for example security orbs if someone has trespassed on your naughty skybox. Usually those devices use the llInstantMessage function which - right - sends an instant message that would add to capping if you are offline. With llEmail exists a slightly more complex mechanism, that instead of sending an IM sends an actual email to an actual off-world email address. A script could even be designed to detect whether the recipient of a notice is online and use llInstantMessage or offline and in that case use llEmail. This should become a level of expectation to scripters to help avoid capping IM's.
  
  
• Ask your friends to cooperate
  Many people send IM's or objects to friends who are offline. The intentions are meant well, however those IM's and transactions also add to each person's IM cap count.

Anything else that can be done?

Yes, there is, alas not by you or me. There is quite a lot that can be done by Linden Lab, and it is up to us to raise awareness.

• Create an alternative to llGiveInventory
  What is needed is a way to get some feedback if the inventory transfer has actually succeeded. Yes, this is far from trivial and requires many, many behind-the-scenes changes, but don't tell me it can't be done! The most drastic change that needs to happen is ...
• Get rid of the IM-based transaction system
  ... because then object transfers can be operations within the database itself (instead of database -> IM system -> database). The detour through the IM system is probably only to give the recipient a notification. Otherwise it would be a simple copy or move operation in the asset server database.

In the recent survey, Pink Linden asked whether merchants would welcome a system that guarantees delivery. Yes, of course we would, but not at a 15% premium. Inventory transfer is a basic functionality of SL, and to say it bluntly - it is broken! Fix it! Asking a premium for guaranteed delivery strikes me as - well - unethical. I think it is Linden Lab's obligation to fix the functionality that is there, and not ask money for a workaround.

I actually wonder what Pink Linden has in mind? The llGiveInventory function, and the problems I described here, can't be selectively fixed. Either they work for everybody, or they keep being broken. So a certified delivery is most likely just a method to request a redelivery, and then it gets complicated when transferable items get sold (hat tip to Rika for that thoug).

Anyways, please, Linden Lab, fix llGiveInventory and the assorted functionality now!

And everybody else, please vote on this JIRA which deals with the issue.

Thanks!