Hi Edmund, "Actually I'm _offering_ to code something for free (DTL/NSL integration with BitCoin or some other distributed currency system that someone might suggest) so that other people can charge each other. I'm then hoping that someone else would do the same to make the viewer work better with what I'd code, although I'm hoping it would be useful even if they didn't."
Truly in the spirit of Open Source! Sounds like a great idea. Not a programmer here, and having no idea what you have in mind, I thought I'd jump in uninvited with my own two cents if I may! What I have here doesn't include buying/selling with "real" money, because I personally don't see a way to integrate that in a decentralized manner. Not to say it can't be done though, it's just a bit beyond me at the moment! I visualize this being possible in two different ways: 1.requiring client support or 2.not requiring client support. 1) Requiring client support: The server money module makes a call to an encrypted/hashed/salted file of some sort on the client machine that has the user's current account balance. It then rewrites and re-encrypts the amount any time money is spent/received. It would be stored on the client machine to avoid any sort of dependence on a centralized resource, and the encryption would be encrypted to prevent an individual user from artificially raising their own balance. The major drawback here would be that the clients would need to support this feature, and with the current state of client development this may take some serious time. I think there would additionally be a trust issue that we would have to know the viewers were "honest" after the whole Emerald debacle. Not sure how that could be done, unless the encryption/hashing/salting/whatever were somehow "hack-proof" (as if). 2) No client support required: The same idea, except the server money module would be in charge of managing the account file. This makes much more sense, wouldn't require any viewer support, and would maintain decentralization. This to me sounds like the best option of the two. If going with #1 here, the money might possibly be used on any grid that is using any sort of credit system. If going with #2 the grid owners would need only apply the money module to the code, and the whole thing would pretty much be self-governing. Not to say there wouldn't still be security issues, but it would take alot of pressure off of individual grid owners who would like to provide an economic functionality but don't want the headache of registering as a bank or whatever. I'm not sure how (without a way to buy SimCred (SimTokens? SimChips? SimCash? SimCoins? SimBucks? SimBones?) with 'real' money) avatars would get any money to start with. Perhaps it would be up to the various grid owners to provide a 'sign-up bonus' of 1000 or so for a new account, but how to prevent people from gaming this is another challenge, especially in an environment like OSGrid where people connect their own grids to the main grid... As always, I may be entirely off the mark, so this can be considered incoherent rambling (which it may very well be!), but I just thought I'd put it out there - YMMV, FWIW, TIOLI, etc. Not to mention this email is wayyy too short to try to include everything. Why yes, I am on my fourth cup of coffee, why do you ask? ;) Anyway, while BC's decentralized nature (and I personally think this is an absolute MUST for any cross-grid currency system) is highly appealing, I'm not too hot on the "mining" aspect. It seems somehow inappropriate in an OpenSim context. But then maybe it would be more appropriate in OS than it has been for BC. Needless to say, I like the idea however it works out. Cheers, ~!CJ _______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
