Show HN: Avatars.io - simple API for integrating avatars into your app or site | Hacker News Reader

Show HN: Avatars.io - simple API for integrating avatars into your app or site

avatars.io

181 pointsgregarious39 comments

Shouldn't this be a library that we can run on our own servers? I simply don't understand the recent influx of things that should be libraries.

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.

If you provide something as a service instead of an open source library, you can theoretically monetize it in the future (in a more direct fashion than the standard FOSS support contact) which makes it possible to use to generate VC interest, which is harder to do with a pure open source option. I'm fairly sure that's why it has become common to do this, though in pure practical terms I agree with you that this system isn't ideal.

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.

I still believe building open source libraries, then building a paid service using those libraries is the best way to have your cake and eat it too. A fantastic example of this is Shopify and ActiveMerchant.

Shopify is not open source. ActiveMerchant benefits Shopify by being open source because it allows third parties to write payment modules which can be folded into Shopify. Since Shopify's main competitors are written on php, asp and other non-ruby languages this amounts to a competitive advantage.

It's not about proving library-like functionality. It's about providing infrastructure that their customers don't have to build and maintain.

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.

Good point. And it's not just availability, it's privacy and security too. When a service like that becomes popular, it can easily be used by tracking people online. It can also be a lucrative target for attacks, since the impact will affect many websites at once.

I couldn't disagree more. As an overworked startup founder who regularly uses services like this, SAAS has been a godsend. I hate configuring libraries, especially stuff like this that needs write access to a filesystem, database, etc. Just host it for me and I'm a happy camper.

(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.)

Yes, it should. http://news.ycombinator.com/item?id=4107459

what a great looking site (this and Chute too). but... maybe you could explain the value a little better to me? the avatar URLs for facebook and twitter are:

http://api.twitter.com/1/users/profile_image/:username.png?s...

http://graph.facebook.com/:username/picture?type=:type

granted, your API has cleaner and more consistent routes,

http://avatars.io/twitter/:username

http://avatars.io/facebook/:username

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.

Hi,

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.

This hits home for me, as I just recently built a super simple avatar system for our MVP of matchist.com. I wish there was a simple "plug it in" library that handled my user avatar functionality, letting users choose between Gravatar, Facebook, Twitter, etc., handling the OAuth, etc.

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.

Tim,

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.

An example of how I still have to do the work is Facebook. In your example, you need the Facebook ID to get the avatar. You can do that already using a simple URL from Facebook, just plugging in the ID in the appropriate spot (which is how I'm doing it now).

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.)

Yes, you are right that you need to get a user to identify themselves on a service. Auth is definitely the most common methods, but for many services you can simply as for a username (ex. twitter or instagram).

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 should add support for more providers, like Unicornify:

http://unicornify.appspot.com/

I'll say something not related to the service but to the .title image.

- 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 app makes avatar integration so seamless. Wonderful job guys. Love it. I've always been using Gravatar which is great too. But having access to all the avatars from various social networks is a huge plus. +10

Thanks! We think Gravatar is a great service, but as more and more apps use social networks and more, having more options is great.

Great work. Very useful service. Now only if there was an easy(ier) way to crop, enhance, tag, etc across platforms.

We definitely agree! And we hope to solve that some more if we can.

The mobile components provide cropping and scaling out of the box.

Love the idea, it's like an updated Gravatar... Gravatar has been very stale lately.

Agreed. Gravatar is pretty much the worst.

Are you guys working on a PHP library, or will I need to roll my own?

Checked with one of our guys who does PHP. He's gonna give it a try in the next day or so.

It will live here: https://github.com/chute/avatars-io-php

We haven't started on a PHP library as of yet. Most of our team is on the Ruby/Node side of things.

Would be happy to work with you on the PHP version though!

Feel free to email me gregarious AT getchute DOT com

Why would I want to move from using Gravatar... to using Gravatar through Avatars.io. If I have to manually support all of these URLs, there's not a ton of benefit from just using the site specific URLs as it is, and I now have a dependency (And thus risk) on avatars.io. Maybe I'm missing something that this enables? (I mean, the URLs are certainly pretty, clean and consistent!)

Agreed. What WOULD be helpful is a service that would look for an avatar on various services, and serve the first one it finds. So if a user doesn't have a gravatar, it looks up their facebook based on their email - and uses that avatar, then twitter, etc.

That's a great idea. As long as the info is public then that would totally be something worth doing.

We'll keep that in mind as we improve the service.

If you did this, I am moving my apps' avatars to you. This would be a very cool feature! :)

Just signed up and it redirected me to getchute.com which threw me a bit...

Sorry about that confusion.

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

This would be great - and if it finds a few, give the user the option to select one of the ones it finds on the various social services.

Hi,

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.

Greg

I guess I am still confused. I don't mean to belittle what you're doing, I just don't understand the value it adds for me. I suppose maybe your gems or prebuilt packages make it more transparent, but at the end of the day, my code still has to know whether to load avatars.io/{facebook,twitter,gravatar} etc, thus there isn't really a significant layer of abstraction? (Like I said, really just trying to wrap my head around it here)

I think if your app is based solely on email addresses now, Gravatar will serve you well.

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.

"I think if your app is based solely on email addresses now, Gravatar will serve you well."

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.

Most sites' users aren't technically sophisticated enough to know how to or want to use Gravatar.

This user is perfectly sophisticated enough. However I refuse to use Gravatar since it requires having a Wordpress account whose terms and conditions I will not agree to.

I don't recall having a wordpress account and I've been using gravatar for about three years now.

Well you hit this page: https://en.gravatar.com/site/signup/

They send you an email that says this:

By signing up for a Gravatar account I acknowledge that I have read and agree to the Terms of Use and Privacy Policy located at the following link:

https://en.gravatar.com/site/terms-of-service

Reply on news.ycombinator.com