API down again?

[saqeb.akhter]

Hey looks like it's down again, I'm getting requests from my users to
integrate with notfio.com :( their api looks more complicated than it
should be but these down times are making notify.io a pretty
unreliable service.

[Jeff Lindsay]

Keep in mind the frequency of downtime is a function of notify.io's growing popularity. Think about Twitter. Luckily, it's something you can grow out of. If things go correctly, there should only be one final step in transitioning away from the unreliable architecture, but it's going to mean all old clients will stop working. Fortunately, I think I can do it in a way that will show a notification to upgrade when you start them (that links to the new client). 

--
Jeff Lindsay
http://progrium.com

[pmcarrion]

Notify Pro works properly and forwards all notifications to notify.io.
I can see those notifications on the history page.
However it isn't forwarding notifications to my Mac (via the desktop
client for Growl).

On Oct 6, 11:11 am, Jeff Lindsay <progr...@gmail.com> wrote:
> Keep in mind the frequency of downtime is a function of notify.io's growing
> popularity. Think about Twitter. Luckily, it's something you can grow out
> of. If things go correctly, there should only be one final step in
> transitioning away from the unreliable architecture, but it's going to mean
> all old clients will stop working. Fortunately, I think I can do it in a way
> that will show a notification to upgrade when you start them (that links to
> the new client).
>

[Jeff Lindsay]

Are you using the new client? (Has black and white menu icon, and run at Login menu item, called Desktop Notifier.app instead of Nio.app)

[pmcarrion]

Yes to all.

I'm Desktop Notifier, the versioin created on Friday, 16 July 2010
4:06 AM according to the Finder's info window.

[Jeff Lindsay]

Oh! Does your listen URL (in ~/.Nio) have a tilde in it? Try going to the Outlets page and Download Listen URL again. 

-jeff

[pmcarrion]

http://api.notify.io/v1/listen/b626369574334d1XXXXXXXXXX6b8ebfabd2ec987

(I've replaced some characters with Xs) There are no tildes.

[Jeff Lindsay]

If you click Download Listen URL again, you should get the new version of the link. Let me know if that works.

Sorry about this upgrade proces!

-jeff

[Mike Wille]

I think this illustrates an important issue of notify.io.  The configuration of the client is not optimal.  Even without API changes, this is problematic.  I believe the process is:

1 Download the client

2 Install the client (unzip, drag and drop, double click)

3 Download the listen url file

4 Double click the listen url file

5 Hope

If 1 through 4 aren't executed completely and in that order, you have a busted client.  Further, the end user doesn't even know it is busted.

-Mike

[Jeff Lindsay]

Right. A couple of things I've thought about to improve this:

1) Notify.io could know if you have a working client. It would work like this:

    - Install client

    - When client starts with no configuration, it gives you a link to activate

    - Activation links your client with your account

2) Further Listen URLs are installed not by a file (that you download and then open), but an iTunes-like protocol handler that will a) only work when the client is installed properly, b) make it one step (click) instead of several.

Thoughts?

[Mike Wille]

Why couldn't the client automatically download the configuration at startup if one doesn't exist?

[Jeff Lindsay]

Identification. You have to identify and authenticate an account to configure. Most clients end up asking for user/pass in the client. Alternatively they use OAuth flow that involves authenticating at the site and entering an auth code. My activation proposal involves identifying a unique client, then authenticating with a user account, and then linking the two.

The flow would be:

1) Install and run client

2) Client display a message that says click to activate/configure

3) Clicking opens a browser to Notify.io where:

    - If logged in, it activates automatically

    - If not logged in, you login then it activates

Activation would mean linking the client to that account AND installing your default desktop notifier outlet. 

-jeff

[Ben Newhouse]

Another possibility is to dynamically package in the configuration into the download, and potentially make the package self destruct (read: expire) if not activated within hours/days. So my download would be:

notifyio_newhouseb_at_gmail_dot_com_expires_oct_7.pkg

[David Reese]

> 1) Notify.io could know if you have a working client. It would work
> like this:
> - Install client
> - When client starts with no configuration, it gives you a link to
> activate
> - Activation links your client with your account

This is great!

But, how does that third step work? Your client still has to get the
listen URL somehow (or at least the key part of it). Wouldn't you still
have to do the "iTunes-like protocol handler" to get the first URL, or
am I missing something?

Is it that your client is already connected to some blank notify.io URL,
and if the server knows some client unique ID, it can pass the client
the listen URL?

david

[Jeff Lindsay]

Err, I meant anything other than encoding the data in the filename would require pre-processing. 

On Wed, Oct 6, 2010 at 2:13 PM, Jeff Lindsay <prog...@gmail.com> wrote:

Another possibility is to dynamically package in the configuration into the download, and potentially make the package self destruct (read: expire) if not activated within hours/days. So my download would be:

notifyio_newhouseb_at_gmail_dot_com_expires_oct_7.pkg

I originally spent a lot of time trying to figure out how to do that. I didn't have any luck. Perhaps you're suggesting to have the configuration in the filename? That doesn't seem very reliable. Plus it would have to pre-process the file before serving it, which complicates the process. 

[Jeff Lindsay]

Another possibility is to dynamically package in the configuration into the download, and potentially make the package self destruct (read: expire) if not activated within hours/days. So my download would be:

notifyio_newhouseb_at_gmail_dot_com_expires_oct_7.pkg

I originally spent a lot of time trying to figure out how to do that. I didn't have any luck. Perhaps you're suggesting to have the configuration in the filename? That doesn't seem very reliable. Plus it would have to pre-process the file before serving it, which complicates the process. 

 

[Jeff Lindsay]

But, how does that third step work? Your client still has to get the listen URL somehow (or at least the key part of it). Wouldn't you still have to do the "iTunes-like protocol handler" to get the first URL, or am I missing something?

Either you get a big obvious link for your default outlet listen URL, or maybe you're redirected to it once you've signed in and it's activated.

 

Is it that your client is already connected to some blank notify.io URL, and if the server knows some client unique ID, it can pass the client the listen URL?

david

2) Further Listen URLs are installed not by a file (that you download and then open), but an iTunes-like protocol handler that will a) only work when the client is installed properly, b) make it one step (click) instead of several.

[Ben Newhouse]

i mean inserting data within the package, which are often some variations on zip files.  the reason the filename is readable is purely to communicate to the user what they're downloading.  i would imagine it would happen something like this:

http://bitkickers.blogspot.com/2010/07/django-zip-files-create-dynamic-in.html

[Jeff Lindsay]

Interesting ... so the app would have to find that file it came zipped with? 

[Ben Newhouse]

well .app's are just directories.  you could just put the config directly into the app bundle, and deliver the temporary app bundle.  i think you might have to zip up the .app in order to get a web server it to serve it as a unit (or a dmg, but i can't find any python tools to do that in linux on the fly)

[Jeff Lindsay]

I think I like the idea of authenticating and activating though. Less processing, less magic. Wouldn't it be weird if my copy of the client ended up with somebody else and they just started getting my notifications? It might not be clear your download is blessed for your account, even if the filename says.

-jeff

[Ben Newhouse]

it would be weird, but how often do other people end up with your downloads?

additionally you could make the magic code one time use and then just default on the old behavior.

so internally the app would be basically be thinking

have i been run before?

no? i found a secret config key.

has this been used? 

no->use it, tell user they're all set, yes->direct the user to notify.io to activate

with this you could basically have people land on the notify.io home page

type in an email to register a username, optionally let them set a password to manage things asap, otherwise let them procrastinate

receive an email with a link to their blessed package

download and run

with this flow users won't get "new account creation anxiety" as much and if they can double click on a download they're all set to go.  the time from what is this? to this is working! would probably be much much shorter.  the shorter that time is the less people give up and the more users you have.

that is to say if we want more users given the scaling issues already :)

[Jeff Lindsay]

Well I like that you're thinking about no account scenarios... so with no password, authentication would only be via email? (Like craigslist)

As nice as that sounds, I'm worried about edge case user flows on top of the extra flow it adds. I think I'd almost prefer supporting more third party signins to ease account creation hesitation...

[Ben Newhouse]

yeah i almost just proposed 

login with google

download client

run

to be honest, i don't know if people prefer no account signup or logging in with google (fb, etc).  anecdotally, i'm hesitant to trust a website that relies on google authentication, but i'm one of billions.  i'm sure metrics could help clarify how these choices impact conversion rates.

re: the no account scenario, i would imagine in the email there would be a link to the download and a link that say's something like "ready to take it to the next level? click here to set up your account and control who can spam you with notifications" or "we've created an account, the temporary password is bananafudge, click here to log in"

re: extra flow, i think messaging on the landing page/download link would greatly reduce how many people see the edge case of you for some reason sending your grandma your personal notify.io download.  it ultimately just boils down to a cost/benefit analysis.

[pmcarrion]

I downloaded the new file.

Please note that Safari 5 for Mac automatically appends the .txt
extension at the end and you must manually change the extension
to .ListenURL

A solution would be to compress the .ListenURL file in a ZIP file so
it's expanded without any changes.

Just to confirm here are some examples of the old and new links:
OLD: http://api.notify.io/v1/listen/b626369574334d1XXXXXXXXXX6b8ebfabd2ec987
NEW: http://listen.notify.io/~1/listen/b626369574334d1XXXXXXXXXX6b8ebfabd2ec987

It seems to be working now but the upgrade process not intuitive at
all.

Thanks.

[Jeff Lindsay]

Thanks for the feedback.

The iTunes-style protocol handler will fix issues with downloading the ListenURL file with wrong extensions.

And as long as you have the new client, when we make the final switch, it should follow a redirect, forwarding client requests to the old URL to the new one transparently. 

So even though it's terrible now, at least we're heading towards something reasonable. :)

-jeff

[Mike Wille]

On Oct 6, 2010, at 5:38 PM, Jeff Lindsay wrote:

> I think I like the idea of authenticating and activating though. Less processing, less magic.
>

That is what I would recommend. That is modus operandi for just about every other client/server situation.

-Mike