What is being described below is dealing in real currency – you owe it to yourself if you plan to use this, to understand how it works, and perform your own risk assessment. The module is completely unsupported and unwarrantied. Use it at your own risk.

Suppose you are a user of one of the Open Grids or Hypergrid system – and you want to purchase an item, pay into an object, or otherwise transact business where a real currency transfer occurs somewhere down the line. Up until now, in all environments you are reliant on trusting a third party to act as a middleman, providing some currency-equivilent (such as say V$, L$ or whatever.).

The problems with this scenario is that that currency is at best backed by a single corporate entity (and even then they may not choose to ‘back’ it at all) – leaving you exposed in the event something goes wrong. This is compounded by the general trading size of these operators – tending to be sole-traders or small-business; the best scenario is one where neither the user nor the merchant needs to rely on a third party beyond the credit card processor.

Which is where DTL-PayPal comes in, this is a free (3-Clause BSD), open source module we’ve developed to solve this explicit problem. It uses PayPal as the backend for the transaction, and prices inworld goods in US cents. You pay me, OS$100 – and you get a bill for US$1.00 from PayPal. Every transaction needs to be confirmed by you with PayPal thus adding security into the system; in addition you don’t need to carry existing balances of ‘currency’ in order to buy items – each item can be bought individually with a seperate transaction on your Credit Card for each purchase.

The transaction is a 2 step process for the user – which is illustrated in the diagram below. Step one, you ‘negotiate’ the payment size — this is basically filling out the payment or ‘buy’ dialog that the vendor or merchant has setup already. Step two is you will be asked to visit a special webpage (which links to one at PayPal) which sets up and pays the transaction. From a users perspective you need to do nothing more.

Steps 3 and 4 occur when PayPal has confirmed the transaction for you – once the payment is confirmed (usually within 10 seconds), PayPal notifies the module, which in turn completes the transaction, finally PayPal deposits the balance in the vendors account for immediate use.

Obviously the problems with inventory server issues, vendor malfunctions, etc still exist – but to a customer PayPal does allow you to dispute charges on non-delivery grounds (however beware doing this to scam the system – the merchant gets a chance at rebuttal and it can be a complicated process)

From a vendor perspective – the main drawback to this solution is cost, PayPal will charge you roughly $0.28 plus 2.2% for a standard account in order to process the transaction. On tiny transactions (such as one for $0.50, fee would be $0.31) this can add up to a significant portion of the transaction. For users using this exclusively, I highly recommend using a PayPal MicroTransactions account which has much lower fees (but certain additional terms & conditions).

So, where can I get the code for this? It’s on my personal GitHub account (along with a few of my other goodies) – http://github.com/AdamFrisby/DTL-PayPal – I will add some further notes, first this module is currently somewhat hard coded to present a warning to the user about it’s experimental nature, remove this at your own risk. Second – OpenSim is still alpha software, you may run into other issues, so be prepared to handle them if you want to accept payments from users in it. This software has only been tested on the PayPal sandbox so far (and I recommend you do the same), however should work with the live version fine.

Enjoy.

OpenSim has had the capability to run multiple different clients connected to the same world since version 0.3. We translate a large number of our internal programming into a somewhat vendor neutral interface; the big catch has been – in the 21 releases since 0.3, we’ve never actually implemented a true second protocol. As of today that has changed, OpenSim now supports two client protocols that can be used simultaneously at the same time to display the same world with the same updates, avatars and interactivity. This means right now you can use either the LLUDP transport used by Second Life™, OpenSim and realXtend, or the new MXP transport developed by the Tommi over at Bubblecloud.org.

We also have some good news from the guys over at VastPark – over the next few days, I will be working with their team to try write another client transport which allows you to use the VastPark viewer to connect to OpenSim. Watch this space for some information about that.

MX Deck and Second Life connected to the same region (Click to Enlarge)

Why MXP?

The simple answer here is the protocol is reasonably well thought out (it’s very refreshing compared to LLUDP), it’s also pretty simple and easy to understand. There’s a good reference implementation on their website which we were able to utilize extensively. To users, there’s potentially some big advantages in how you can route packets from a region simulator to viewers – possibly eliminating some of the issues people see when trying to host from behind firewalls and routers. This is however conceptual – a decent client will still need to be written to utilize the MXP protocol (right now the only clients using it are for demonstration purposes).

The big reasons were however that it’s appropriately licensed, there’s good reference code out there and the protocol is straight forward. It was also in the right place at the right time — while it gets the crown for first additional protocol, we’re hoping to have quite a few more now the infrastructure is in place and tested to properly support alternate client libraries.

How complete is this implementation?

Not very – we implement at the moment about 5 of 250 “functions” the Second Life viewer can present to us, ontop of the basic connection management. Mostly these are relating to display of primitives, updating their positions and chat. We still need to do a good deal towards displaying avatars correctly (and assigning a ‘ruth’ for each clients display of the other). Given the adapter is however less than 48 hours old – I expect to see some rapid progress here in adding features and capabilities to it. To give some idea of what’s working however below is some screenshots of the same region connected to in each client.

How do I connect a MXP client to OpenSim?

Grab a copy of the Demo Client from Bubblecloud.org (see Downloads -> MXP Demo Client.zip) and a copy of the latest release of OpenSim from the OpenSim Trunk SVN.

In your OpenSim.ini, add the following settings to the end

[MXP]
Enabled = true
Port = 1253

Start up your OpenSim and create a region if you havent already – now go into your OpenSim Region’s directory and open your default.xml – cut and paste the sim UUID (looks like this: b18ddeb1-f3d4-4c05-aa55-f1ca55532220 )

Install the MXP Client and edit the MX Deck.exe.config file – you need to paste your region UUID into the “BubbleID” field, and edit the “ServerAddress” to read “127.0.0.1″

Start MX Deck.exe and you should be connected to your OpenSim region.

Voila!