I think building our infrastructure around free things that can be taken down at anytime is the wrong way to go. This "API services" should not be encouraged. Give us the source and let us run it on our own servers, let us modify it the way we see fit... This is what should be encouraged. "API library services" is just a lame way to get people locked down to a set of APIs that they have no control over.
Personally, I just ignore these services because virtually always the risk of building on them and having them suddenly disappear outside of your control far outweighs the time they save you in building your own thing.
Managing avatars has non-obvious challenges/headaches:
- uploading images, downloading from services, and processing images to the right size should happen asynchronously. That's not easy in every web framework, and even when it's easy, it's mean you have to manage that infrastructure.
- you might want to periodically update your avatars from Facebook/Twitter in case your users change theirs
- sometimes you may have to retry downloading avatars from Facebook/Twitter
This is the point of all "cloud" services. Some people think "I can run Linux on my own machine, I don't Amazon EC2", and that's fine, but obviously there is a need for services that provide or hide infrastructure. Some companies, like startups for instance, are willing to accept the risks that external dependencies have to attain the benefits of not having to manage the infrastructure.
(The only thing I generally require is that I be able to do something sane for testing locally without internet access. I don't care what it is as long as it enables me to minimally test.)
granted, your API has cleaner and more consistent routes,
But it's not a huge difference as far as I can tell.
As far as uploading avatars goes... I guess that can be a little more difficult but your process doesn't seem a whole lot simpler than just uploading to s3. I would definitely be more interested if you did on-the-fly image manipulation like cropping and centering around faces, maybe you could look into the Dragonfly gem if this is a Ruby app.
Great questions. Let me answer them one by one.
Avatar URLs - we are normalizing the way you access them regardless of the service. Also, we'll be keeping these up to date. For example, when an instagram profile photo changes, it will result in broken images unless you go update it. We're doing the queueing to make sure you don't have to.
Uploading - the platform we've built actually does a great number of things on the upload side. We've limited it down to the resizing to the appropriate sizes. The ability to use custom identifiers for your avatars lets you build the route to them instead of having to store the full path which we think is a help when putting together dynamic apps.
Enhancements - we're working on a number of the items you've mentioned as possible improvements down the line. Dragonfly is a great recommendation for this sort of stuff.
I like the idea behind this, but as others have commented, I'm not sure how this solves the problem. This seems like the same work I've already done, except now it's all hosted with you, and I don't know you well enough to trust you to handle this aspect of my web app.
I think we agree that this is a challenge, especially as you want to add more diversity to the methods you support.
A service like avatars.io does really well before you've invested any effort into solving your own Avatar support. We'll continue to add a number of other features and make the service more functional for even more diverse needs.
As for trusting us now or later, I agree that's the risk that is there for all of us as we evaluate any potential new service. That's not something we expect anyone to do without great consideration and only time delivering a great solution can win that kind of confidence.
Re: gravatar being enough. I agree that it is not the most widely used service and ideally we'd love to see our users having the option to customize their experience per app - as opposed to universally. We started with uploads since our platform manages that handily and many developers who approached us initially were seeking to use Chute specifically for their site's avatars.
Thanks for your thoughts, and I welcome any feedback you have that can help make the service better.
To get the ID, you need the user to "login using Facebook" via OAuth, etc. Using your service, I still need to do that (like I'm already doing now). That's what I mean by it's the same amount of work.
(Correct me if I'm wrong about the Facebook part with your service.)
We definitely recognize that there's a lot of permutations in terms of how to make this as usable as possible and we'll continue to add more support for those other options.
We started here so that it would be possible for apps with existing authentications to easily work with the service but also be able to expand to other services as well as uploads - as they felt appropriate for their own users. It's definitely not a solution for everyone.
Also, we actually provide auth services for Facebook, Flickr, Picasa, Instagram, and more. If you take a look at the mobile components, you'll see that we actually are handling the authentication there to capture the appropriate credentials and map it to the avatar. We'll be brining these to the web side very soon - we already do it with our other product, SlideChute.com.
Thanks for the input... and I definitely think I understand your concerns.
- You'd most likely want to do a sprite with the mousehover/mouseout images
- Both images are 75kb-ish, so you'd probably want to display/hide the bandage (still in a sprite) on mouseover/mouseout
- The eye moves slightly down when you hover it
The mobile components provide cropping and scaling out of the box.
It will live here:
Would be happy to work with you on the PHP version though!
Feel free to email me gregarious AT getchute DOT com
We'll keep that in mind as we improve the service.
Just signed up and it redirected me to getchute.com which threw me a bit...
Avatars.io is an app we built on top of our platform. The app credentials you get are for Chute which also gives you access to all the other features of the API.
If you want to see more of that, you can check out http://picture.io
We made it so that you don't have to stop using Gravatar, but can expand to include other services.
Probably the biggest win, though, is that you can also allow for your users to easily upload their own.
When we started building this service, a lot of people wanted a simple way to handle their own avatars - that is letting users upload their own photos and not send them to Gravatar to do that. That's likely the biggest win for everyone.
Also, a lot of apps are using more than email now so our goal is to offer that as an option. Being able to simple ask someone which avatar they want to use and storing that, as opposed to just an email gives the users more options - and we'll keep track as they change their avatars.
Not sure that clarifies it much, but that's a big part of how we built this particular solution.
Not necessarily. We're using emails as the identifier for matchist.com but based on some initial research (you can easily determine if an email has a Gravatar image associated with it), not everybody has a Gravatar.
They send you an email that says this: