 This session, we are happy to introduce a terrific session called Open Simulator VR Commerce, a primer on contributing to the open-source GloBit money module. And our speaker today is Chris Colosi. Christopher Colosi runs GloBit, the most broadly used commercial service for OpenSim. He ran Second Life's Economy, Currency Exchange, and Web Marketplace for virtual goods after Lyndon Lab acquired Windmark Mark Interactive, a video game company he co-founded. Mr. Colosi has a BA in Computer Science from Harvard University. Welcome all, and hey, let's begin the session. Hello everyone, thank you all for joining us here today. Hopefully, you've heard of GloBit and hopefully most of you are users already, and you've come across a GloBit-enabled region. If you haven't, I recommend trying it out. Today, the focus we wanted to give was we recently released our plug-in for OpenSim as an open-source money module. Our repository is on GitHub, and we're hoping that the community will help us continue to improve, to maintain, to create a feature list. So today, I just wanted to give a quick kind of walk-through of the setup so anyone looking to do that will know where to start based on what they want to do. And I'll walk through just some high-level, I'm always available to answer questions. There's a lot more depth in our README file on our repository, but this will hopefully give a high-level intro for anyone looking to maybe improve the OpenSim money module, improve the kind of C-sharp generic component of the module, or port it to something. I know we have some people who've talked about web marketplaces, for instance. So GloBit is a whole website. What we're really focused on right now, if you've used it, you know that you can create an account. You've got your transaction history, your balance. But as far as the way the OpenSim system connects, GloBit has a RESTful API. That's an API that is hit via HTTP web requests. Some of those, not all of them that we make accessible, but a few of them up here, authorize, get balance submitting a user-to-user or a user-to-app transaction. So effectively, the money module for OpenSim is a tool so that our OpenSim worlds don't have to do all of the integration work themselves to make use of that. We effectively built a plugin that made it really simple for someone to tie the UI commerce functionality already built into OpenSim, your balance in the top right, buying an object in world, to effectively going through and making those calls on the GloBit website. This is a picture of our architecture effectively. Sorry. Adjusting my camera here so I can see my slides. The architecture to give you a high-level view of everything in our repository, all the files you might find in there, starting from the right, you have our website so effectively hitting our RESTful services. What communicates directly with that is a C-sharp client-side API. This is just something that is converting C-sharp functional calls to HTTP calls to web requests going to the GloBit service, making those connections, handling the communication to pull the responses back in, processing that, turning objects in C-sharp into JSON code that's going through. The client-side API is made use of from a functional helper layer to the left. That layer is basically taking whatever information we've got from the platform and grabbing the objects that are necessary, converting some amount of information to what the client-side API needs. It's handling certain callbacks that come in from asynchronous web calls. It's effectively a layer that's just making that client-side API simpler to use. Above that, you have the object layer. This is just a set of classes, basically. What we're sending to the GloBit web services are JSON code and C-sharp is an object-oriented language. On our end, we're creating objects. These are transactions, subscriptions, users within the system. That just makes that easier to store, kind of containerizes the components that we're making use of. Those attached to a database layer, that is where we're storing everything behind the scenes. Traditionally, if you wanted to do this integration yourself with our service, you would have had to store things like an OAuth token that comes back in. You might have to store some information about a transaction, at least through processing, if not permanently. This object layer is storing all of that in a database layer. Then, ultimately, moving further to the left, you've got the platform glue layer. This is what really integrates with OpenSim. That is truly the OpenSim money module piece. Effectively, the GloBit money module, as it stands in that repository, is really two things together. We may separate these at one point, but one is a generic C-sharp API. That could be used by other platforms, or someone looking to do a web marketplace integration. Most of that wouldn't change if they can use a C-sharp API. On the left, the platform glue layer, a little bit of the functional helper layer, I probably won't get into those details today, would change. Maybe a little bit of the database layer. I know I don't have that highlighted for simplicity here, but that purple piece on the left is really what the OpenSim money module is. That is really the piece that is deeply tied to how OpenSim makes use of our C-sharp API to hit the GloBit services. Quickly, this slide is just giving you an idea of what those classes are. If you're going into a repository, if you're looking to modify the C-sharp API and improve it, you're going to be dealing with the GloBit API wrapper or the API. If you're looking to improve the object or the database layers, you've got that. If you're looking to add functionality to OpenSim, let's say I think we haven't done group join fees yet, we've had people request that. Say someone wanted to build the group join fee transaction flow. Most of that is going to happen within the GloBit money module. That's the piece where that is. If you're going to change and add configuration values to how an OpenSim world can change something about how GloBit works, that's going to happen primarily in the GloBit money module. It just gives you a layout of the classes. I quickly want to walk through just what is happening behind the scenes from a high level that is kind of vital. There's more to this. You'll see the GloBit money module class is rather large. Effectively, that is a shared region module for anyone who's done some OpenSim coding. That gets loaded for every region. It gets loaded once for a SIM process. There's an add region call for every region that gets added to that SIM. You'll see a section at the top of that file that kind of handles the general instantiation. We use GloBit.ini as where we store our config values, and effectively, these files need to read in that Iini file and set things up. You'll see an I region module interface at the top, and I shared region module interface. Those are OpenSim interfaces that we are consuming, and those functions are getting called, and we're using those to set up the API. These are the primary and maybe most important pieces of setting up the API. We're creating a GloBit API wrapper class. That's that functional helper layer that I mentioned. That, by the way, behind the scenes, if you looked at that class, is creating a GloBit API and initializing the databases, basically, so that our database implementations know where to write. We're registering three rather important web hooks, callbacks that the GloBit system needs to be able to hit. These get registered on this end, and transactions, auth functions will send those URLs to GloBit to say, hey, this is how you contact our system. Chris, some of the audience is asking about your slides. Are these available anywhere if they wanted to get a copy of them? I can certainly make that available. They're not at the moment, but I'm happy to do that. Maybe I can get them up on our dev site and share out a link. What's the best way to get that information out after the conference to people? I think we send out a post conference email as well, a follow-up, but yeah, if you can send it to Learlobal, that would be great. Also, remember, I think you have an expo booth, right? Yes, so I'll go check that out. You could place it there after the fact as well, and then folks would know where to go to get it. I want to get through a couple more slides, and then open up for questions that people have, and I know we don't have a lot of time, so I'll do this pretty quickly. I mentioned users. We create a user for every avatar on a grid, on an app effectively. That's either called a global user or an app user in our system. The global user object class.get will create or retrieve one of those. You can do that before you've authorized that person with global, but that just generates in our system. Authorization is an OAuth 2 handshake behind the scenes. That is a protocol that lots of different companies use. In our system, that goes through an authorized function, gets called in the API wrapper. That effectively calls this interface function that the money module has to implement that just says, hey, load this for a user. In the case of OpenSim, we send it in IM because we can't just launch a browser. In the case of a web app, you might just redirect URL if you know that user wanted to go into that flow. Behind the scenes, there's an OAuth complete function that comes back in from the server and exchanges an access token that gets stored in the database. In the case specifically of OpenSim, we use our getUserBalance function to do this. We don't directly call authorized. I don't think anywhere in the money module, but you could if you knew, hey, this is where I want to authorize a user. Another flow, just to walk people through a transaction flow quickly. We implement in the money module the iMoneyModule interface. We also register a handful of OpenSim events. So different transactions come in through the money module interface or through registered events. For any individual transaction, we create a transaction type enum. We check for some potential failures before we submit it. We build an OpenSim transaction description map, which effectively is a bunch of additional information that we want to make available to the users in their transaction history. And you can look through any of the existing transactions to really get an example of how this works. We build a global transaction in the system and submit that to Globit through a function in the API helper. And then we get three callbacks, generally two callbacks that will come back in and enact and consume. And that enact is where the OpenSim Money Module or anyone implementing a system with a different money module has to handle delivery. If it's a by object, it's deliver that object. If it was by a land pass in the case of OpenSim, it would be, hey, give this person access to this parcel for this amount of time. That has to return true or false back to our system so that we know and then we handle the transaction. We cancel it and give someone their money back and then alert the system as well. And we suggest that you message the user through this process. So that walks you through a couple of the flows quickly. I know that's brief for tech. Our repository, if you've got things you want, features you want, bugs you want fixed, I highly suggest people file issues. We've had a few people do that already. If you're going to work on it and help us improve it, clone or fork the repository within your clone or fork, create a feature branch, do your editing, and then submit a pull request to us via GitHub. We'll get that. The issue gives people a chance to discuss design maybe before you get into it or someone else. Pick up what you want. Doing a pull request gives us the opportunity to review it to discuss and hopefully pull your improvements back in. Like I said, there's a lot more information in the Read Me. I suggest people take a look and I will open up for questions with whatever time we have left. And I hope that was a useful little primer for people. Yeah, it's a complex topic but an important one. Thanks for the work you're doing on it. So audience, do we have any questions about this? Looks like somebody's asking about Bitcoin or Bitcoin. We got one here from Commander X. This is a general question about Globit. Bitcoin functionality on the website has been locked down for some time now. My question is why and when can we expect to be able to enter and exit the Globit economy with Bitcoin again? Sure. We implemented a Bitcoin exchange using Coinbase a while back. One of the challenges you run into with third parties is sometimes they change their APIs. Coinbase, I believe, changed that one with very little warning. So we just haven't had the time to redo that implementation. We don't have a ton of users demanding it. So we hope to get back to that but it's been more important to focus on some other problems people want fixed. It's just a matter of redoing that implementation. There was no product choice to remove that. Same thing goes for Amazon payments. We had implemented Amazon payments. Amazon basically removed a payment API they had. They wanted people to use a new API. We haven't had the time to redo that integration. So that's why you'll see Amazon grayed out but we still have PayPal and credit cards. Well, I look forward to trying to use it. I haven't honestly used Globit yet myself. I've used the Kitely. But I'm not sure if yours is part of the Kitely if that's something separate. But the outfit I'm wearing right now is a samurai. I was purchased through that with options to either wear it just on the Kitely grid or to wear it hyper-griddable to all grids that are on the hyper grid. So that was better things to open simulator than you had in the past. But it's nice to see yours coming out and being able to do so much. Yeah, our goal is to just make it as simple as possible to be usable everywhere. We'd love to get everyone onto a single currency. We think it'll help all of OpenSim as a whole. And if we can make that currency usable across other platforms as well, great for everyone using and the stability and the functionality they'll get. So we are separate from Kitely. They've done a lot of great as well. I don't really have time to talk about the differentiation there. But that's fine. In fact, we need to wrap up as it is. One thing, if you do have a link for the repository, if you could post that in the chat for folks, if not, if you could get it to Lear Lobo later, that would be great. I will post it in right now. Thanks, Chris. Great presentation you gave. Really terrific.