Changes to the listen URL -- plus new expected client behavior proposal

[Jeff Lindsay]

FYI, there may be some changes to the listen URL soon. We're moving to
a more capability URL scheme, where each URL is generated for a user's
specific local notifier. For example:

http://api.notify.io/v1/listen/168eb3d52dee591c7b6a00aaef043095d75eb961

No api_key, a longer SHA1 hash that represents the capability. This
secret URL can also then be shared with friends that you want to get
your notifications (since later you can treat these as channels that
notifications get routed to).

We're also going to create a common dotfile (for linux/mac systems) in
~/.notifyio (or something like that) that will be a plain text file of
a list of URLs like the one above. Each line is another URL that will
be listened to. This way, clients have a common way of storing
notify.io URLs... this also leads to our ideal "installation"
scenario:

When the user sets up a new pull based notifier on notify.io, they get
a download. But it's not an executable, script or anything. It's
assumed they already have a notify.io version of Growl or GfW or some
other client bridge. This file is a notifyio file (or something) that
will be opened by a program (ideally Growl, GfW, etc) that just reads
the file and adds the contents to the .dotfile.

This way, users have or install a notifier, then for each channel they
create (and there will be one default channel when you sign up), they
just download a file with a capability URL that is handled by adding
it to the central notify.io dotfile.

We had a really long discussion last Saturday about how this should
work. We don't want users to run scripts. We don't want users to have
to configure things. We do want advanced users to be able to have more
control. I think this works.

[Jeff Lindsay]

Also, as pre-alpha, I don't think we'll make the listen URL change on
a v2 api ... but I will continue to support the old URL listen scheme
on v1. But ideally you shouldn't be effected because to clients, it's
just a URL. If you're already getting it from a dotfile or some static
configuration, you won't have to make any changes!

[briandunnington]

so what exactly is represented by the hash? what types of
'capabilities'? how does the end-user's client affect the capabilities
and/or url? treating it like a notification 'channel' makes sense to
me, but i am unclear how that relates to the notifier client.

i was about to hit 'send' and then it dawned on me - are the
'capabilities' that are mapped to the hash essentially a list of
sources that will be notified on that channel? so if you had 10 total
sources, maybe a few are on one channel and a different set on another
- allowing for mix and matching of who gets which notifications? still
not sure exactly how that relates to the end-user's client. and i
could be way off base - i will just stop typing now and let you tell
me what it means instead of guessing =)

On Nov 11, 1:44 pm, Jeff Lindsay <progr...@gmail.com> wrote:

[Jeff Lindsay]

Capabilities are like security tokens. Capability URLs are unique, unguessable URLs that represent both a resource and certain privileges. Several capability URLs may be used for a single resource, which allows you give them to various third parties as keys ... but you generally have the ability to disable a capability URL, preventing that one party access, while the others still have it.

So it actually doesn't affect the client at all. If you assume all the client does is "listen on a URL for notifications" ... it doesn't care what the URL is or what it means. In this case, these capability URLs represent access to a channel. A channel being something you can route source notifications to. So yes, a list of sources. But the client should have to care about that. They might care about the sources, but that's independent of the URL used to get notifications from them. So really it's not much different from how things were.

Except that you might want to start being able to support multiple HTTP connections with separate URLs. That's not necessary, but an ideal case. Most people will have one. But advanced users may want to share a particular notification channel with somebody else that's already listening on their own channel. I think it's easier to support multiple connections on the client and easier for the user to "share a URL" than to try do complicated cross-user routing (and UI to support it) in the notify.io app. Especially since it's not a common case (but one that should be supported).

--
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things