Using a web service for group-based services maintainance
I've been doing a little thinking about group-based networking and services. Here's the situation. Let's say you have a small group of people, and want to offer some kind of online service to them (like a private chat area, mailing list, etc. etc.) That's all well and good, but maintainance of 'who's in the group' is hard. You need:
- the ability to let other 'admins' add/remove people
- a nice UI for doing so
- a nice UI for people to request to sign up
- decent authentication, username/password
- the usual stuff that goes with that -- 'I've forgotten my password, please email it to my listed address'
- did I mention a nice UI?
The traditional approach is to code all that up myself, in my copious free time presumably. Urgh, talk about wheel reinvention on a massive scale.
I'd prefer to use something like TypeKey, a web service that exposes an API I can use to offload all this hard work to. Initially, I was in the 'ugh, Typekey 0wnz my auth data' camp, but I've eventually realised that (a) they're not quite as evil as MS, (b) they're not quite as stupid as MS (deleting Passport accounts if you don't log in to Hotmail, which is only one of the services? hello?!), and (c) it's actually really convenient having a single-sign-on for weblog commenting.
Having said all that -- TypeKey's out. Unfortunately, it only does authentication, without dealing with group maintainance. However, social networking services are all about groups and group maintainance.
Running through the options -- LinkedIn, Friendster and Orkut are all grabby and gropy and 'my data! mine!', so they're out immediately.
The next step was to take a look at Tribe.net, which seems kind of nice, has Marc Canter involved if I recall correctly, and had a good rep for open APIs -- but as far as I can see, all they've got really in that department is FOAF output, and TribeCast. I could list all the group members in a FOAF file, but without authentication that's pretty useless since anyone could claim to be one of the FOAFs.
To get into more detail, here's what's needed:
- 1. Authentication, when someone needs to log in to do something
- 2. Group maintainance, to move people into and (poss out of) the group
- 3. Group membership validation, to see if they're in the app's desired group
Authentication: After I came up with this page, I mailed the flickr API user group, and a while later they produced the Flickr Authentication API spec. This spec contains everything needed for third-party web apps to authenticate both a user, and themselves, to Flickr. Truly awesome!
Group maintainance: this doesn't need to be through the API at all; in fact, it's better if it's doable through the SNS' nice UI.
Group membership validation: Once a user auths themselves, they've authenticated as a member of the social networking service in general, not as a member of the specific group. Not so useful. So to finish the process, we need to determine if their username is in the group.
The flickr.groups.getInfo API call doesn't return the names of the group members, just a count of how many members the group has. However, Stewart Butterfield in a mail to the yws-flickr list on 21 Aug 2006 mentioned that a groups.getMembers method "is planned", and its omission was a "crazy oversight".
flickr.people.getPublicGroups may allow access to this another way, in the interim -- given a user_id, it'll tell you what public groups that user is a member of.
This means that private groups are out, but it's possible to have a public but invitation-only group; in other words, membership can be controlled easily.
Some further pointers:
flickr.urls.lookupGroup converts a group's URL to it's NSID (a unique ID string used in Flickr);
the Flickr::API perl module.
Comments here please!:
Try Quiknets.com 1. username/password required to be a member. 2. members can set up, or join , by invitation, any "group" formed and maintained inside a WorkSpace/ meeting Room, each with its own Access List (drawn from members only) (- i.e. the second authentication-), and inside can share docs, exchange messages, chat, create private webpages, etc. 3. using the Telecryption option- not currently available except by specific enablement of new users- any messages or files transferred between members or into/out of "meeting rooms" are transparently encrypted in a unique new system. (Meanwhile the whole network can also be accessed in secure- SSL- mode.) Meeting Rooms can therefore be automatically encrypted, but decrypt transparently only if you are authorised (with the password, which is sent automatically to your local system). Encryption is always on your local system, never on the server. Click in WorkSpaces to set up a meeting room- it takes a couple of seconds and no limnit on the number you can operate.(Sent by [email protected])
Thanks Brian -- but what I'm after is a web service to authenticate members of a group, so that I can hook that auth into *my own* web apps, rather than use existing apps. --Justin