Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Personal API

x.naveen.com

Post reply on HN
Print view View original

11–20 of 119 posts

Re: A Personal API

#12

Post by neeharc »

As you suggested, I think this is a great way to expose your data to apps that may be built on top of you.

Also, a stalker would love this :P

Re: A Personal API

#13

Post by abraininavat »

I was about to dismiss this but have thought about it a bit more, and there's something interesting here.

There are already APIs built on top of you. There are the ones you know about, like Facebook and Twitter. There are the ones we know exist but have no direct access to, such as Amazon's backend or your police record. And there are the ones we may never know about, such as the NSA bot scanning this post right now and correlating it to my recent overseas cell phone calls.

I'm intrigued by the concept of aggregating this data. Imagine if the wealth of data collected about you all went to one place, and, most importantly, was controlled by you. Imagine if Company X had to pay you to know about your Amazon spending habits instead of paying Amazon. Imagine if scientists could perform long-term health studies in an instant because the data they need is already collected and just needs to be crunched.

I think the concept that's missing from your blog post is the idea of discoverability.

Re: A Personal API

#14

Post by ianstormtaylor »

jpreiland wrote: post #5
ngoel36 wrote: post #2

This is so cool. Somebody should turn this into a platform - a mobile app that at least helps you record the stats you want, paired with an API platform that lets you grant and request permission for other "personal APIs". Then other API calls can be built on top of individual people - College students in the US, citizens of India, etc. The possibilities are pretty endless.

The Biggest Loser - play along at home! Be the "biggest loser" in [your region] to [acquire swag], etc. Sorry, maybe I'm being a bit facetious. There's definitely a lot of cool stuff that could be done with a personal API though. But how do you get people on-board? You have to have equipment to track/update stats right? Are people willing to buy into this potential network?

If Fitbit and all of those types of companies start having Export APIs a service could have wrapper around all of them. Then anyone with one of those devices could join easily. Could be the way to start, since you definitely don't want to be building the hardware and API altogether for an MVP.

Re: A Personal API

#16

Post by danielsiders »

This is one of the use cases we had in mind when in developing Tent (https://tent.io).

Tent is an evented data store for arbitrary JSON blobs which can be typed b the developer. It has the added benefit of operating as a decentralized system that lets you push and receive posts with other users via webhooks.

Tent can be used to create applications and systems from the quantified self to microblogging to cloud-backed file sync to collaborative real-time document editing.

Re: A Personal API

#17

Post by tannerc »

cocoapriest wrote: post #11

As an engineer, I can understand the excitement. But I wonder why and who should use that data? I can't see any great use cases.

Doctors, for checking activity/sleep/etc.

Friends/relationships, for checking general activity and check-ins.

Potential businesses, for seeing interests and the like. Or, if currently employed, the employer could randomly check to see how the employee has been sleeping (are they going to be tired/cranky today?) or to see how often they check-in at the office.

Aggregated with more data from people doing similar things and you can start to get a look at populations (what if everyone in SF was logging this data? What if a good chunk of those in the US were?).

Re: A Personal API

#19

Post by reeses »

nkozyra wrote: post #7

I've thought about this many times before. But, this is the easy part. Storing, doing simple metrics, making assumptions and returning the data is not a problem. Standardizing input methods is.

Federating data is a fairly 'solved' issue. Ironically (or not) enterprise IT is ahead of the average organism in this space.

Faced with legacy systems communicating (or not communicating) via various channels, Middleware, ESBs, SOA, message queues, content-based routers, business process management, event processing, and data virtualization have all been created so that a development group can factor these systems into canonical representations of business events.

At that point, the input method ranges from the simple (existing web app to API) to complex (treating a batch-oriented system in a semi-synchronous manner or screen-scraping an ancient smart terminal as a queriable data source).

At that point, the real challenge isn't the input method but master data management and security/authority/privilege.

Post reply on HN