The beauty of AT Protocol is that all of your data from different apps is available on your PDS, your own folder on the internet containing your stuff as JSON. This means that you can switch which app you use to view that data, without losing anything. It also makes it very easy to make connections between data stored using different lexicons, or just display activity in one place. Sifa does a nice job of this on your profile page. For web developers, and people who understand webhosting, the concept is reasonably easy to understand. I know that any atproto app I join is going to store data in my PDS, any other people will be able to see it.
However, for atproto to really succeed it needs to go mainstream. The general public are less likely to understand what it means to have this folder of information on the internet. They may not realise that using a collection of different apps means that they are creating an easily viewed paper trail of their activity on the web. They may not expect that another app can display their data. So as I explore the Atmosphere, and experiment with making my own app, I’m wondering if anyone is thinking about how we should message this to users.
I’m not thinking here about private data, and I know that there’s a separate conversation happening about that. I’m talking about data that is intended to be public, and making sure that users understand. This will be a completely new idea to many people, and the “it’s like your webhosting” explanation isn’t going to resonate with someone who has only ever published to the web in a walled garden. With obvious social apps like Bluesky, users are likely to understand that their posts are public. That expectation may be less for other types of apps where users might reasonably expect their data to be private unless they share it, and would be very surprised to see it appear on some other app without their explicit permission.
It would be good to have some common guidelines for app developers as to what to tell users, and to develop explanations for a non-technical audience. Is anyone working on that? If so, I’d love to get involved.
This is the seventh and final post in my July series on API sprawl. I have covered what it is, its organizational and technical roots, the shadow, rogue, and zombie APIs that hide in the gaps, why it costs you, and how governance prevents it from forming. Governance sets the rules and the gates. Management is the operational muscle–the day-to-day machinery that finds the sprawl you already have, catalogs it as a single source of truth, and puts a consistent front door in front of all of it. A good management strategy promotes “golden paths,” the well-defined and supported approaches to common API structures, and keeps the environment secure and efficient. It rests on three pillars: discovery, inventory, and gateways.
API discovery is where you have to start, because you cannot manage what you have not found. Discovery is the process of identifying and cataloging all the APIs your organization uses, and knowing exactly what is available is the front line against redundancy–it is how you stop engineers from wasting time rebuilding a function that already exists. But discovery is genuinely hard, and I want to be honest about that rather than pretend a single scan solves it. The tricky part is finding the shadow, rogue, and zombie APIs precisely because they are undocumented and off the books. In practice discovery is a combination of methods: traffic analysis to see what is actually being called, manual code review, examining whatever documentation already exists, and scanning code repositories for API endpoints. Many cloud providers offer discovery tools inside their own platforms, and there are dedicated third-party scanners and discovery apps, some using automation and AI-powered simulation to probe for undocumented APIs. No single method finds everything, which is exactly why discovery is a combination and why it has to be continuous rather than a one-time project. The estate keeps moving; discovery has to keep moving with it.
API inventory is where discovery’s findings become durable. An inventory, or catalog, is the centralized repository that holds information about your APIs and serves as the single source of truth across their whole lifecycle. This is the registry I have referenced in nearly every post of this series, and it is worth spelling out what a real inventory entry contains, because the depth of the record is what makes it useful. A good entry captures: the API’s name, identifier, version number, and owner; a description of what it does; the base URL and endpoint locations; the protocol and architectural style; the authentication method; a link to the spec file; lifecycle and status information; known consumers and dependencies, along with who is even allowed to consume it–internal, partner, or public; governance and compliance tags such as GDPR or HIPAA; and operational details like rate limits and uptime expectations. Inventories were historically kept in spreadsheets, which–let us be honest–left enormous room for improvement. Modern catalogs live in API portals that actively facilitate discovery, so the inventory is not a document that goes stale the day it is written but a living surface people actually use to find and consume APIs.
I will plant my flag here, because this is my life’s work: that inventory should be machine-readable. The entire reason I have spent sixteen years on APIs.json and championing OpenAPI is that a catalog full of the fields I just listed is only as valuable as it is queryable, diffable, and automatable. A spreadsheet cannot fail a CI/CD gate. A machine-readable index can. When your inventory is structured data rather than prose, every other practice in this series–the registration gate, the traffic audit, the ownership check, the deprecation policy–can be automated against it. That is the difference between an inventory you have and an inventory that works.
API gateways are the third pillar, the consistent front door. A gateway is specialized middleware that acts as a single entry point for your backend APIs, and beyond routing traffic it is where you enforce consistent authentication, security, and management across many APIs at once. On routing, the gateway receives an incoming call, processes it, routes it to the appropriate backend service or services, aggregates the results, and returns one clean response to the client–which is enormously useful in a microservices architecture where a single request might fan out across many APIs but the client only wants one answer. On authentication, the gateway verifies the identity of every consumer trying to reach an API, using API keys, OAuth tokens, or other measures, so that security is applied uniformly rather than reinvented per service. And on management, the gateway centralizes tasks like versioning and load management while giving you a consolidated view of traffic and metrics, which is how you actually monitor usage and performance across the estate instead of guessing.
I will add the caveat that matters most: a gateway is a powerful chokepoint, but it only governs the traffic that flows through it. The shadow and rogue APIs from earlier in this series are dangerous precisely because they route around the front door. So the gateway is necessary but not sufficient–it enforces your standards on everything that goes through it, and discovery is what finds everything that does not. Put those two together and you have both a front door and a way to catch anyone climbing through the window.
That is the whole picture, and it is worth stepping back to see it as one system. Governance sets the standards, assigns ownership, mandates API-first design, and installs the automated gates. Management operationalizes all of it: discovery finds what exists, inventory records it as a machine-readable single source of truth, and the gateway enforces consistency on everything flowing through it. None of these pieces is exotic and none is new. The entire remedy for API sprawl comes down to a single, almost embarrassingly simple discipline–decide to actually know your own APIs, write that knowledge down in a form machines can use, and wire it into the pipeline so it stays true. Sprawl is what happens in the absence of that decision. Everything in this series has just been the long-form argument for finally making it.
Wenxin Fang of Redmond, Wash., holds the ZeroPivot Protractor that he designed and is selling through a new Kickstarter campaign. (Photo courtesy of Wenxin Fang)
Wenxin Fang was 14 years old when he realized he was fed up with fighting with a flimsy piece of plastic in math class.
As an eighth grader at Evergreen Middle School in Redmond, Wash., Fang kept bumping into the limits of standard classroom protractors — the cheap, clear tools generations of students have used to measure and plot angles. Frustrated by how often he had to realign the plastic arc just to mark a single line, he started sketching an alternative in his notebook.
Two and a half years and seven design iterations later, the incoming Tesla STEM High School junior is launching the ZeroPivot Protractor, a sleek, precision-machined aluminum hardware project aiming to drag an overlooked classroom staple into the modern era.
“I shouldn’t be fighting with a piece of plastic to draw an angle,” said Fang, now 17, during a call from China this week where he was meeting with suppliers ahead of production of his tool.
Fang launched a Kickstarter campaign on July 26 to fund the initial production run of the ZeroPivot. The campaign hit its initial target within 48 hours and has raised more than $2,200 from dozens of early backers.
Priced at $19, the ZeroPivot is positioned as a durable, high-precision upgrade over standard $3 plastic models. The funding will cover tooling costs and help manufacture the custom-machined aluminum components through HKAA Industrial, a supplier Fang vetted and partnered with during a visit to Shenzhen.
To make the tool work, Fang abandoned the traditional semi-circular design in favor of a guide-rail system made from anodized aluminum — a material choice he insisted on despite the higher production costs.
Unlike a standard protractor, which requires users to mark an angle’s vertex and rays in separate steps, the ZeroPivot features an adjustable sliding mechanism that allows users to plot and draw precise angles in a single fluid sweep.
“I went down this path of product design, trying to come up with something that’s small, that’s almost simplistic … that is able to improve the lives of people in tiny ways through good design,” Fang said.
Fang didn’t just keep his ideas trapped in his notebook. After coming up with the initial sketches, he brought them to his middle school engineering teacher, who encouraged him to build an actual prototype rather than treat it as a fleeting thought.
The ZeroPivot Protractor. (Photo courtesy of Wenxin Fang)
When he transitioned to high school, that mentorship expanded into a full support structure. A trio of teachers helped him turn his hobby into a legitimate consumer hardware launch:
Steven Bonomo, an engineering and product design teacher with a background working on Microsoft’s Surface Laptop line, guided Fang through user testing, ergonomics, and physical product design.
Andrew Christensen, who has a background in law, walked him through the corporate, operational, and legal logistics of starting his company, Bonae Artis LLC.
Karen Schaeffer, a graphic design teacher, helped him refine the brand identity and the final visual aesthetics of the product and its packaging.
That guidance proved essential as Fang spent the past year user-testing prototypes in class on himself and his classmates, refining the tool’s feel and mechanics in real classroom conditions.
Balancing the demands of a hardware startup with high school homework requires an intense level of discipline — and plenty of late nights.
“It’s a ton of work, that’s just the reality of it,” Fang said. “If you’re pushing a project by yourself, there’s not an external deadline there. What you have to do is set deadlines for yourself and say, ‘Hey, this iteration needs to get out by Sunday.’ I do late nights pretty often just to get something in on time.”
Diary of a protractor reinvention, from left: Wenxin Fang’s notebook sketches, touring a manufacturing facility in China, and various prototypes throughout the process. (Photos courtesy of Wenxin Fang)
For Fang, the ZeroPivot is just the starting point for a career he has been prepping for since childhood. His earliest memory of designing anything was at age 9 during Chinese Lunar New Year, when he used Lego bricks and superglue to create a custom ceiling hook to help his grandparents hang decorative lanterns.
Now aiming for a college degree and future career in product design and mechanical engineering, Fang sees the protractor project as proof of what simple, physical problem-solving can accomplish.
“That was kind of when I first realized, hey, I could make something so simple, and I could have somebody else use it, and it could be really nice for them,” Fang said.
With the Kickstarter campaign already funded, Fang is focused on executing the manufacturing run smoothly in China and delivering the finished ZeroPivot protractors to backers by his estimated February fulfillment target.
While he isn’t yet ready to reinvent the ruler or big pink eraser, Fang does envision creating more consumer hardware tools down the road. But his immediate motivation remains remarkably simple.
“I’m definitely focused on getting this through to fulfillment and getting this in people’s hands,” Fang said. “I think that is the most satisfying part of doing products — getting to see people using them.”
When the phrase "OpenAI hacked Hugging Face" has more or less entered mainstream culture, you know we have an AI problem. This week, we learned more about exactly how OpenAI's agent broke out of a sandbox and autonomously traversed the web, including a bunch of other supposedly secure web services, all in the name of cheating on a benchmark tests.
The fact that this hack happened is a problem. So is the fact that it took a while for anyone to notice. And the fact that it seems no one is willing or able to do much to stop it. (And lest you think it's just an OpenAI problem, since we recorded this episode Anthropic acknowledged its models ha …
Your semantic layer is a risk mitigation strategy. Not risk in the abstract, compliance-framework sense, but the practical, operational risk that quietly drains organizations every day..
Log in
