Gloebits proposes money module for OpenSim viewers

Mobius Grid has implemented Gloebits grid-wide. (Serra Royale.)

Gloebit has built, tested and proposed to Firestorm viewer team, a patch that, if implemented, will bring multi-currency support in OpenSim and eliminate the need for Gloebit users to do complicated coding and configuration for their grids and regions to support various money modules.

With the current viewer implementation, the currency symbol is configured to work with the global settings of the grid that a user first logs in and does not update even when the same user teleports or hypergrids to a different region using a different currency service. The patch will remove that confusion by making sure that the symbol updates to the currency symbol of the currency module supported in the new grid.

Christopher Colosi

“This is a big step forward in getting the money module to handle all commerce activity and truly making it so that you install and configure the Gloebit Money Module and everything just works,” Gloebit CEO Christopher Colosi told Hypergrid Business.

That means if a user teleports from a region with one currency to a region that uses a different currency, the currency symbol in the top right-hand of the viewer window will be automatically updated.

“With the Gloebit Money Module enabled, this will set the symbol to ‘G$,'” he said.-

The patch is now available for download for importing and as a reference to any viewer development teams who want to develop a similar module.

ZanGrid Hypershopping I and II regions are Gloebits enabled. (Image courtesy ZanGrid.)

The helper-uri will also update automatically to that of the new grid if the patch is implemented in the viewer when a user teleports or hypergrids to a different grid supporting a different currency module supported in the previous grid.

This means that the buy-currency, insufficient-funds, and buy-land flows will work without breaking and without asking the user to manually update the grid info in their viewer and without the currency.php file, landtool.php file or an xml-rpc server set up.

“I haven’t double checked this, but it might allow a foreign hypergrid visitor to buy land in a foreign grid,” he said.

For instance, if the Gloebit Money Module is enabled in the region that the user newly teleports or hypergrids to, the helper-uri will point at the sim running this region which will allow the Gloebit Money Module to handle these calls directly.

Gloebit, which is currently in use on more than a dozen grids, is inviting the OpenSim community to get onto Firestorm’s jira and vote up the idea.

The Gloebit team has not yet enabled purchasing of Gloebits directly in the viewers, but the update will allow them to set helpful messaging for a user either directing them to link or authorize Gloebit, or to buy Gloebits.

“Once we feel most users have updated to viewers with this functionality, we may remove the messaging we currently send to users each session letting them know how to auth/link or buy Gloebits, as we’ll be able to supply that messaging when they need it during the purchase flow,” he said.

Gloebit has been supplying the currency service for grids and regions but that required manually supplying of the currency service parameters to the viewer when the user enters a Gloebits enabled region, which was complicated and involving on the user side.

The update will also eliminate the need for users to learn the process of configuring the module, which takes time. It will also eliminate break of buy-currency, buy-land, and insufficient-funds flows breaks that are experienced.

Implementation of the patch in Firestorm will be great news for Gloebit because the viewer has the highest users at 53 percent followed by Singularity at 26 percent and 7 percent for Alchemy according to a post. Gloebit hopes that the Firestorm development team reviews, imports and tests the code, and include it in their next viewer update.

“I have no idea how much time they spend on that or if they ever modify code,” he said.

Singularity and Alchemy viewers have confirmed they will implement the module although they will need to do some changes on the patch code because the viewers’ codes are different from Firestorm code.

But there are tens of viewers out there who would also need to do the changes. For those viewers that have not diverged from Firestorm in terms of their code can just import the module as well without doing any changes to the patch code.

“If they have (diverged), they might need to resolve merge conflicts or they might need to just use this as a reference and redo the work for their system,” he said. “Even though they may have coding to do, I’ve done the most challenging piece, which is to understand the existing system and determine how and where to change it.”

The team will keep improving the module as time goes and as problems are discovered. For instance, the currency symbol works well with all buy-currency floaters that have dynamic string but they might be adding some changes if any buy-currency floaters with static string are found.

“As those are discovered, we may need to add a few lines of code to force those to update as well,” said Colosi.

Currently, it allows grid owners and event hosts to sell tickets to an event in OpenSim using a built-in parcel access interface.

Related Posts

David Kariuki

David Kariuki is a technology journalist who has a wide range of experience reporting about modern technology solutions. A graduate of Kenya's Moi University, he also writes for Cleanleap, and has previously worked for Resources Quarterly and Construction Review. Email him at [email protected].

71 Responses

  1.' XMIR Grid says:

    There is clearly a need for the viewer to detect new grid currencies on HG teleports, but I am not so sure about per region crossing as it would add to the lag per crossing, both in making a query to a server for a change (even if it is the region server), update the UI with new currency symbol, retrieve new balance and even re-authenticate to get the new balance.

    From a grid owner standpoint I think it is an exceptionally bad idea to allow different currencies in different regions of the grid.

    •' Cinder Biscuits says:

      It requires no change to the protocol and doesn’t incur any additional “lag per crossing”.

      Also, it would have to be per region because that’s how hypergrid works.

      •' XMIR Grid says:

        As I said in my other post, then it does too much work as the information is not really required till the point when a transaction is to be started (other than from a general informational point.) In some cases it would not even get the user the correct information such as when you have PayPal payments or true credit card payments where there is no need for the balance at all, but only need an authorization from the payment processor to let the transaction complete.

        The reason why Gloebit is pushing this is to have multiple currencies per grid (on a per region basis) and IMO that is highly undesirable from a grid owner perspective for a number of reasons.

        •' Cinder Biscuits says:

          There already *are* multiple currencies per grid on any grid that is hypergrid enabled. If Grid A is using $A and Grid B is using B$ and you teleport from Grid A to Grid B, your B$ balance will show in the viewer. Money functions are done via client -> region messaging.

          •' XMIR Grid says:

            So what is the point of the patch then (as described in the article)? If the balance already updates correct, then it is a minor issue to display the correct currency symbol alongside it.

            The question is also where does it get the balance from? If the avatar starts in Kitely with a grid KC balance and teleports to a region with the OMC module, it necessarily have to lookup the OMC balance via an authentication to VirWox as the balance for all possible VirWox accounts are not cached on the new region. It will have to go a round trip to VirWox to get the current balance. Same for Gloebit I suppose.

          •' Cinder Biscuits says:

            You should know by now HGB almost without failure misinterprets technical details. The patch simply updates the currency symbol and the helper uri (which is used by the viewer to get exchange rates and for in-viewer currency purchase. Nobody in opensim, as far as I know, has implemented either fully. Although you can use the helper uri to send a message to the user if they attempt to buy currency from the viewer requesting the visit suchandsuch url to purchase game gold tokens.)

            As I already said, money functions are viewer->region so it gets the balance from the region. This has always been the case as can be witnessed by teleporting from any grid to Hyperica, your balance will jump to $10,000 and will return to zero when you leave.

          •' XMIR Grid says:

            Yes you get some balance when you TP to Hyperica, but which is it, and can it be used for anything? :-))

            If I teleport from XMIR (that has OMC) to another region with OMC on any grid, the balance follows me and I can make purchases on another grid and it is delivered to My Suitcase. I presume the OMC module on another grid is able to communicate with the OMC server of my home grid to fetch my correct VirWOX user ID to set up the authentication with the VirWOX site where I have to enter a password before the transaction can proceed. OMC must have a the module running in Robust where it sets up a trust with the OMC transaction server, in addition to the module running on each simulator.

            If my Kitely avatar that has a KC balance goes to XMIR or some other grid with OMC, I can’t do anything with the OMC balance held on VirWox if I wanted ever so much. Possibly because Kitely does not have the OMC module installed anywhere so there is no trust with OMC, hence it cannot get the balance and it does not know who I am.

            I don’t know how Gloebit is working from a technical perspective, but I suppose they have similar arrangements, where before you can get a valid balance you have to authenticate yourself to their backend. Otherwise anyone can spoof an avatar and fetch a balance and possibly use it.
            I also don’t know of any code in the viewers that would store the Gloebit balance in a local wallet, so it will have to fetched live?

          •' Cinder Biscuits says:

            “Yes you get some balance when you TP to Hyperica, but which is it, and can it be used for anything?”

            Guess you could use it to pay other people in Hyperica, but that is all.

            I don’t know how Gloebit works. I remember evaluating OMC for the grid I used to work for, but their management was somewhat hostile when questioned and since the grid was being used for gambling, having to authenticate every transaction would have been too time consuming.

            Most money modules don’t work with hypergridding agents. I can’t speak for what Gloebits does because I haven’t used it, but when I wrote my bitcoin escrow module, you had to authenticate yourself for every new grid you travelled to. (this never went into production because only a single grid used it.)

          •' XMIR Grid says:

            From the discussion on G+ I have the understanding that Gloebit only needs a module per region (I would suppose that is per simulator) and nothing more, and I don’t like the ring of it at all.

            This is also the rationale for the patch; that they can deploy Gloebit to single regions on any grid essentially having multiple currencies per grid. Hence also the need for checking currency type and fetching (per currency) balance on each region crossing.

          •' Butch Arnold says:

            Currently, users in DigiWorldz can choose to use either PODEX, or Gloebit in their regions… we leave it up to them to choose which they want to use and they can choose to change their choice at any time.
            I personally think it’s a great idea and it provides a choice to our users as some users do not yet want to use Gloebit, while others want it.
            When you have a flexible system capable of handling either, you can serve both sides in the argument.
            Each region has either our currency module for PODEX, or it has the Gloebit module, depending on the current choice. If/When a user decides to change the type of currency they accept in a region, we simply swap modules and change the config file for the region.
            Since our system builds the configs for each region on the fly each time a region is started, it allows for fast and easy changes. We simply change the setting and restart the region, our system replaces the currency modules and builds a new config file the simulator will use when it’s starting up.

            It’s not as confusing as one might think, as by default our entire grid is PODEX, but on those regions which have chosen to use Gloebit, when a user arrives in the region, they will receive a popup notice letting them know the region is using Gloebit currency.

          •' XMIR Grid says:

            Yes, as far as I can judge it would be possible to do the same with OMC as the base and Gloebit in selected regions.

            If we are going to make changes to the viewers, it would be beneficial to make sure the changes improve the usability of all currencies and not Gloebit. We therefore need better understanding of how the various currencies handle the transactions. In general the money module in OpenSim server is weak on functionality, so better general support for such transactions is also needed.

        • You can read more about this patch on my medium post ( and from the Firestorm Jira (

          1. This patch was built so that any currency module can use it. It is not Gloebit specific. I built it in my personal time by the way. Yes, it helps Gloebit provide a better product, but it is also intended to improve the user experience for all users regardless of what viewer or currency module they are using.

          2. Gloebit believes in choice. Too often, I hear people say that they don’t like something and no one else should have it. They seem afraid that somehow they’ll lose what they have if someone else gets what they want (It reminds me of people fighting gay marriage). Everything we’ve built, we’ve done our best to preserve the most choice for OpenSim users. So, we didn’t require that a grid switch completely to our module. It can be installed on a single sim. Further, it can be enabled only for specified regions running under that sim. If you don’t want to run multiple currencies or don’t want that functionality, that’s fine. Don’t use it. But don’t try to prevent others from having that choice just because you don’t understand it. If you do that, you are being obtuse.

          3. A grid or set of regions (yes, you could be someone running one or a few regions on OSGrid for instance and you could set those up to use Gloebit and you could be one of many region sets in OSGrid running Gloebit) is tied to an app on Gloebit which that owner has created. An avatar has to authorize that app to give it access to see that avatars balance and request transactions for that avatar. This is how the permission system works. Once a user has granted access once, they do not have to do so again. This is intentionally designed to be unlike PayPal, where authorization is required for every transaction. This allows a user to shop without constantly jumping to the web to authorize individual transactions.

          4. We do fetch a user’s balance from our servers. This puts load on our servers, not on OpenSim. If this load becomes costly, we can begin to cache a user’s balance. This would be done within the money module. This was a choice not to build for now as software developers need to prioritize where they spend their limited resources and this is not yet worth applying resources.

          •' XMIR Grid says:

            I am not agains choice at all, and Opensim both can and needs to have support for business models that are quite different from the LL business model that currently is hammered into the viewers.

            In doing so, many parties needs to come together and agree on the protocols and functionality that both will have to go into server and the viewers. Currently the support for monetary transactions in OpenSim core is very weak, and deliberately done so by the developers (and I can see a can of legal worms being one reason). IMO the support needs to become better and have better hooks for third party modules.

            What we don’t need is solo initiatives like one change that has gone into 0.9.1 dev that benefits Gloebit, but breaks other currency modules, or only talking to one viewer developer about changes in hope of pressuring the others to support it.

          •' Cinder Biscuits says:

            “In doing so, many parties needs to come together and agree on the protocols and functionality that both will have to go into server and the viewers.”

            This absolutely never works in OpenSim. It comes down to one or two people sitting down, writing actual code, having it reviewed by others, and finally integrated. I think it’s great that Chris was ambitious enough to do it all himself and do it in a way that others can take advantage of it as well.

            There really is no liability issue in Core implementing an inworld currency system. The fitness for use and liability disclaimer clause in the license covers them from any liability. (Not that I’d trust anything written by core to be secure given what’s currently there, and the current opensource options are riddled with bad security practices all being based on the same terrible implementation.)

            but that’s an argument from last decade. Core isn’t getting a money module, and that was decided a very long time ago. Anyone who can’t handle a little api breakage now and then really has no business writing modules for alpha-grade software either. At least breaking api would cull some of the many abandoned and insecure money systems floating around out there that people use.

          •' XMIR Grid says:

            Melanie is the one who have been pulling the liability card most often, and being quoted as the reason why OpenSim server is in perpetual alpha. I simply disagree with her.

            Having said that, in a scenario where virtual currencies are regarded as taxable properly, handling balance, privacy and ensuring transaction integrity in the money module takes on a different level of significance and could easily be subject both to legal action but also regulatory intervention. It would not hurt if the basic money module could handle full forward transaction integrity, rollbacks, proper reporting and all the transaction types currently in use in SL and/or OpenSim without resorting to such means as land tool.php even if it only does so for zero value transactions.

            As OpenSim matures (hopefully), there is more need for coordination, specification and prototyping upfront with input from a wider audience. Granted, you might end up with less than a handful people coding it, but the end result will be better and with better uptake across grids. In the same process ensuring backward compatibility becomes more important as very few can afford to work through multiple SharePoint type upgrades where you basically have to scratch the lot for a new version.

            It is important to note I have not criticized the patch as such, it is even simple to implement in Kokua (given that the Kokua codebase on HG teleport leaves a lot to be desired – it will be fixed, but is not at the immediate top of the queue.)

            In another venue I have said a lot about the fitness of Gloebit for use in Europe, but that has nothing to do with this patch or the codebase as such. It is purely from a legislative and business standpoint that issue arise. The company behind Gloebit is possibly not even in a position to do anything about it unless they incorporated themselves with a subsidiary inside the EU. Even then it could be painful and costly, and not worth the effort.

          •' Cinder Biscuits says:

            The basic money module isn’t intended to run that scenario. it simply implements the protocol which is all OpenSim is meant to do.

            and of course it would be an easy patch to integrate. Kokua’s OS support is taken directly from Firestorm’s.

          •' XMIR Grid says:

            >Kokua’s OS support is taken directly from Firestorm’s

            According to NickyP it is the other way around where a lot of the initial support came from Imprudence, then was adopted by FS and were refined in both viewers sometimes in tandem, sometimes independent. Because of this it is a bit of a mess here and there, and needs to be firmed up.

          •' Cinder Biscuits says:

            None of the initial implementation came from Imprudence because that’s an entirely different codebase and license. Armin Weatherwax wrote an implementation for Kokua which was pulled into Firestorm early on, but that implementation was obsoleted when Armin joined the Firestorm team and ported his implementation that included hypergrid support from Teapot Viewer to Firestorm. Armin left OpenSim entirely and sometime after that Nicky gained control of Kokua and started to wholesale port stuff from Firestorm into Kokua. I can’t think of a single thing related to OpenSim that Nicky actually wrote that Firestorm adopted. Just Armin, and as I said, the bulk of which came out of Teapot into Firestorm and eventually to Kokua. You don’t even have to take my word for it, it’s all there in the changelog.

          •' XMIR Grid says:

            > Armin Weatherwax wrote an implementation for Kokua

            But he also wrote the initial one for Imprudence, so it might not have come from the same repository, but from the same head. Kokua is a direct continuation of Imprudence, but based on the LL v2 interface and base, but with a lot of spillover and experience from the Imprudence implementation. There is still code from the initial OpenSim support implementation in Kokua, and it makes it different from FS in many ways.

            > I can’t think of a single thing related to OpenSim that Nicky actually wrote that Firestorm adopted.

            That is my assessment as well.

          •' Cinder Biscuits says:

            Well as far as grid management, yes. I was speaking more along the lines of internals which got switched up with the inclusion of all that Havok separation-of-code crap that Firestorm has.

          •' XMIR Grid says:

            The only thing that matters is that code developed for FS does not cleanly apply to Kokua in many cases. To make it apply, the solutions used have not always been optimal…

          • Nothing has gone into 0.9.1 dev that solely benefits Gloebit. Nothing has gone into 0.9.1 dev at all. An map called OpenSim Extras has been delivered at region entry for a long time. This is a dynamic set of information that any module can add to. It doesn’t break any service. Gloebit has been taking advantage of it in its module which is compatible back to early 0.8 versions of OpenSim.

            What we have done is supply a patch to get the viewer to make use of this additional information. Also, the behavior will not change for modules which don’t supply this or regions without a module.

            It is disappointing to see a community member throw around false accusations. Please stop.

          • Nothing has gone into 0.9.1 dev that solely benefits Gloebit. Nothing has gone into 0.9.1 dev at all with regard to this patch.

            A map called OpenSim Extras has been delivered at region entry going back many versions. This is a dynamic set of information that any module can add to. It doesn’t break any service. Gloebit has been taking advantage of it in its module which is compatible back to early 0.8 versions of OpenSim, so it’s at least that old.

            This patch simply allows the viewer to make use of the additional information which Gloebit already supplies and which other money modules can also supply. Also, the behavior will not change for modules which don’t supply this information or regions without a module.

            XMIR, where did you get the idea that any change was made to 0.9.1 dev or that anything in the patch supplied solely benefits Gloebit or breaks any other currency module? You stated this adamantly and it is false. Did someone tell you this? Did you read it somewhere? If there are a group of people who somehow got this impression and you are voicing their views, I’d like to know how I can reach out to them to assure them that these views are incorrect.

          •' Geir Nøklebye says:

            The impression has been made both in the dev meeting and elsewhere that the changes to the land passes purchase process was on the request from Gloebit, and these changes broke the OMC module.

            Personally I had to revert them.

            Particularly this change is troublesome

            But I am sure you are able to test it yourself since you are so clever?

          •' Cinder Biscuits says:

            Ummmm, if you’re running 0.9.1 dev you should expect api breakage and lots of it.

          •' Geir Nøklebye says:

            I didn’t say it was not expected, just stated a fact. 😉

            …but as always backward compatibility, and/or involving all parties affected by such changes is a good thing. Messing with people’s money systems is not quite the ticket.

          •' Cinder Biscuits says:

            Like I said, you should expect api breakage and lots of it. There doesn’t need to be any consensus to improve an api especially on the development branch of an alpha grade project. The whole reason OpenSim is stuck with a shittty script engine is because Melanie won’t let anyone change the script api.

            Also, PS that changeset doesn’t have anything to do with the subject of the article.

          •' Geir Nøklebye says:

            The fact that OpenSim is artificially held in status alpha grade project is the primary reason why nobody wants to take it serious. Virtually nobody are interested in throwing effort or funding at it any more.

          •' Cinder Biscuits says:

            Well you’d better keep making uneducated accusations and drive Gloebits off too because they’re throwing effort at it.

          •' Geir Nøklebye says:

            I am not the only one who have discovered the changes that were made for purchasing land passes have broken currency modules. The link was to one of these changes; the sum of them makes such modules not work. The changes have been profiled as being made to accommodate Gloebit; not by me but others. OK?

            Secondly, what Gloebit does and don’t do is of little interest as long as they cannot operate within the legislation I have to operate within. That is MY concern that might be shared with others, but it does not characterize the software development they do.

            With respect to the viewer patch supplied, I see no objection to providing information to the user which currency is used in a region and add to the ability to purchase currency (any), but I am not convinced this patch is exactly the way to implement it both viewer and server side for multiple reasons.

          •' Cinder Biscuits says:

            On point #1, So what? Again, it’s a development branch. Expect breakage.
            On point #2, Then why spend so much time flat out guessing how their module works?
            On point #3, Nobody exactly asked you to weigh in on it, now did they?

          •' lmpierce says:

            Just a reminder to all: In discussions, everyone is welcome: no one needs an invitation or special authority to ‘weigh in’. Opinions are permitted, whether they are valid or not. It is also permitted that readers disagree with opinions and provide their own facts and perspectives. Ideally, this creates the dialectic that is a discussion.

          •' lmpierce says:

            There is a Discussion Guideline that people or organizations should not post self-serving material or external links without adding relevant material to the quality of the discussion. So, please consider enhancing statements, such as: “I am not convinced this patch is exactly the way to implement it both viewer and server side for multiple reasons” with additional information, such as a list or reiteration of some or all of those ‘multiple reasons’. When people are presented with specific information they can respond with their own specific information and this helps to keep the discussion moving forward.

          •' Geir Nøklebye says:

            I already did that further up the discussion. We’ll see how it turns out once implemented in the viewer code I work on.

          •' lmpierce says:

            Thanks for including something of a reference to your previous comments. Please remember that in a long discussion, it’s hard to keep every previous comment in mind, so it can be helpful to the readers if salient points made earlier are reiterated. While not required, of course, it can improve the discussion immensely.

            Once you have results please do post them here. Specific information is always the best way to work out any issues, whether they are general or idiosyncratic.

          •' Geir Nøklebye says:

            To give you one hint; user interface hell!

            A grid might have a primary currency (that the user holds a balance in), some regions on the grid may have a secondary currency such as Gloebit, and in addition you might have PayPal vendors (or other similar systems) offering in a third currency. Which currency do you display for the region? Which currency do you update the viewer primary interface to purchase in? Where do you display the balances the user might hold for the different curencies? You might also want to present the users with the transactions in the viewer as if to not have to log in to multiple websites to get an overview.

            One of my takes is that both the object floater (that now) displays the currency the object is to be sold in, also must have functionality to be able to set the current and amount the object is to be sold in if there are multiple currencies on the grid.

            Likewise the currency must displayed when the user clicks an object to make a purchase, and only then offers the user to purchase additional currency if they don’t have the balance to proceed.

            It is also imperative for the grid owner to have a view of monetary transactions going on on the grid, otherwise the grid owner has no idea if fraud, that he might be held accountable to by authorities, are ongoing on the grid.

            By completely removing transactions from the grid owner’s view (and this is also a concern with OMC), the grid owner is virtually blinded with the respect to the economy of the grid and fraudulence that might take place.


          •' Cinder Biscuits says:

            Again, it appears you don’t grasp how any of this works. There is no primary/secondary/multiple currency as far as the simulator is concerned.

          •' Geir Nøklebye says:

            For the primary currency (the grid currency) it must be enabled on Robust for the grid, and should be displayed as the primary balance and currency symbol on any region on that grid. I did not think any region could opt out of this by configuration unless you don’t load the primary money module on the simulator, so it will always be there.

            In general I would think a grid owner would like to have the primary grid currency enabled in every region for consistency on the grid.

            In general I would think every merchant would like the merchandise or land to be able to sell in the primary grid currency.

            Mr. Gloebit states further up “So, we didn’t require that a grid switch completely to our module. It can be installed on a single sim. Further, it can be enabled only for specified regions running under that sim. If you don’t want to run multiple currencies or don’t want that functionality, that’s fine.”

            This sounds like Gloebit can be installed in ADDITION to the grid currency in select regions, while it is not entirely clear if that removes the primary grid currency from the region.

          •' Cinder Biscuits says:

            Again, it appears you don’t grasp how any of this works no matter how many times it has been explained to you. Instead of inferring and supposing and making assumptions on what you read in the comments section, you could read the simulator code or you could just at the very least take the people who have actually written money modules at their word.

          • Thanks Cinder. We’re working out butts off.

          • Cinder, there doesn’t need to be consensus, but APIs should be well thought out and ideally breaking changes should only be made when absolutely necessary. When possible, they should be phased in to give developers a chance to release versions that support the new interfaces before customers see crashes. This did not happen in this case.

            Core very quickly implemented a flow to handle land pass sales under the believe that they had all the money module tools they needed. I informed them that they didn’t and should take some time to plan this. No planning went into this (other than the research I had published in IRC as to how to capture the land-pass sale flow) before coding was started. They first tried to use the flows that uploading of textures or group creation fees uses. I had to inform them that those don’t supply any information for who to pay (the land owner) or any details of the transaction (such as the parcel). They then jumped to using the existing MoveMoney() function, but I informed them that this flow might hand out a land pass when the payment failed as it returned void. They added a new interface function which returns a bool to resolve this. I asked that they add a dictionary arg to this so that information about the transaction could be passed to the money module and so that it might be more flexible for future transaction modifications, but they seemed set on preventing the money module from having access to any info beyond a string description. I asked that they provide a callback function for the money module to call after it had asynchronously completed the transaction (so that the money module could control delivery of the pass), but this was also refused and they went with a flow where the core fully controls the flow.

            This could have been done without breaking any money modules by creating a new event in core which the money module could subscribe to. For modules which didn’t, this event would be fired and nothing would happen. My other suggestion was that if they add a new interface function, they do it now and announce that they would start using it some number of versions in the future, to give all money modules a chance to implement it. Instead, they added it and immediately began using it.

            Further, these changes were made in the 0.9.1-dev branch and really should never have impacted the 0.9.0-release. So, even if you are making breaking changes, those should not end up in a release if they weren’t in the release candidates for a version. Sure, core has the ability to do what they want and sometimes moving quickly is the right move. I don’t believe they needed to move this quickly here and I believe a lot of bad decisions were made which unnecessarily adversely affected customers.

          •' Cinder Biscuits says:

            Right, as the maintainer for a software library, I understand the need for API/ABI stability if you expect any consumers of the library to make effective use of it, but I have a special loathing for the majority of OpenSim money modules, their memory leaks, and their home-brewed security schemes, and will happily see the unmaintained ones obsoleted by improvements.

          •' Geir Nøklebye says:

            This is probably how the perception of changes made for Gloebit came up, as you (apparently) where the only person interacting with the devs while making the land pass changes, and they did, as you describe above, “make changes to make it work with your currency module”.

            It sounds from the above, that despite making interim changes, at the end of the day they went ahead and did their own thing breaking a lot of eggs as a result.

          • Geir, please don’t put words into my mouth. The core devs did not make changes to make land pass sales work with the Gloebit money module. The core devs made changes which broke my implementation of land pass sales and caused my module to crash. Unlike OMC and other modules, I provided a patch to my customers to make it work again. I then also created an implementation to make land pass sales work under the new flow that core created for users on 0.9.0-release and beyond.

          • After core created a flow which allowed for the case where a payment would fail but the product would still be delivered, I did instruct them that I would not implement their new flow and would find a workaround because that would be a major flaw for any and all money modules. I had warned them about this before they started as well. That is when they added a new interface function to the money module which doesn’t completely fix but drastically reduces that risk. Now, if you’re going to blame me for trying to ensure that either people are charged and get their item or people are not charged and don’t get their item, then please, go ahead and cast that on me. I take full responsibility for trying to make sure core doesn’t destroy the transaction system by inserting flows where users will get items they don’t pay for.

          •' Geir Nøklebye says:

            OK, then you have to become BETTER at explaining what you did, because above you clearly stated you had multiple rounds and suggestions to the land pass purchase changes. If these changes did NOT support the implementation of Gloebit, why even be involved or make such suggestions?

          • I agree I need to get better. I also have to understand where these views popped up from. I didn’t make them, so who in the community started these rumors?

            I’ll be on Mal Burns’ show tomorrow, and I’ll do my best to explain and to answer questions. In short regarding land pass sales. I built this functionality into the Gloebit Money Module with no help from core. Upon learning that I did this, core implemented land pass sales in core OpenSim under what I would consider a misguided idealism that the money module should be stupid, all logic should be in the core, and the pre-empt me releasing something which might make it harder for them to take this flow over down the road. Core broke my implementation and created an implementation which could not be guaranteed to work properly. I informed them of their error. Core made a breaking change to the money module interface to fix this which broke all existing money modules for 0.9.1-dev. Core then pulled this breaking change into the 0.9.0-release, breaking all money modules in 0.9.0-release. I patched the Gloebit Money Module.

          •' JozeeTungsten says:

            Kudos to you for even attempting to deal with this outfit. This whole discussion screams “amateur hour”.

          •' Geir Nøklebye says:

            Let me first say that nobody is pointing fingers at you because of these changes that were made to core.

            It has only been said that changes have been made to the land pass sales for it to work with Gloebit. For all I know that may have been said in the middle of developing these changes (most likely in the context of a dev meeting).

            I only discovered the breakage after taking the changes and realizing that OMC would no longer start. The commit messages says nothing about breaking money modules and as far as I can observe there is no communication about it elsewhere. I find it even more disturbing to learn that these were deployed to the 0.9.0 release.

            The core development process is not very transparent, and if you don’t hang out on IRC (I don’t) it is often impossible to know why changes have been made and the reasoning behind.

            Anyone is free to submit or propose changes, but that does not mean everyone likes the proposal, agrees or may not have counter proposals. It is, however, imperative that those who accept proposed changes for inclusion and implementation in OpenSim core, do so in a transparent manner, informs about the consequences of the changes (beyond telling people to read the source) and seek to implement backward compatibility and reasonable forward migration paths.

            Even though there are many who will be delighted to see money modules break in their misguided understanding of what OpenSim is or can be, the same people should also know that most OpenSim installations would be extinct without some finance and real currency supporting them.

          • Sounds like I should attend more of these dev meetings. Is there a calendar I should subscribe to with the schedule for these? I’ve been to a couple when people have specifically asked me to come, but I don’t know the normal schedule for them.

          •' Geir Nøklebye says:

            Every Tuesday at 11 PST in Osgrid’s “Projet Secret” region

          • Thanks. I’m going to try to attend today and it’s now on my calendar.

          •' Arielle says:

            The dev meetings would be much better for discussing interactions between your code and Opensim then on Disqus, G+ or even Mal’s show as at least there you are in a place where a few dev’s are going to see what you have on it. There is also a log file posted that is searchable and readable for anyone interested in looking for info on its status.
            Some links to the relevant commits would be nice too for a little more background.

          •' Cinder Biscuits says:

            Piss-poor, unmaintained, easily-exploitable money modules help no one.

          • Agreed Geir. I begged core to get input and not to rush money module changes.

          • Hi Geir, thank you for providing me the opportunity to speak to this. I should attend more developer meetings.

            I (for Gloebit and at the request of some customers) implemented land pass sales strictly in the Gloebit Money Module without any modification to the OpenSim Core. As I did so, I passed along all the research I did on the opensim-dev IRC channel. When core learned that I completed this, they did not want Gloebit to have an advantage and did not want the logic handled in the money module (and did not understand that much of the logic of all of the other transaction flows is handled in the money module, not in core), so they rushed a modification into the 0.9.1-dev specifically to pre-empt the work I had done. I begged them to stop and design this and explained they were making breaking changes. Core would not listen. I wish someone from OMC or anyone who has complained about this would have been in IRC when I was fighting this battle without much support. A couple of weeks later, core did something unprecedented, and pulled all of the 0.9.1-dev changes into the 0.9.0-release. I explained how this was bad process and how they specifically released a breaking change to the money module interface which was not in any release candidate and which no module was prepared for (including Gloebit). They didn’t really seem to care.

            Gloebit’s money module was also broken at this point, and I had to rush out a fix for everyone on 0.9.0-release and 0.9.1-dev. I actually had to do more than twice as much work because of this modification to the core. The Gloebit Money Module has two implementations for land-pass sales: 1 which is handled entirely in the module for OpenSim prior to 0.9.0-release, and one which uses the new flow and interface which core added in 0.9.0-release and beyond.

            Trust me, I (on behalf of Gloebit) was pushing against making any changes to core, not pushing for them. I also was not satisfied with the design decisions made for the new interface function. I did my best to guide them to improve it, but most of my suggestions were ignored. I also asked them to wait and get opinions other than mine from grids and other currency modules, to no avail.

  2.' XMIR Grid says:

    In reality the grid or region currency is irrelevant to the user till a transaction is to be made.

    So from a transaction standpoint you don’t need to find out the currency till the point of time when the transaction is to take place. At that time you have plenty of time to find out what currency the goods is offered in or the transaction is to take place in (such as between avatar payments).

    If the transaction is to take place in a different currency than the native grid currency of the avatar you can let the avatar authenticate to the currency service, retrieve the balance, complete the monetary transaction and deliver the goods if applicable. If the transaction is performed in the native grid currency of the avatar, it basically takes the same route, except the avatar may possibly be authenticated already.

    This way there are no lookups to be done on HG transfers or region transfers, which will both reduce the load on the currency service and region servers on crossings.

    In either case, if the avatar does not have sufficient balance to complete the transaction, it should be aborted and the avatar offered a way obtain more currency.

    • XMIR, I wish you wouldn’t make statements which sound like fact when they are incorrect. This disseminates misinformation and is bad for all of OpenSim. The way you’ve stated that this works or should work is not based in any understanding of the OpenSim server or viewer code or how they communicate. If you’d like to suggest that the core and viewer teams get together and design a new communication system (which would break functionality with Second Life btw), then make clear that you are stating it as a suggestion. My goal here was to get something working under the current system and which would not break functionality with SL (since many viewers choose to keep that).

      1. The grid or region currency is not irrelevant until a transaction. It is displayed in the top of the viewer and is therefore, immediately relevant. Further, users need to understand the pricing of an object before they start a transaction, for which, the currency is relevant. 1 peso is not equal to 1 dollar.

      2. There is no communication system in place to supply the currency (symbol or helper-uri) at the time of a transaction. Those protocols are defined and do not support the passing of additional parameters as designed. There are limited options in OpenSim. Initially, it was designed to supply the helper-uri only upon adding a grid and to supply the symbol only at login. OpenSim was adapted to send some region specific information upon entering a region. We have tapped into this to now supply the helper-uri and currency symbol. There is no mechanism to supply these with a transaction. Further, the viewer starts most transaction flows. For the flows that require the helper-uri, there is no way to do so if the server has not already sent this information.

      3. It sounds like you think that the purchasing UI of OpenSim allows a user to choose what currency they will transact in. This is incorrect and I don’t know where you got this idea. People can create scripted objects which could let a user choose how to purchase. Those transactions do not go through the built in UI. The built in UI is not malleable. There is no mechanism for the user to choose between multiple currency modules nor is there any mechanism on the server to handle such information. The server is not designed for multiple currency modules to even be enabled on the same region. A user clicks purchase and the viewer sends a call to the sim/region to make that purchase and the single module enabled on that region handles that call in its currency. If you’d like to build a new interface for the viewer, get it adopted everywhere, build a handler for the server, get core to adopt it, build a new event system for the money modules where multiple can be enabled, test and release that, be my guest. Please don’t pretend that is in place or could be easily put in place.

      4. Lookups…. You make it sound like you’ve reviewed this code and heavy lookups are being done at region crossing. You are wrong and you clearly don’t understand how this system works. The OpenSim server has a system for sending down “OpenSim Extras” for a region. Any module can easily add information to this. The currency module adds information that it has in memory (not that it has to look up). This amounts to two extra entries in a dictionary which are passed to the viewer. If you think this is an efficiency issue, then you really don’t understand software. There is some overhead in the viewer to replace currency symbols and update the helper-uri which were not currently being done. But, to compare this overhead to the overhead of rendering graphical frames is ludicrous.

      5. When a user does not have sufficient funds, the transaction is aborted and the insufficient-funds flow is entered. Unfortunately, without my patch, this does not work after any HG teleport and at best could only work with a single currency system per grid. That assumes it was set up correctly and that if the helper-uri is ever changed after a user has added that grid info, that they have manually gone in and updated the grid info. This patch fixes this problem.

      XMIR, please don’t speak about engineering solutions if you don’t have any engineering experience or experience with the OpenSim server and viewer code. Feel free to make suggestions, but please clearly state them as such. You have stated many things as fact which are completely, 100% false. Based upon this post, I recommend that the OpenSim community never trust anything you ever post again regarding engineering. I’m sorry to be so blunt, but the amount of misinformation is deleterious to this community.

    •' mikelorrey says:

      An avatar should be able to have a balance in whatever currencies they choose. When I tp my Kitely avatar to a gloebit enabled region, it displays my gloebit balance even tho the viewer says its KC. I have not just my Kitely avatar, but accounts on other grids all using the same Gloebit account, so whichever I log in with I have the same gloebit balance. Chris is providing a great service here, and his plugin is great for stimulating growth and competition in the marketspace.

      •' XMIR Grid says:

        Not within the same grid necessarily. It is entirely up to the grid owner to determine how the currency(s) are to be implemented on the grid. Often it is an integral part of financing the grid and crucial to its existence.
        For an avatar moving off grid, I am in agreement with you.

  3.' JayR Cela says:

    I personally think this is a good idea, for reasons I have seen in action. For instance, a smaller grid I have been doing work for the past 10 months or so recently implemented the Gloebits currency standard, and we have seen a small but noticeable growth in our ability to attract new content creators. This is a good thing, and has been the main reason these particular content creators chose to set up shop in the first place.

    As far as it creating extra lag, on the grid and or hampering region crossings, I’m sorry but I don’t follow the logic behind this opinion.

  4. Please vote up the jira –

    And for some additional detail, you can check out my post here –

    Thanks to Hypergrid Business for getting the word out.

  5.' mikelorrey says:

    I want to applaud Chris for making this contribution to viewer codebase! It is built to not just benefit Gloebit, but anyone who wants to develop a virtual money system can utilize it and ultimately grids could enable region by region currency settings so a region owner could make that decision for their own region. Potentially it could be set to enable users to pick the currency they want to use and the payments exchange will happen on the backend. This means competition in money systems, which is better for everyone.

  6. I’d like to clarify a few things as many inaccurate statements have been made here and on G+ regarding this patch. Any viewer or core dev would know these statements are wildly inaccurate immediately, but I fear that the community members without a technical background might believe them because they are stated so confidently. In the future, I’d please ask that those without technical expertise pose questions which I’ll be happy to answer rather than make assumptions. If you do make assumptions, please make it clear that you are doing so, rather than disseminating false information which is deleterious to our community.

    1. Is this anti-competitive? — NO. I wrote this patch in a way that it can be used by any money module.

    2. Will this break backwards compatibility with modules which don’t implement it? — NO. I wrote this module so that modules which don’t send region specific currency information will work the same way they always have. The mechanism (a dictionary of OpenSim Extras sent to the viewer when a user enters a region) for supplying this info to the viewer has been in the OpenSim core dating back to at least early 0.8.x. No communication protocol with the server was changed.

    3. Should grid owners who only intend to have a single grid-wide currency care? — YES. First, this fixes both the currency symbol and the helper-uri after a hypergrid teleport even if no money module is enabled anywhere. Second, if you want land purchasing to work but don’t want to set up the landtool.php file and an XML-RPC server and ask every user to update your grid info in their viewer, this makes it possible for a money module to fully implement the land purchase flow. Gloebit already does this and other modules are welcome to follow suit.

    4. Will this add to region crossing lag? — NO. The amount of work added at region crossing is negligible. The server already compiles a dictionary to send to the viewer at region crossing. A money module implementing this feature adds 2 entries to that dictionary. The viewer already parses this dictionary. It now parses two additional entries. The region helper-uri and currency symbol are stored locally by the viewer. The helper-uri isn’t used until and unless the user attempts a transaction which requires it (after they are fully loaded into the region). If the currency symbol changed (and only if it changed), the symbol is updated in the status bar (2 strings are modified). For most of the other UI widgets which have a currency symbol, these will be retrieved and marked as dirty so that they can be updated when they are next requested. This pushes off the work of modifying these strings until they are necessary, so that does not happen at region crossing.

    5. Will this add complex balance updating and money module authorizations to region crossing? — NO. This patch does not add any balance-update requests to the region crossing. It actually provides the ability to reduce messaging at region crossing and push it off to when a user requests a transaction. Gloebit currently sends a new user an IM asking them to authorize when they first enter a Gloebit enabled area. We have done this here because we couldn’t consistently take over the insufficient-funds flow when a user later attempts to purchase. This patch allows us to consistently handle that flow, which means we could give grid owners the option to stop asking for authorization at entry and only prompt a user when they attempt a purchase.

    6. Why did you design this to happen at region crossing rather than when a user attempts a transaction? — Lots of reasons which are rather complex, but I’ll do my best to summarize here. First, the currency symbol is needed immediately. A users balance and the currency symbol are displayed in the status bar at the top of the screen. When these are incorrect, it confuses users well before they attempt a transaction. Second, designing a new communication protocol between the server and viewer requires buy in from core and all viewers and could potentially break compatibility with second life. This makes it incredibly hard to gain adoption and take a very long time. It is rarely the right approach, and an engineer should always try to use the communication protocols available before making breaking changes to existing protocols or adding new ones. I determined that using this communication protocol at region crossing was best. It has virtually all of the upside and none of the downside of attempting to modify communication protocols for transactions. Also, it was suggested by Cinder Roxley and I agree with her assessment that this was the place to send this data.

    7. What do you have to say to grid owners who think it is a bad idea to allow different currencies in different regions? — That is their prerogative and we are not preventing them from making that choice. They control their grid and can choose to only allow a single currency across their grid. This patch does not change that. If that grid is hypergrid enabled, this patch improves the experience for all HG travelers to and from that grid. If that grid doesn’t want to mess with an XML-RPC server, landtool.php, currency.php and the helper-uri, this patch makes it so that their currency provider can handle all that hassle for them. For grid owners who do want to support multiple currencies (and there are many such grids and many users who shop on those grids), this patch improves the experience for all of their users. I completely understand that not everyone will want to use a new feature we create, but I’d ask any grid owner who seems intent on preventing adoption of this patch and inso doing, preventing other grid owners from having the option to use this new functionality (even though it has no negative impact on the grid owner who chooses not to use it), why they are so intent on controlling what other grids can do and how those grids serve their users.

  7.' Area Fiftyone says:

    This is all wonderful, and i applaud Christopher Colosi for the effort. It’s just that the whole approach is completely wrong given the time we live in. I love the idea of Gloebit but it should stop pretending to be a currency we can trust (because it can’t be trusted), instead Gloebit should act as an intermediary between a trust-less currency (such as Bitcoin) and users of opensim.

    •' Cinder Biscuits says:

      …. stay tuned. 😉

      •' mikka says:

        Isn’t disqus fun.. yes trying to stay tuned, even fired up my old viewer jira id to watch the colosi pitch. Amazing to see FS as being dominant in OS ( I don’t use it but fun to watch) G+ even worse =^^= But yes it is an interesting. From the protagonists medium thingy ‘OpenSim was a spin off of the Second Life virtual world platform.’ to ML ‘competition in money systems, which is better for everyone’ ( do like that perspective as a Euro user in both senses ).
        Have no problem with a proprietary currency wanting to try. A unifying even so go for it. But even with PP rates out of existing US sales don’t see why I should bother.

  8. Some more clarification:

    1. Does OpenSim version 0.9.1 have changes that break some money modules? — yes, AND those changes are not related to this patch. They broke the Gloebit Money Module as well, and I had to patch it. Those changes are actually also in 0.9.0-release. They are related to land-pass sales and neither I nor Gloebit asked for those changes. I asked core not to make those changes without inviting a lot of discussion and design first and I asked them to delay rolling them out once they were made so that money module developers would have a chance to patch their modules. Sorry, I lost all of those battles.

    2. Shouldn’t you have fixed this by allowing a user to choose which currency to use when they are making a purchase? – NO. The goal here was to make a reasonably quick fix that would not break anything (like other money modules), not to completely redesign OpenSim. I’d love it if people worked with us to vastly improve OpenSim transactions and eventually implement a new system, but that would take a very long time, break every existing money module, require viewer and core devs to agree upon an interface, and it would likely break compatibility of those viewers with SL. This fix causes none of those problems and improves the functionality.

    3. Finally, let me briefly explain how transactions and currency work in OpenSim. By default, OpenSim doesn’t handle any transactions. The included default money module doesn’t really do anything. It is just a reference. At the grid level, you can set the currency symbol across the grid and you can set the helper-uri. The helper-uri is where api calls are made when a user attempts to purchase land or purchase currency. I won’t get into why these historically have been outside of the money module. When you attempt to buy an object, pay a user, pay an object, pay to upload a texture, pay to buy a land pass, pay to create a group, etc., these api calls are handled by a money module. There is no grid wide money module. The money module is a region module. What that means is that these calls are handled by the sim or region you are on when you make the request, not by the grid. For grids with a single currency across the grid, they have the same money module installed on every sim across the grid. In cases of grids which allow users to purchase in multiple currencies, users do not choose the currency at the time of purchase. For all built in UI transaction methods, there is a single currency per region. To use a different currency, a user would have to go to a region which has a different currency module enabled, and on that region, all built in transactions would happen in that currency. The other option is to use scripted vendors. These vendors don’t use the built in interfaces. They can call their own external APIs directly (for instance on some web server). They can allow a user to choose the currency to use and they can use a currency which is not the same as the money module for that sim. But, they don’t work via the built-in UI or via paying the vending machine directly. Finally, it’s not simple to just start allowing a user to choose which currency to use when making a purchase. First, the seller would need to have set the price in every currency they are willing to sell in. The seller would need a new viewer interface for setting their items to sale, a new communication protocol with the server to carry this information, and the server would need to modify or create a new db table to store this additional information. These prices would need to be presented to users so there would need to be more communication and UI changes to get this information back to a purchaser. The viewer would need to implement UI to choose the currency and a new communication protocol to send the currency choice to the server. The money modules would need to be completely redesigned to handle this as multiple would need to be enabled per region or they would need to be turned into robust services. This is just what I can think of off of the top of my head. I’m sure there would be more. It’s nice to say “this is how it should be done”, but it’s not that easy. It doesn’t mean we can’t shoot for that in the long run, but we shouldn’t discourage incremental improvements in the meantime, and anyone suggesting that there is a better way to improve the system should be asked to specify how and how long it would take.

  9.' Alexandre Abrial-Gayet says:

    Money in opensim opensource project …. in grid open with hg ? can be dangerous seriously i desagre thats !!!
    Owner grid need have a big t.o.s for have money and solve the problem of security of opensim before use a module money ( for all module money ! )