Open Source InWorld version of SecondServer.net / SlExchange.com

Hi folks,

This is just a request for likeminded developers who wish to build an open source in world version of SecondServer.net / SlExchange.com

Basically, it will be an attachment that will let you browse through categories *inworld* via the dialogue and then *temporarily rezzes* the object and/or pictures of the objects you want to buy before you purchase it.

Any information collected will be revealed to the community at large (everyone will be able to see the code as well). Information collected will need to be agreed upon (probably democratically) before we even collect it.

Anyone should be able to sell to all worldwide attachments by simply dropping their object and a notecard into a 1 prim repository which they will host on their own property (and then sends the info to a central catalogue object for catalogue purposes..)

Any performance issues with in world communication should be able to be handled by catalogue caching and multiscript / multiobject request/response.

IM me for more information.

blaze, how will these temp objects get to the attachment? llGiveInventory to objects only works in the same sim.

Unfortunately Blaze, the LSL Scripting in SL isn't up to the task. We have no inworld data storage to speak of, so doing a totally-inworld system like you propose is pretty much impossible. Believe me, I prefer inworld solutions to outworld solutions!

The current outworld solutions don't charge that much to provide a very valuable service to everyone inside of SL. Why replace it?

Hank is right. You'd have to store data on notecards in order to avoid stack heap collisions, and since scripts can't write these yet, any central repository would have to be updated by hand. It would be a pain, and if a lot of people were using it simultaneously, very slow.

Well there actually *are* ways to store data but they are cumbersome and involve many scripts.

Why not make it a web based system?

-AP

As the LSL scripter for SecondServer.net I can telly ou this is not possbile for 2 reasons. The first being that an LSL script can only hold "so" much. 2nd, if I give out the source to the SS.net vendors you can kiss all your "privacy" goodbye. So on that note we will not be releasing the source for the SS.net vendors.

I dont think they were talking about getting ss.net code but instead writing their own.

I might be mistaken, though.

-AP

Ah! Yes writing their own will be possbile!

We have practically unlimited inworld storage! It just happens to be partitioned into 16K blocks. Between that and message linked and it'll do just fine. That part isn't really cumbersome at all .. at least not anymore cumbersone than anything else in LSL is. And if it does for any reason become difficult, we can always use offsite storage.

Any programming task is as simple as the well known backup option

As for the temp rez, I have a fleet of 16 m2 spaces I'll donate to the cause. Maybe a linden might be kind enough to donate tier. Who knows. Not exactly a big cost, either way.

We can also temp rez from our inventory as well. Say, use the dialogue (12 options now! woo! .. to rez all the 'picture windows' (which have textures of the objects/animations/etc) for a category and at the bottom of each has button which says - "give me this object to rez before buying" (you get the idea).

Object gets sent to avatar's inventory, avatar rezzes it to check it out before buying.

As many times as he wants. In fact, he can give it to his friends as a sample.

Truly, the only challenge will be inworld object 2 object communications. I hate having to wait a couple seconds for anything. However, I think between caching and hopefully improvements in this area from the lindens and it won't be a big deal.

The problem with using multiple scripts is link messages, which are not guaranteed to actually arrive. I have seen scripts drop link messages intermittently when sim performance is in the toilet, particularly if you send many of them in rapid succession.

Maybe they've got that working better now, I haven't actually tested for it in a while.

THis is a problem with any solution. I have increasingly used an 'ack' approach to ensure delivery with everything as any kind of message (email, xml, llsay, linkmessage, etc) is pretty much toss it into the wind and hope for the best.

Why not just start to use offsite storage for everything instead of only starting when it becomes "difficult". this is what we are doing now and it's FAR better then storing in SL. I'm not just pulling things out of my hat here, I know the limitation of LSL (by now I hope so!) from what should be and should not be inworld. I have tried and testest many ways, and offsite DB handling is the best for this kind of volume!

Going further from your "toss in the wind" email IS the best solution for important data. Unlike all the other means of communication, if the email system is down... the actuall emails WAIT, they don't just happen. So whenever the email system comes back online, you'll simply get a pile of emails at once! (this has been proven and tested)

Adding: With the type of data manipulation we are doing server side, LSL could not handle it! It would be simply too slow (or never happen, overflows) to be practical.

I donate 10000 L$ prize money for first functioning open source implementation of this

If you write down clear specification maybe more people are willing to donate

Theoretically, object-2-object communications will be always be faster, latency wise, inworld than outworld. But it's an open source project - no room for anyone to get religous about anything.

No need to replace it if

a) A pure and well functioning inworld solution is created by the private versions
b) purchasing data does not go to the connected but rather to the meritous. In community hands, listing purchase data can be very powerful for the community good. As long as it is released in an open, fair, and equitable manner.

Also the price comes down. 10-15% is too much, I'm afraid.

While what you say about storage and linked messages is true, it gets cumbersome. It *can* be done, yes .. but should it? One would basically have to write a simple database engine to handle the queries (actually it would more resemble a filesystem) and it will bog down rather quickly. The error & exception handling for just the data storage are a monumental task for something this large. Performance will suffer as a result and by extension reliability.

However, creating an open source version that uses a website w/database is far more attainable in the short run. Something like that wouldn't be too difficult to pull off & I am guessing a few people might be inclined to offer some help. I probably would.

-AP

Oh, I'm never religous when it comes to development. Offsite storage wouldn't be a problem. Not as sexy, but that's OK.

As for the website, there a few things to consider:

a) a website version already exists which is free (secondserver.net)
b) a website detracts from the immersion of SecondLife
c) Harder to maintain as you need to maintain a second set of images for vendors / upload pictures / etc
d) the lindens are theoretically going to make things better, so an inworld solution will improve over time.

Free software should be Free as in Freedom, not Free as in beer http://www.gnu.org/philosophy/free-sw.html That said, there is nothing wrong with either site that currently exists. If we work on something like this, it should be to *augment* what is currently available and not to replace it. There is always a place for closed proprietary systems. An open version would simply allow more people to enter the arena, which creates healthy competition, which is good for the market & the consumer.


Indeed. Perhaps we can think of a hybrid version/method.


Hrm, I dont know. There are pros and cons both ways. A lot of the image maintanance can be automated to a certain extent.


Yes, but they have also said they aren't going to increase the script memory signifigantly in the near future, if at all.


Start a group for this project. I'll join it. We can create a group forum here to discuss it and perhaps get some other folks interested.

-AP

I'll match Anshe's prize money with another L$10k for either an open-source in-world version or an open-source duplication of the web-based version.

~Ulrika~

Let me explain why an open source version would be a bad idea...

Nexus gets MrX's vendor system... wow it's open source! yay lets go see what triggers a "give object" when someone is bought! Now lets go see what the names of the object holders are! OH cool they are called object 1

Now everyone knows the give object query is [serveruuid]@lsl.secondlife.com subject is GIVE_OBJECT message is [useruuid],[objectname]

WOW! now all I have to do... is find myself an object distributer... get the uuid (about 2 secs) take a peak inside and see the names of the object, and make my own email sender! Nexus just got an infinite supply of that users stuff! wow! And you guys are worring about privacy with the CURRENT system which is behind closed doors.

Pfft. Just generalize the code and leave the details to the end user. We're not looking for a skeleton key, we're looking for a basic chunk of code that can be modified once adopted to be secure through obfuscation, authentication, and encryption.

~Ulrika~

Open security is not impossible, though I agree can be tricky. We may need some secret which will be in a non modifiable script, or we can utilize rsa key generation.

Another way to ensure payment before delivery is to double check secondlife.com/account with code which scrapes it. A reason why offsite capability may be necesary.

Security through obscurity is not security at all.

Obviously one would not design a system to be so easy to hack.

In fact, I think that it is arguable that an open system can be more secure. If more eyes find ways to exploit it, then those can be fixed, while a proprietary system might rely on the fact no one has easy access to the code as a method of "security".

For example, in the above scenario, the in world client should be expecting a mesage from the server with a specific subject. In that message would be the name of the next subject. And so on.

-AP

Edited to provide a basic example of minimal security.

That still doesn't solve the problem you quoted me on.

What's the point? Why do you want the Gigas code? Take Gigas code generalize it... and you have a normal vendor, you won't even be able to connect to the Gigas network. no offence, I don't want you to connect to the gigas network using the same protocols we are going with our closed source vendor. Think about for a minute... think of the griefing/cheating people would do!

I don't want something anyone can hack at... I want customer confidence, it takes one idiot to a) revoke L$ change when you buy somethign and you pay too much, b) simply not give the item. If that happened NO one would ever trust those vendors again! So keeping the code secure is the 1st priority.

P.S. An obscure code is not a secure code... it's waist of memory!