“Why would they allow?” — ‘They’ is Facebook, I assume. (if following on from my observation about FB probably not tolerating this for long) But I think the lock-in effect you are referring to is on the other side, the benefit gained by using HAT. However you sort of imply that it is a mix, of existing lock-in to these parent services plus your value-add.

The danger with this approach is that your service will have numerous crucial third party dependencies that can be disconnected by the parent/s at any time. Much like what happened when a heap of startups built their businesses on Twitter, see: ‘Why you shouldn’t build a business on an API call ‘.

But don’t get me wrong.. there is so much I like about your approach! Its those 3rd party dependencies that always trouble me. Joi Ito has written some interesting pieces recently (here and here), that point to the rise of distributed ML processes, and in your recent article you talked of ‘edge’ processes. (ML on the user’s device), which is smack on my area of obsession.

But taking a data-dump from centralized 3rd party repositories like FB and hosting that data at the edge is not really edge-processing in terms of making use of the proximity between the user and their device. I humbly suggest that processing unique user data that is not derived from 3rd parties (who must be negotiated with and can pull the plug), is the sweet spot. :)