Sadly, Clef is shutting down in a couple months. If you haven't heard of it, it was a clever way to use your email and a mobile app to sign in to websites. I had integrated Clef logins to indieauth.com as one way to authenticate your email address. Since they are shutting down in June, I am proactively removing it from the website right now.
The other method for authenticating your email address is is to receive a verification code sent to your address, which I will of course continue to support.
While I was in the code, I figured it was about time to retire SMS authentication as well. While conceptually receiving a code via SMS or email are equivalent, in practice this is not true. SMS is actually a pretty insecure protocol, and it's possible (and not that expensive) to intercept SMS messages to all phones in a nearby area if you have the right hardware.
So as of today, SMS authentication is no longer an option for indieauth.com, and you will have to receive verification codes sent to your email instead of using the Clef app. I may bring back SMS support in indieauth.com as a second factor authentication in the future.
Here is my list of providers I use now.
Many people keep asking me why I use Tropo instead of Twilio. It seems that Twilio does a great job of getting the word out about their service, so many people end up using them first. But there are a few reasons I'm using Tropo instead. Basically it comes down to features, scalability and support.
In addition to sending SMSs and calling phone numbers, Tropo can send messages over other text channels such as AIM, Google Chat, MSN, Yahoo IM, Jabber and Twitter, and can also call Skype and SIP numbers.
Tropo recently released Phono, a browser-based SIP client, so you can now do things like have a click-to-call button on your website which will use the computer's mic and speakers to make the call!
Phono also turns a browser into a Jabber client. Your browser gets an address you can use to send messages to via the Jabber protocol. This means you can quickly make a chat interface without having to build the server-side code dealing with sockets.
Tropo lets you set the caller ID of outgoing calls to any arbitrary phone number, which can be used to more tightly integrate with existing phone systems. For example, I'm using caller ID tricks for a client to route calls directly to extensions in their office phone system.
Tropo can do great voice recognition to let callers speak instead of enter digits. For example, you can prompt a caller to say "sales" or "support" instead of just entering 1 or 2 on the keypad. This is especially great for when you need to ask the caller to choose from a large number of options such as states, or cities within a state.
Tropo doesn't charge anything for development applications until you put them onto the production network. This is really great for experimenting with a new idea without running down your development "credits."
Twilio runs on Amazon EC2. Tropo runs in the private Voxeo network. "Co-tenancy is hard." says John from Netflix in a blog post titled 5 Lessons We?ve Learned Using AWS. Personally, voice data and SMSs are not something I want running in a shared environment where resources may be allocated away from a call while I'm on the phone.
Additionally, if you are building an application that needs to be secure, such as for a bank or a government agency, they probably won't allow the application to run on the Amazon cloud for security reasons. With Tropo, you can license Prophecy and run your own Tropo platform in a secure location.
I've had nothing but great experiences with Tropo support. They are very responsive to tickets submitted, I usually get a response back in less than an hour.
There are also several Tropo staff available on their IRC channel (#tropo on freenode.net) at pretty much any time of the day. There are also several community members that hang out on the channel and can help with questions and issues.
Here are some links about projects built using Tropo.
Originally posted on oakhazelnut.com by Amber Case
The reason you should know him is because he created a system for automatic location check-in two years ago. He’s been taking GPS data every day for those past two years, and he’s got major data visualization skills. And Aaron innovates. The system he built keeps getting built.
I first met Aaron at Beer and Blog when he had just moved to Portland from Eugene. I forgot who introduced him to me, but I was very excited. I’d been talking about so many of the systems that Aaron was actually building. I promptly told him to present at the second Portland data visualization group, which he did.
Since then, we’ve been working on micro projects together. I started carrying around a GPS with me starting on 12/28/2009. With the exception of Japan, I’ve been logging pretty much everywhere I’ve been.
A while ago, Aaron set up an automated check in system based on GPS coordinates. The system allows one to check into locations without having to load an interface. This was about 2 years before any of the geosocial systems were readily available. Parecki was not living in Portland, and his audience was small.
Now, social sharing platforms are hot, but they still require user action. This means that one still has to pause social flow to look down at a device, poke a few buttons, and check in. This is normal when one is around a tech-focused crowd, but should one still do this on a date? Or in the presence of a non-geek?
Checking in can punctuate social flow. I ate lunch one afternoon with and experienced this. A group of five was sitting at the table next to me. One of the guys in the group got excited when he sat down. “Oh! I have to check in on Foursquare!” he said. His tablemates looked at him with blank faces as he tapped away at his mobile device. When he realized this, he started trying to describe Foursquare in order to explain why he had stopped to check in on his mobile device. It didn’t work. There is a way to avoid this.
Early on, Parecki’s system was able to SMS messages depending on quadrants of Portland, or pre-defined locations. Every time I go home, I get a text message on my phone telling me that I’ve arrived at home. Instead of actively checking in, I can simply dismiss the message. This reduces the time and space it takes to check in because I don’t have to load an app, wait for the location, and then check in. When I leave SE Portland and enter Downtown Portland, I get a SMS message telling me that I’ve changed locations.
But there’s a lot more to the social equation than just automatically checking in. GPS is useful for a number of things. For instance, co-location negotiation, or “meeting up”, is one of the most text heavy social protocols currently in existence. It gets worse when one party hops from place to place, because one can’t constantly text their location or forward motion. Two people who haven’t met before must also negotiate by multiple texts. One might sit in a coffeeshop and wait for quite a bit of time without knowing when the other person should arrive. New visitors to buildings need specific directions in order to enter the location.
Instead of receiving a text message like “I’m late!” or “stuck in traffic”, I’ve been able to simply look at Aaron’s GPS. The picture is worth a thousand text messages. I can see if he’s left the office or if he’s crossing the Burnside bridge. If the GPS lines are squiggly and slow, I know he’s having trouble finding a parking spot.
In this situation, there is no need for text messages. Looking at a GPS map still takes user effort and load time. This punctuates task completion and social flow if one must always be checking and refreshing a GPS map 15 minutes before someone arrives.
In an effort to reduce the need to look at the GPS map, Parecki set up what has proven to be my favorite part of the entire system: proximity notification.
Instead of having to look at Parecki’s GPS map, the system detects when Aaron and I are in a certain distance of one another. I know when Parecki is near when I get a text message that says “you are 0.4 miles from aaronpk”.When I get a message that says “you are 0.1 miles from aaronpk”, I know that he’s arrived.
I can wrap up client work or finish what I am doing right up until the moment he gets there. I don’t have to waste time waiting. I get a warning “0.4 miles!” and then a confirmation “0.1 miles!”. It’s the equivalent of “on my way” and “here”, the two most common co-location ‘drags’. I call them drags because they are redundant and repetitive communication protocols. They’re actions that can be costly, especially when struggling to split concentration between driving and texting, or the sheer inability to text while on bike.
A few nights ago, Aaron created bridges as locations, so that one could be checked into them as well. I got the text message you see here on my iPhone when I crossed the Burnside bridge.
Aaron wants to take the two years of GPS data he’s gathered and use it to visualize how many times he’s crossed the many bridges in Portland. It’s kind of amusing to get an SMS when crossing a bridge.
I’ll tell you why it’s important. Computers are evaporating. Interfaces are dissolving. Innovation in technology comes from reducing the time and space it takes to preform an action, or compressing redundant actions in order to free up time. Computers used to be the size of gymnasiums. Now we have computers in our pockets, begging for attention. We’re constantly planning for our future selves. We look at Yelp! reviews to prepare our next culinary adventure. We want to guarantee that our future selves will have a good experience. We’re connecting to tons of people to do this, connecting to the collective wisdom of a data set that consists of many samples. The more samples, the more accurate the data set. Why ask one person when you can ask many?
Xerox PARC had little tablets in the 80’s that allowed everyone to see where everyone was. There were little local GPS maps in the offices, so people could co-locate more easily. One of the guys working there was very excited about the tablets. “This is the future,” he said, “in maybe 20 or 30 years, everyone will have one of these. What works within these walls will work everywhere on Earth”.
Good interfaces disappear. Good work is invisible. Good technology dissolves. A book is a good piece of technology. If the writing in it is good enough, one’s consciousness dissolves into the pages and one has a consensual hallucination of an alternate reality.
The mouse is melting. The button is evaporating. Why check in physically when you can do so automatically? “Buttons are losing their shape,” says Interaction Designer Bill DeRouchey in a recent speech on the History of the Button at SXSW, (Bill’s slides on SlideShare) “Before [the computer monitor], buttons always had a sort of tangible border around them, whether physical or visual”. Automatically checking into a location means that the button does not even have a center. It is just a state that one physically walks into, or something that occurs after a certain amount of time has passed. An environmental button.
This is very similar to a video game, in which pieces of the environment closer to the avatar are loaded more fully than far away variables. Our lives are turning into video games, with plus one follower, and plus one friend. Our phones are our friends, giving us statistics about who we are and what we can do. They are our remote controls for reality.
“Steve jobs hates buttons”, DeRouchey continues, “He sort of has this mandate to not have buttons. This is evidence if you consider how long they resisted having a two button mouse. It’s a all about hiding the buttons, hiding the barrier between us and technology”. Good design is reducing buttons.
A vehicle is a physical transportation device. There are limits to how small it can be made. But a computer is a mental transportation device. It need not be limited by tangibility.
Location sharing platform Gowalla has items that one can collect when they check in, but they have to physically check in on the interface in order to retrieve the item.
This Sunday, Parecki developed the ability for users to send geonotes. That is, an outsider can open up a Google map and drag a circle over an area.
You can leave a Geonote for @aaronpk. Just drag your cursor, choose a geo size, and leave your message!
If you leave your E-mail address, you’ll get an E-mail when @aaronpk gets your note. Also, the bar will let you know @aaronpk’s likelihood of receiving your message, based on 30 days of GPS history. You can also leave a Geonote for me as well.
When one takes automatic check-ins further, one can add streaming data, allowing one’s device to collect SMS messages for hyperlocal areas without the need for QR codes or any visuals. This could be called non-visual augmented reality.
I began the session by drawing a big grid of Portland’s on the white board. I drew 5 circles representing Portland’s 5 quadrants on the white board, and labeled them NW, NE, SW, SE and N. The circles represented ranges of ‘hearing’ that a mobile device might have to RSS feeds. I pointed out that as one progresses from street to street, quadrant to quadrant, one’s phone should understand this and automatically subscribe the user to the geolocal RSS feed for that area. That way, data could be very relevant and contextual to the area.
Aaron Parecki has developed a framework that does just this. Locations are defined by circles on a map, and SMS messages are triggered to send when one enters into the area defined by that circle. One can set neighborhoods, areas, and blocks.
Privacy is an enormous issue with systems like this. One does not always want SMS updates, open GPS map data, or text notifications of another’s proximity. In our case, it works well because we work together frequently. If, on the other hand, we were to get proximity notification texts all the time because our commutes were similar, the data fuzz would be annoying and unvaluable. We’re the only two people using the system right now. Anyone with more than 10 active friends on Foursquare or Gowalla and has probably experienced a Push Notification nightmare of endless texts.
Here’s a definition: One’s location is valuable to another if and only if that location or person is socially relevant during that time period. The basic case here is the meeting. Person A and Person B need to meet each other, but GPS data is only shared between them when they have a scheduled meeting. When the meeting ends, the data wall closes off, giving them back their privacy, kind of like a wormhole of temporary transparency between two people. This solves the problem of extreme bouts of “checkin-ism”., as well as the issue of remaining privy to one’s whereabouts all the time.
If more people were on the network, this sort of action would have to be taken. Negotiations of privacy and messages would have to be structured so as to prevent push and SMS notification exhaustion. When done correctly, the system is a valuable time saver that decreases anxiety, showing that technology is not inherently good or bad. It is design that is important.
There’s a lot more. Hours and hours worth. But if you’d like 45 minutes of it, come to our talk at Open Source Bridge session: Non-visual location-based augmented reality using GPS data.
The presentation will cover the topics discussed above. It will also highlight the advantages and disadvantages of visual and non-visual augmented reality. We’ll cover alternate types of augmented reality techniques and how they have been saving us time in the past few months.
We’ll demonstrate how we’ve been merging available technologies with custom programming to create location-aware social networks with custom proximity notification. Finally, we’ll describe other uses for location sharing, such as automatically turning off house lights when leaving for work, and wayfinding with piezoelectric buzzers. Privacy and data transparency will also be discussed.
Aaron Parecki uses trackr.eu. They have windows mobile, java, and blackberry versions of their software. Parecki says that, “when the GPS device has a lock it is very accurate, you can tell what side of the street I am on”. The program logs data about every 6 seconds, so it ends up being a very smooth line when drawn on a map.
iPhone users can use a program called InstaMapper. However since it’s an iPhone you will be limited to running the application in the foreground, which means you’ll stop tracking if you get a phone call or want to check twitter or something. But as long as the program is open you’ll be tracking. IIRC it doesn’t end up with as high resolution data as the program on my phone.
Since I have an iPhone, I can’t run a GPS apps continuously unless the device is jailbroken, so Aaron set me up with with a pre-paid Boost Mobile phone, which the InstaMapper program runs on as well.
One downside is that I have to carry and charge another device. This isn’t bad at all, because I can carry 8 hours of GPS tracking, and it feels kind of awesome to have a physical GPS tracker instead of some claustrophobic invisible mobile app within a device. Not to say that the Boost Mobile interface isn’t archaic. In a way, it’s the age of the interface that makes it nice. Switching between the two makes one constantly appreciate and consider the extremely fast evolution of interface design.
You can pick up a Boost Moble phone for $50 at Target, and get a $10 prepaid card. You wouldn’t be using any voice minutes on it, but the credits expire after some time. It would only cost $10/month to run it all the time. Over the summer I loaned a friend my Boost phone and she took it on a bike ride from NY to LA logging most of the way.
Instamapper has an API which provides a CSV file of the last 100 points logged. Aaron then imports them into a MySQL database.
Originally posted on oakhazelnut.com by Amber Case