This blog has been silent for most of the year, and since I’ve been making progress on SLOpenID v3, I thought I’d make a post to bring people up to date on where things are with SLOpenID.

Logo

SLOpenID Logo

SLOpenID is no longer in need of a new logo, and hasn’t been in need of one for some time now. Back in August of last year, I put out a call for a new logo. Well, in March of this year, my friend Trinity Coulter produced a logo (one that has been in use since since at least August this year, in the form of the favicon for the SLOpenID blog/website.

Linden Lab Brand Center progress

After my meeting with Robin last year, I’ve still not heard anything back from Linden Lab regarding my use of “SLOpenID”/”SLopenID”, and the slopenid.net domain name.

SLOpenID v2

SLOpenID v2- the version of SLOpenID based around a WordPress MU install- has been officially retired. There wasn’t sufficient demand for the WordPress-based features to continue development and maintenance of that aspect.

The blogs housed on my.slopenid.net now redirect to their sw.slr pages. This should allow anyone who used the Provider facility to make use of the SLOpenID v3 delegate feature implemented in sw.slr.

SLOpenID v3

SLOpenID v3 will- at least initially- be concentrating on the Consumer/Relying Party side of things, as opposed to the previous generations of SLOpenID concentrating on the Provider aspect. SLOpenID v3 apps will have their logins implemented in such a way that the Resident enters their Second Life username, and not their OpenID (aside from the initial association). As always, SLOpenID will never require Residents to enter their Second Life password- and with v3, no password should ever need to be entered on a site operated by Marvulous when using SLOpenID.

A beta version of a SLOpenID v3 application is currently available- a revamped version of the old relationships manager beta test moved to production location due to providers having issue with the .name TLD. Although the association process is fully operational, I’d prefer to keep the flow of beta testers to a minimum (SLOpenID alpha testers get preference!), so that I can concentrate on fleshing out the relationships manager. At the time of writing, the beta app uses the SLOpenID login process, then presents the user with the relationships manager form. Submission of the relationship data isn’t enabled yet, as a new parser/validator has to be written.

I may also consider adding a login link to sw.slr pages so that Residents can log into the domain without even entering their username, though this would likely be added with a JS enhancement so as to avoid modifying the caches (helping to keep the site running as smoothly as possible).

Site consolidation.

Now that SLOpenID v2 is retired, there is less need for me to keep the WordPress MU install around- slopenid.net will now act as the site and blog for SLOpenID.

Hot on the heels of the improvements to the Profile Widgets, I’m happy to announce our first foray into javascript powered content, the AHAH Edition of the Domesday Book. Rather than loading up a bulky multi-widget Domesday Book page (which in some circumstances caused Firefox to freeze), you view one profile at a time while still having the option to browse through all of the widgets.

What is AHAH ?

Dynamic, javascript powered content seems to be all the rage with the “Web 2.0″ meme, but SLOpenID’s lead developer has never been comfortable with the approach that Ajax takes. AHAH on the other hand, is ridiculously simple- two basic functions, directly injecting HTML fragments. More information can be found on the Microformats Wiki

AHAH is a very simple technique for dynamically updating web pages using JavaScript. It involves using XMLHTTPRequest to retrieve (X)HTML (http://en.wikipedia.org/wiki/HTML) fragments which are then inserted directly into the web page. AHAH is intended to be a much simpler way to do web development than Ajax: “Asynchronous JavaScript and XML.”

Thanks to the new search, the Profile Widgets and Domesday Book now have three major improvements:

1. Profile descriptions are now visible (and implemented with hResume)
2. secondlife app URLs have been implemented allowing the in-world profiles for Residents and groups to be launched from the profile widgets
3. SLOpenID’s photo resizing service is now discontinued as Linden Lab have enabled image assets to be viewed over the internet. Any calls to the resizing service will either be redirect to the appropriate image, or served the “Missing Image” texture with a 404 Not Found header.

The alpha release of SLOpenID had a feature to display the profiles of all SLOpenID users. In keeping with my quirky nature for naming things, this feature was called the “Domesday Book”. Since SLOpenID has moved onto MN:SL, I thought I’d bring back the feature for MN:SL. The Domesday Book uses the hCard and hResume microformats, enabling extra geeky uses when used with such Firefox extensions as Operator.

Anyone concerned about data privacy should be aware that all information displayed in the Domesday Book is publicly available via LSL, and is still in keeping with SLOpenID’s Privacy Policy.

Yes I’m aware I haven’t done much on SLOpenID in a while.

However, after some conversation with a few knowledgeable people, I’ve decided to migrate from the standalone PHP-based OpenID Server to a WordPress:MU-based install.

Read the rest of this entry »

I added 1:64, 1:128 and 1:256 scale levels to the SLOpenID SL Maps API. You can view the world map at these scales in the following documents:

• 1:256 scale world map
• 1:128 scale world map
• 1:64 scale world map

Yes this means that you can view the world map where each region takes up a pixel. Yes I’m aware my references to “scale” are slightly off- I’m referring to the square root of the number of regions contained in each texture.

At the moment, my rather lacklusture implementation of webmap API (I’m not as good with JS as I should be) doesn’t do any checking for non-existent images, hence the alt text displayed when you zoom right out. This is a simple case of running an is_file() check before spitting out the API results, so it should be fixed soon. Once it’s fixed, I’ll update the PHP API wrapper with any fixes

Just a little note- it’s 4-digit numeric only for now, although I’m wondering what you would think about having 1,679,616 possible combinations instead of 10,000

How the PIN is used

The PIN is used with the secret sauce in the API scripts for SLOpenID’s services. At the time of posting, only SLNTPoHTTP (Second Life Needs Time Parsing over Hyper Text Transfer Protocol) has a fully working API.

SLOpenID API scripts will be set to no-mod, with full copy & transfer perms, so as to prevent distribution of maliciously altered code. Since you won’t be able to modify the source code of the API scripts, you’ll be needing to use the linked message functions.

Security Warning

Because you’ll be using link messages, and you’ll likely be wanting to give the products using the SLOpenID services out to peeps, it’s not advisable to leave the scripts or object with mod perms on them. If you leave the script with full modify rights, peeps can nab your service PIN and masquerade as yourself (as far as the server is concerned). If you leave the object with modify rights on it, peeps can drop in a listener and grab your PIN that way, and “inject” requests. This will of course be taken care of the moment the suitable LSL functions are made available (e.g. getting the creator of inventory items, and identifying which script a link message comes from), but for now, for your own sake and ours, please take these two simple security precautions under advisement.

Other security notice

The observant among you will notice that we don’t have SSL installed yet- this is because of the way DreamHost operates, not due to any lack of desire or priority on our part. If we could, we would install a self-signed certificate while we save up for a kick-ass uber-high encryption rate certificate, but alas, we cannot.

This does mean that your passwords are being broadcast over plain text, and for the security concious or paranoid among you, this means that people do have the ability to read your passwords if they are looking. So as always with these kinds of things- do not use your Second Life Password, do not use a password you use for any sensitive accounts such as online banking, where possible, rely on the ability to change your password to a random one with the HUD. While this state of affairs is only a temporary measure, you should, as a means of good practice, avoid using the same password for different services wherever possible.