On Thu Feb 20 09:15:15 2014, Adam Roach wrote:
Keep in mind that the nominal user experience for this, once we get to
MVP, will be rooted in an address book. I'll have my list of contacts,
which includes phone numbers and email addresses. When an address book
user is activated by a user, we'll check whether the contact info
corresponds to a Loop user. If so, we place a call in that direction;
otherwise, we offer to create a "call me" URL and (if possible)
deliver it using the contact means (email or phone/SMS) corresponding
to the address book entry. So, when we create the URL, we'll know who
the user intends to give it to.
This is important because it allows us to say "You have an incoming
call from Alexis" rather than "You have an incoming call from some
random person." The delivery of calling party identity is simply
considered table stakes for a communications service nowadays [1].
I'm confused. Isn't the main use case for the "call me link" making it
very easy for someone
who doesn't already have an account to become engaged enough with our
tool that they will be interested in upgrading to get an account to get
the better user experience you're describing?
Otherwise how do we expect to convince enough people to bother to
create a Firefox account, given that the network benefits (i.e. the
systems that all your contacts are already reachable on) have already
accrued in other systems that are believed to be relatively well-liked
(viz Skype, mobile phone)?
Dan
In your proposal, I don't understand what is the "serial #", and
especially why it can't replace the version as you specify it.
The "serial number" is different for each and every URL issued, and is
used for revocation purposes.
The "version" allows us to transition between schemes in the future,
if we need to change the properties of the URL -- it allows us to
unambiguously change the format of the {token} [2]. For example, if we
decide to re-key the HMAC, we can increase the version number. The
same goes if we decide to add fields, encode them differently, or even
go to a completely different design (such as a sparse key into a
database table). It gives us an "out" to reconsider the design of the
token if it doesn't meet future needs.
It seems straightforward to just have a serial number (randomly
generated and not auto incremented, because auto increment is harder to
scale) that we can revoke if needed.
Sure, random would work, as long as we have sufficiently low chance of
collision. It would be a pretty big error if revocation of one URL
caused a different URL to also be revoked because they shared the same
random identifier.
It means that before displaying the app and accepting a call (we can
also chose one of them only), we will have to check in the database if
this serial # is still a valid one.
If I understand you correctly, you're describing an intended feature
of the system, not a problem: the check for revocation of a serial #
is part of the revocation mechanism.
We could let the user chose what's the duration of their call-url, and
default to something specified in a configuration file if the user don't
specify anything.
Right, that's the intention.
Ideally, we also want the ability to identify multiple versions of URL
encodings, should we decide to migrate to include an enhanced scheme
in the future.
If you're thinking about having multiple versions of the service running
at once, then I think this shouldn't be handled this way. When you ask
for a node to the token server, you ask for a particular version of the
service, and you get an endpoint to this service.
This allows us to not have to deal with multiple versions of the API in
the server code. If that's not what you're refering to, can you provide
more info?
It's not multiple versions of the application; it's multiple versions
of the URL field format. At any given moment, any single version of
the server application running would be expected to be able to parse
the current URL format, plus any of the previous URL formats that have
been issued within the ${max_url_duration} seconds.
Yes, this requires some conditional logic in the server code when (if)
we decide to change to change the token format, but that should be
pretty lightweight.
____
[1] cf.
http://pimcore-1872623517.us-east-1.elb.amazonaws.com/infoservices/resources/whitepapers/whats-next-in-caller-identification-services#.UwYya8dn9N0
[2] Since the current plan is for all tokens to be time-bounded with a
known maximum possible duration, the general means of transitioning
from token format "n" to token format "n+1" would be to introduce the
new format on the new version number; have both formats running
side-by-side for this maximum possible duration; and then retire
format "n" altogether.
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
