hello all
here is the idea i have for the moment :
create an universal module to link users to any metaverse (or website)
to do this, we need :
- an entity linked to the user to manage external profile (the different systems can be additionnal modules creating only a bundle for this entity)
- an entity to manage terminals (connector) or other ways to communicate between inworld and drupal
- an universal way to exchange values between metaverses and drupal (a kind of json or something like that)
example :
a user can have a link in a menu like "add a secondlife profile" / "add an opensim profile" / "add a twitter profile" / "add a facebook profile" etc....
then, depending on the selection, the user needs to fill some values like the loginuri etc...
after this, the user can have his drupal profile linked to multiple secondlife/opensim avatars or something else...
and then, we can build modules using these "connectors" to communicate with external profiles.
how to do this ?
im not able for now to build everything quickly and i also think that we can exchange about ideas before sprinting to a solution that is not the best one for everyone.
(to tell you the thruth, im just begining to build modules for d7 so i need to find some marks)
in this group, we have some devs, so maybe we can separate the job.
* the ui
we need to have an admin interface to manage "external profile" (entities) and "external profile types" (bundles)
we need to have an admin interface to manage "connectors" (entities) and "connector types" (bundles)
we need to have tabs or something else on the drupal user profile to link to external profiles
* the drupal entities engine
we need 2 or 3 entities built using core entity class or "entity" module
* the lsl / osl
we need to find a better "dialog menu" script
we need to create a communication protocol between inworld and drupal
we need to create a communication protocol between scripts
you can get some infos here : http://groups.drupal.org/node/123689
what do you think about that ?
Comments
OK, I want to chime in on
OK, I want to chime in on some very basic infrastructure stuff. I want to do this because there is no real application in mind for this project, and I think it's probably better to compartmentalize the functionality into a number of smaller modules that have more focused intention. Also so they can be tested more easily.
LSL can POST and GET to http just like any other useragent. You can see the headers LSL will provide here: http://wiki.secondlife.com/wiki/LlHTTPRequest and http://wiki.secondlife.com/wiki/Http_response
One of them is X-Secondlife-Shard. This tells you which grid the request is coming from. If you know a range of IPs for that grid, then you can know pretty well whether the request is from that grid or not. OpenSimulator's LSL also sends X-Secondlife-* headers.
Second Life tells you X-Secondlife-Shard:Production (to distinguish from beta grid). ReactionGrid says X-Secondlife-Shard:ReactionGrid. And so on.
This lets us build a DB of 'shard' names versus grids. Each grid can then have, for instance, it's range of IP addresses, whether or not we want to receive connections from it, and so on.
Similarly, other headers will tell us lots of information, such as Region name and location, owner UUID, and so forth. All of this information can be gleaned and used. And the reason we do this is because there's only 2k of text available to us to send information out of SL.
The next area of progress I was going to make on metaverse.module was to create a data interchange format. I got pretty far, actually, but the code is messy so it's not in the repository. And here's the idea:
I propose: LSLON. It's a play on JSON. There are JSON interpreters in LSL, but they're cumbersome. Basically, LSLON is lines of key=value with pipe-delimited lists for value. Like this:
urlencodedkey=urlencodedvalue|urlencodedvalue|urlencodedvalue
This is very easy to generate and parse in both LSL and PHP. (I also use an in-world variant that has variable type markers.. I'll post a more full description later.)
LSLON would mainly be for data returned from Drupal back to LSL, because in-world objects can just use application/x-www-form-urlencoded for their POSTs.
Hooking up the avatar UUID to the Drupal UID isn't so hard. We just do some DB accounting, as in metaverse.module. The real problem is authentication and security, so that people can't go around claiming avatars that aren't theirs, and so that this information is kept private on the Drupal site.
I'm not sure that entities are the way to store all the profile info, mainly because I think a Drupal site shouldn't be scraping profiles from other sites. :-) I'd want to have a good application in mind for that kind of functionality.
And, of course, this is all in D7. And much of what you're talking about is in metaverse.module.
about headers / lslon / entities / security
about the headers
the secondlife framework is catching these headers.
for sure we can use them but i dont trust them in opensim because most of the people don't use them in their grid except the big ones (need to setup shard = "OpenSim" in OpenSim.ini).
i think that the only solution to distinguish a grid from another one is the loginuri.
we can not add it automatically but the owner of a terminal can add it in the lsl variables.
about the lslon
i have joined some links here http://groups.drupal.org/node/123689
if you have a link to the lslon protocol (that i don't know) please add it to this wiki page
i think that it is a good idea and this protocol can also be used between lsl scripts
we can separate the data from the methods names, this is why im using integers in my scripts to call functions using llMessageLinked (see https://spreadsheets.google.com/ccc?key=0Au6l3O6rGSAKdEVzbnJOVjFOZ3VfbWM... )
we just need to define one protocol and all use the same one
about security
this is the biggest problem and for the moment, i have no idea for that.
the communication between the website and lsl can use a password and a key, ok, but if someone is using a copybot to copy the terminal and rez it close to the other one, nothing can prevent it and distinguish if the terminal is safe or not.
we can use agent name set in headers, but the terminals should be able to be shared between people (for example, a friend is giving away terminals to allow registering on the website from inworld).
about entities
the idea is to use "connectors" that are entities to link any module to an external system.
we can create entity types to create connectors for secondlife, opensim, and any other virtual world (in the same time, why not other websites...)
this can be a simple single module to manage entities and then build a set of modules to make connector types for each virtual world.
the old secondlife framework could be integrated in one of these connector types.
i think that we should separate secondlife from opensim because each of them can provide options that the other one can not have (like opensim can send xmlrpc but not secondlife, secondlife can use a media web page on a prim and not opensim... and maybe some other things in the future...)
the external user profile is just an application of that but other modules can be built for other needs like a vending system or rentbox etc...
why this module ?
people are asking to have a sluser update for d7
we already spoke about that in another group that was deleted
we spoke that nodes are not adapted to store information because nodes are designed for website pages content and the d7 entities system is a good way to store other kind of data like user profiles or terminals etc...
sluser and d4os are script that helped me to learn some things in drupal
i think that sluser needs to be completely rewritten (d4os also but this is another story... :))
from my experience with these tools, i could see that :
- my joomla modules mostly downloaded are slcontact and slvendor
- Austin Tate that knows the subject told me that a module like sluser should be multigrid and multi sites
- i consider the secondlife framework abandonned (and we need something for d7 (even if the modification to update it is very easy) and other worlds like opensim, opencobalt, etc...)
- since 2007, the only person i have seen making opensource systems to link sl to websites are Phrearch Miles (who left joomla and made a python script to manage grid (hwios)) and Skidz Tweak (who helped me to debug slvendor and then built his own vending system)
then, last year, i could meet 2 persons (Mile23 and Lennard) that are able to build modules (i was very happy to see that im not alone)
some people are using sluser to link users (registration to the website from inworld), some other ones are using it with the user points system to make like a bank system (at their own risk)
the idea of this module is to replace the secondlife framework module but not only reserved for secondlife and opensim, the other worlds can be added with entity types by third party modules.
to resume
and the goal for now it to build at least the main module and 2 connector types (1 for secondlife and 1 for opensim) then after that, we will be able to build other ones
Headers: Yes, grid
Headers: Yes, grid maintainers need to set it in their .ini. Many do. It's worth publicizing. Also, OpenSimulator gives us:
http://opensimulator.org/wiki/OsGetGridLoginURI
http://opensimulator.org/wiki/OsGetGridName
http://opensimulator.org/wiki/OsGetGridNick
This means right off the bat there are LSL scripting inconsistencies.
LSLON is something I invented, and I'll have to expose it to the public in some useful way. Coming soon to a github near you, probably. It's not a protocol, but more like a data interchange format, like JSON. It would be up to the caller and receiver to know what data to pass back and forth.
Security: I'd say that a public-key encryption system would be best. I was trying to work that out in metaverse before I lost interest. The LSL script is compiled with a vendor's passphrase in it. That passphrase is also in Drupal as a setting. Generate a hash based on the key and, for instance, the owner's UUID. Drupal looks up the user for the UUID, and if there is one, does the hash and compares.
Entities.... :-) I haven't fully grasped how entities relate to this project, other than giving a node-agnostic way to store stuff like, for instance, a grid's data. I'm not sure what you mean about connectors... For OpenSim and SL the mechanism is the same, and of course they can be exposed to Views or Panels or what-have-you.
As far as the future of secondlife.module, it's in hibernation. :-) It could be updated, but it has that problem in that it's called 'secondlife.' I don't want to speak too soon, but it might be getting a co-maintainer. A D7 version of it wouldn't be too hard to crank out, and someone on the issues queue mentioned having done it already.
"the idea of this module is to replace the secondlife framework module but not only reserved for secondlife and opensim, the other worlds can be added with entity types by third party modules."
I think it's a bit ambitious to say any other world. If the other world (Blue Mars?) can be made to follow the same API, then no problem. My goals would involve having a platform for OS/SL users to link their various avs to one Drupal acct, and be able to manage some of the web stuff from in-world.
Basically to finish metaverse.module :-)
Desired tool request
I have my Drupal site, and I have a concept I would like to see...
I maintain a store venue in both Second Life and in InWorldz. If I could wave a magic wand and have what I believe I'm looking for, I would have a tool on my website I could watch that alerts me when someone is 'relatively close' to either the InWorldz or SL terminal, and both terminals would reflect a status message to alert the nearby person I am 'online, just not present'. I would have the option of talking with them through my Drupal website, and they with me as with an Instant Messenger. I would also have a link on this page that could teleport me to the terminal location.
1) I wish to know when people are in a given venue, and what venue
2) I wish them to have a clue on my online presence
3) I wish some means of instant message
4) I wish ease of teleporting to the venue location
I would have traffic encryption on a high priority. While I'm wishing, I would want some form of asymetric key or secret that would allow everything to be exposed (such as on an untrusted OpenSim) but still protect the data stream over the wire. Wishes being fishes 'n' all.
I can see where merchants that hold multiple venues across multiple grids would find this sort of tool very handy. So much the better if I could set up the tool on my website for others besides myself to use. I would, of course, need to authenticate them on each grid being used.
Thank you for considering my idea.