Friday 28 September 2007

Where have all the gadgets gone?

All existing gadgets are invisible to the gallery, until you publish them.

You can always see your own gadgets, but you must edit a gadget and pulish it to allow others to see it in your gallery.

Obviously the gallery is far from complete..

Wednesday 26 September 2007

Calls and messages back

An admin can now edit user details - as has been the case previously.

Calls and messages should all be working normally.

Blocks are entering the building, but are not visible yet.

Friday 21 September 2007

New URI : mojo.bt.com

As of this afternoon you can now access Mojo through the following URI(s):

http://mojo.bt.com and even
http://www.mojo.bt.com

So theres no excuse for not coming to visit :-)

Monday 17 September 2007

Balance

So you can now check your balance from a simple URI, see this ruby example:

"/users/#{username}/balance.xml?digest=#{hash}&gadgetkey=#{GadgetKey}",

"/users/#{username}/balance.json?digest=#{hash}&gadgetkey=#{GadgetKey}",

Sunday 9 September 2007

More than one

The relationship between users, services and applications always becomes an issue as different use cases come to light.

From Mojo's point of view, the user takes responsibility for payment when using a gadget, with one user having a single account. The gadget is just a trusted intermediary.

This model will doubtless always exist, but needs to be expanded to work with different scenarios:
  • A company wants its staff to use a corporate gadget. The company will pay for all use, but wants to deal with staff user management internally.
  • A media company wants to promote a new service with a fancy gadget. It will pay a fixed amount of credit that matches the campaign budget. They want to limit any one user to a few calls each.
  • A group of friends all want separate user accounts but want to share costs. They also want access to group audits.

No doubt our users will have more to say.

Friday 7 September 2007

mojo.treeho.us

Mojo live is now on mojo.treeho.us - no funny port numbers needed!

Site Updated

The mojo site has been updated with the final touches to the new design, a new 400 error page, a new image for the 404 error page, updates to the Developer Guides, a user can now edit their own details.

Thursday 6 September 2007

Lets separate

You will need colon separators now when constructing your digests.

Either

username:gadgetkey:gadgetsecret

for getting feeds or

username:gadgetkey:messagename:gadgetsecret
username:gadgetkey:callname:gadgetsecret

for posts.

See /howtos for details

Wednesday 5 September 2007

Change, change everywhere

Come back for your daily dose huh? Well, have we got news for you!

As we approached feature complete, we let some of our developers here in the office loose on Mojo. We're pleased we got lots of thumbs up and lots of feedback. Some of the changes we've made include:

  • No more hashing on parameters
    • e.g. previously we supprted parameters such as message[name]=messagename
    • Now we support name=messagename. Much more pretty we think.
  • We've got rid of the term api_key, now we're using gadgetkey as a parameter.
  • You now get a nice 201 status code when you create a call or message instead of 302. Check the Location header in the response for where the resource has been created.
  • We've also updated the UI, like it? Let us know.
Robbie

Saturday 1 September 2007

Gift certificate (future story)

One of the early ideas that our chief web fiend has coveted is that of unique URIs that are good for one (or more) calls. This gift certificate would probably be a time limited credit, and maybe only for a particular gadget.

It might sound as if its just a strange way to give credits to another user, but that's not quite true. For a start, a non Mojo user could, in theory, use a gift certificate, though this may not be required. A gift could be given to an anonymous recipient, something not possible for a credit transfer. And a time limited gadget promotional offer would make good marketing.

The mechanism isn't too important; the certificate must match a record in Mojo and so is quite secure. Sending the uri itself to the server should be enough to redeem it.

Address book (future story)

(This blog is for talking about whats new on Mojo, but I'm just going to cover a couple of things that are whirling about in the sea of future stories.)

In most cases an address book is simply a mapping between a name and a number, and exists purely for the users convenience. And many would be quite happy if it was left to a client to implement. However, it might be appropriate if the audit lists (i.e. the list of past calls and messages) could display names as opposed to numbers. And of course it would be nice if a Mojo user could use the same name in any gadget. And it might be a useful privacy feature if a number need not be displayed in audits or the UI.

The downside of all this is that Mojo would need to accept both numbers and names from requests. This is looking less of an issue as a notional prefix ("tel:", "sip:", "name" etc.) will probably force its way onto us sooner or later.

Would the user worry about Mojo storing this private info? Just encrypt it in the database.