but yeah, in general, what happened to the dream of true Data Portability?
It got muddled into the privacy/security debate and then we all got distracted.
But also privacy - it would be amazing to just be able to connect to any app or service you want, interact and react to stuff that's happening _over there_.
However, do you want any old app or service connecting to _your_ data, siphoning it and selling it on (and, at best, burying their use of your data in a huge terms of service document that no-one reads, at worst, lying about what they do with that information)? So you have to add access controls that are either intrusive and/or complex, or, more likely, just ignored. Then the provider gets sued for leaking data and we're in a situation where no-one dares open up.
I agree with you in principle, but this is only half-true. You're right that Facebook's XMPP was always just a gateway into their proprietary messaging system, but Google did support XMPP federation. What Google did not support was server-to-server TLS, and thus it was “us” who killed Google XMPP federation.
In late 2013 there was an XMPP community manifesto calling for mandatory TLS (even STARTTLS) for XMPP server-to-server communication by a drop-dead date in mid 2014: https://github.com/stpeter/manifesto/blob/master/manifesto.t...
"The schedule we agree to is:
- January 4, 2014: first test day requiring encryption
- February 22, 2014: second test day
- March 22, 2014: third test day
- April 19, 2014: fourth test day
- May 19, 2014: permanent upgrade to encrypted network, coinciding with Open Discussion Day <http://opendiscussionday.org/>"
Well-intentioned for sure, but the one XMPP provider with an actual critical mass of users (Google Talk) remained non-TLS-only, all Google Talk users dropped off the federated XMPP network after May 2014, and so XMPP effectively ceased to matter. I'm sure Google were very happy to let us do this.
* Just let your users pay for API access at a per-call rate
* Charge app developer per user
The problem is that ultimately the LTV of the average user is high, but this is skewed up by the most valuable users who will switch to a different app that will inevitably attempt to hijack your userbase once they control enough of your users.
A classic example is that imgur became a social network of its own once it had enough Reddit users and only Reddit doing their own image/video hosting stemmed that bleeding.
And then there's the fact that if you choose the payment-based approaches, one app will suction the data out and compete with you for it; inevitably some user will lose his data through some app breach and blame you; and the basic app any newbie developer will build will be "yours but ad-free" which is fine for him because you're paying the development and hosting costs of the entire infra.
It's no surprise everyone converges on preventing API access. Even Metafilter does.
I'm curious if anyone has an idea for API access that can nonetheless be a successful company. Everyone's always got some idea with negative margin and negative feedback loops which they bill as "but that won't make you a billionaire" (that's true, because your company will fail) but I wonder if there is some way that could work without ruining social network network-effects etc.
If we do allow companies to block AI agents from accessing our own computers and data, then the users are to blame for falling again into another BigTech trap.
How long do you think it will take for this to meaningfully override Apple's share price?
Mathias Wandel (an ex Blackberry engineer) has a neat video where he explains exactly how that happened and the attitudes are strikingly similar to the ones today.
None of them actually care that they are Apple products or iWhatevers. Most couldn't tell you what the difference is between what they use and windows or android. They just know to go to the apple store to get things that work for them.
The entire Android ecosystem is built around people not paying for anything ever, where the iOS ecosystem, people pay for things. And honestly, it’s a way nicer experience.
Maybe users would rather keep their data safe than have it exfiltrated by a confused AI?
They need APIs for it to be efficient. For whatever reason they didn't choose to use accessibility tooling to automate agents, and we haven't written REST APIs for 20+ years - they're left hoping a newly designed protocol will fix it.
That surprises me too. It's arguably the only way forward that has a chance of surviving for more than a moment, because accessibility actually has a strong cultural and (occasionally) legal backing, so companies can't easily close that off.
LLM companies could easily have made a similar impact by leaning on accessibility tooling. Pushing companies to better support ARIA standards online would have made a huge impact for the better.
Heck, throw a little of that LLM money towards browser vendors to even better support ARIA - personally I'd love to see a proper API for directly accessing the accessibility tree.
If anything, they'd have the reverse impact, unfortunately. The thing is, the companies whose sites/apps/resources would be accessed by LLMs don't want this. That's the entire point of the article we're discussing.
All I'm saying is, accessibility is the only interoperability wedge they can't just close off, without a huge community backlash and in some cases because of compliance reasons.
Expedia makes sense, for example, and it'd be nice if they had more of a reason to improve accessibility on their site rather than building out and maintaining an API service specifically for MCP.
I think the current useful state of consumer LLMs is a temporary subsidy, and the incentives to add ads are too large. And that will change everything, even tools that should work for the user. I recently wrote a blog post on this: https://digitalseams.com/blog/the-ai-lifestyle-subsidy-is-go...
Can you actually even do that today? Not on iOS, I presume, definitely not on Android, at least not without hacking it six ways to Sunday with Tasker and Termux and API access to LLM providers.
(And no, firing Gemini and asking it to kindly maybe search your GMail doesn't count - because GMail is not the only e-mail provider, and GMail app is not the only e-mail client. If I want this to be possible with FastMail as provider and FairEmail as the app, it's hack o'clock again.)
Vendors all across the board really hate to give users useful features, because useful features tend to side-step their monetization efforts. And if history is any lesson, they'll find ways to constrain and shut down general-purpose use of LLMs. "Security" and "privacy" were the main fig leafs used in the past, so watch out for any new "improvements" there.
(emphasis mine)
Been awhile since I’ve seen this kind of content error.
Incidentally, why do the article’s links all use strikethrough rather than underlines? Is this a deliberate style choice, or some Chrome/Firefox/Safari incompatibility? It’s pretty ugly.
One thing I haven't seen written about much is how these APIs turned into massive liabilities for privacy. If a Twitter API allows me to siphon tweets off of Twitter, you can never delete them. If a Facebook API allows (user-approved apps) to view the names of my friends and the pages they like, this data can be used to create targeted political ads for those users[1].
So a company considering creating a public-facing API must deal with the fact that:
1. This API could be helping my competitor
2. This API makes internal changes more difficult (typically there is a strong effort to maintain backwards compatibility).
3. If company XXX uses the API to extract data (that users have given them explicit access to), the ensuring scandal will not be called the "XXXX Data Scandal", but rather the "MYCOMPANY-XXX Data Scandal"[1].
[1] https://en.wikipedia.org/wiki/Facebook%E2%80%93Cambridge_Ana...
It’s like they never even tallied up all plausible advantages and disadvantages in the first place. So how did anyone determine it was an overall net positive?
I mean, why not just kill your competitors? Then your product, however bad, would be the only one. Clearly a net negative, but a competitive advantage.
What has changed is that we've recently lowered the bar for how much of a net positive we plan on shooting for. Top dog on the trash heap is, I guess, now an enviable position.
Someone has to actually do that analysis in the first place. It doesn’t just automatically become true.
If you're referring to 'net positive [for facebook]' rather than [for users] or [for society], then the point is conceded that facebook can make more profits abusing their users versus being more considerate of them.
If so… then we should discuss those instead.
Going against that grain might be advantageous in certain cases but ultimately you have to live in the world that you create so its usually not a great long term strategy.
But since the opinions of people aren’t anywhere near the same value… comparing it your way is nonsensical.
How is it relevant to what? We were discussing "net positives" as in net positives for society, but it sounds like you're referring to net positives for Facebook alone, at the expense of all others.
> The user isn’t the one making the decision to implement it or not
This is true. Here is another difference between them: Facebook isn't the one being harmed by cutting off approved API access to 3rd parties.
It seems like we both agree that Facebook and users are different groups, in different circumstances, with different things to gain and lose from different decisions made here.
With that shared foundation of understanding: Why should we care about what Facebook wants, more than we care what users want? Why should we care about Facebook wanting to stifle startups and other competitors, more than we care what users want? Why should we care about Facebook's profit margin, more than we care what users want?
Of course Facebook is free to do what is good for them and bad for users, and they indeed chose (and continue to choose) to do so. Here we see the predictable result: Users criticizing them for it.
We are all smart and can comprehend Facebook's purely-economic "fuck the users, we wanna make money" decision criteria just fine, but we don't have to respect it.
Bluesky has decided that it’s not a bug and is not going to be fixed: you can delete a post, but someone could have saved it, and worse, it’s digitally signed.
Edit: editing posts is nice to have.
How would you design Bluesky to prevent analog holes?
We could contrast Bluesky with the Fediverse: a maze of independent websites with uneven distribution and no systematic search or archiving. So, if you don't have much of a following and you delete a post, it's possible that nobody saved it. Some people prefer it that way.
But it really does make sense. Nothing you publicly tweet can ever be private, nor is there any real way you can reliably take it back. Because as soon as the tweet's been transferred to someone else's device, they now have every bit as much control over that content as they do over any other content that makes it onto their device.
I'm a pretty pro-privacy person, to the point where I generally avoid social media sites. But this was also my policy back when I administered an oldschool Web forum: once it's posted, it's out of your control. Period. That's really the only policy for a public forum that makes any sense at all. If that's scary to you then maybe the things you're posting should be, y'know, kept private instead of being broadcast to the entire world.
tl;dr: group chats are actually pretty cool.
It's called an "analog hole". It's very difficult to prevent analog holes. By difficult I mean: impossible.
The internet was collaborative when it was very small. You still had islands like AOL and Compuserve and such.
Then as it got bigger the big islands like AOL broke, and the views started going to larger and larger websites (think things like news sites). These sites had to work with vendors (Microsoft/Apache) to be able to support the load without crashing. While this is occurring hardware got a lot faster and databases more performant (along with things like K/V caching).
This lead to the last 'social media' wave where just a few large companies could host enough servers to serve everyone on the internet (within reason). These companies sucked a lot of wind out of the smaller companies that were successful. You could wake up one day and find out Google had implemented your entire business model and is giving it away for 'free'.
But free was never free. Those big companies need your eyeballs. They need your attention. And they will do anything regardless of the ethics to keep it (what are small fines between friends). There was not much more room to expand in to, you're only expanding into other companies. You take over/replace the ones that give their data away and 'compete/fight with' the ones that don't.
Big tech companies are full of extremly competent people who for the most part cant get shit done. A hand full of cooperating people armed with curiosity and the desire to make something useful can do things tens to thousands of times better.
What are these websites they make that need hundreds of requests to show a bit of text? I cant view source without repeatedly screaming from laughter.
Maybe the answer to the riddle is to force the pattern and make usefulness as well as asking for help requirements for participation.
Not only is this already possible (I can open up twitter and press "control-P"; I can open up Facebook and see names)*, but it's already being done by those companies. If you thought Cambridge Analytica was bad, imagine what Facebook is doing with even more user data.
That indicates that the issue isn't protecting users from that sort of abuse (since they are the abusers in that sense), but to prevent business competitors from doing the same and reduce user choice (eg users who don't want to have to have their eyes bleed to read their content on these sites).
If the goal is to keep information secret from X, disclosing it to X via 1 programmatic means while restricting it via another, fails to achieve that goal.
> So a company considering creating a public-facing API must deal with the fact that:
1. It could be helping users, which is more important to users than Facebook winning some corpo-war-on-data-access. Is it more important to Facebook et al, though? Clearly not, and therein lies the ethical failing of Facebook et al.
* - "but wait" I hear some saying, "you're just a human, you can't do that at scale!" Well: the data got on my computer screen programmatically, and it's trivial to reuse those methods to get the data you want. It's just an extra step or two that frustrates legitimate users.
Is that really a privacy concern? Tweets are public. As soon as you post them, others can just save the page. No need for an API.
Of course not. All this gatekeeping is how every Tom, Dick and Harriette make their money and wrestle for dominance. Believing that any specific tech would fundamentally change that is hopelessly naive. The honeymoon phases that make it look like it could be different this time around are merely there to lock in lots of users.
It's in the nature of capitalism and that's not a technological issue.
Regulatory support of interoperability and competition:
1. EU mandated interoperability on mobile and messages.
2. US won antitrust legal case against Google. Remedy TBD.
3. Epic lawsuit enabled non-Apple payments and lower fees for content sale.
4. US has mandated that banks open up payment history data to 3rd parties.
5. US halted Facebook/Meta Libra/Diem digital currency.
6. China halted Ant Group digital currency.Lots of other comments argue for regulation mandating open APIs. I disagree, instead we should remove and prevent regulations that block scraping. We should also create alternative monetization paths for companies who charge for access or use ads, since they’ll lose those paths, and they’re already suffering from piracy and illegal scraping.
Over the years most of the problems I had with sites getting overloaded were from valid 'scrapers' like Google. Quite often providers were adding more memory/cpu just to ensure Google could index the site.
While hosting costs are cheaper than ever, being on the internet can still get very expensive very fast.
It already costs a small amount of electricity for clients to send requests, so maybe paying for the server to handle them wouldn’t be a big difference, but I don’t know much about networking.
Although in practice, similar things have been tried and those haven’t worked out, e.g. Coil. It would require adoption by most browsers or ISPs, otherwise participating sites would be mostly ignored (most clients don’t pay the fee so they don’t get access, they don’t cares because it’s probably a small site and/or there are alternatives).
[1] Stop using REST for state synchronization (2024) - comment:
https://news.ycombinator.com/item?id=44000810
[2] A Synchronous Web of State:
bigmattystyles•7mo ago
_jholland•7mo ago
As a business, they uniquely leverage inefficient and clunky design to drive profit. Simply because they haven’t documented their systems sufficiently, it is “industry standard practice” to go straight to a £100/hr+ consultant to build what should be straightforward integrations and perform basic IT Admin procedures.
Through many painful late nights I have waded through their meticulously constructed labyrinth of undocumented parameters and gotchas built on foot-guns to eventually get to both build and configure an SAP instance from scratch and expose a complete API in Python.
It is for me a David and Goliath moment, carrying more value than the consultancy fees and software licences I've spared my company.
piva00•7mo ago
robertlagrant•7mo ago
dbreunig•7mo ago
A very successful company with some of the happiest customers I’ve ever seen, whose entire product was a SAP hack that allowed people to enter their data using Excel. As someone unfamiliar with SAP, absolutely blew my mind.
jgraettinger1•7mo ago
Open to a conversation about your work here? Reach me at johnny at estuary dot dev.