[bo1024]

The common denominator: the data needs to be owned by you, or at least made accessible. Companies love to create walled gardens where they own the content and control how you access it, making this kind of personalized interface impossible. Hopefully we can push back more now.

[bs7280]

The ability to quickly make an API connection + custom UX means that companies with a sub par website / app but a good data API are more valuable to me than the world class fancy website with a locked down API.

At work I have a great brain dump + TODO list tracker via custom API + MCP into confluence, using confluence pages as the app state. The website is so bloated it takes like 20 seconds to go from "idea" to getting it written down. Im now able to avoid all of that and make ~ MY ~ perfect UX while still being a good corporate employee.

[dharmatech]

I agree that owning the data is ideal:

https://news.ycombinator.com/item?id=48129841

[tptacek]

I mean, hold up, if that thought lights you up I'm happy, but I don't actually think that's the common denominator. I used Things.app to track projects for a long time and ultimately fell out of love with it. Things.app didn't own my data; it's a pure UI app.

But now it occurs to me: I know precisely how I work, I know what patterns are valuable to me, I know when and how I need to remind myself of things. I don't know why I haven't already started building my Things.app replacement. But I'd guess I have it to a place where I'm happy by this time Saturday.

Honestly, it's harder for me to think of daily-driver apps where this wouldn't be the case. I guess vector graphics editing? I'm not going to vibe up a vector editor. But I'll bet all the money in my pocket that 5 years from now, the real value in vector graphics tools will be their API/SDK, not the packaged application experience.

[bo1024]

I'm not following your reasoning about the common denominator, not sure we're on the same wavelength about what I meant. I'm claiming that in order for an application to be "reclaimable", you have to be able to access and manipulate the data under the app. Some applications currently work that way now, lots of them don't.

For example, we can "reclaim" non-DRM ebook readers, audiobooks, and music players that play local files or use an open API. But a company-specific walled garden streaming DRM'd ecosystem will be almost impossible to build around.

[tptacek]

You're talking about entire systems. That's something to be optimistic about too. But it's actually not the thing the comment you responded to was about. I'm not saying I'm excited to get out of the Apple Music ecosystem (I like Apple Music, the service, quite a lot). I'm excited to get out of Music.app, and into my own custom Apple Music player; one where playlists and play history are simple, sanely-schemaed sqlite databases.

I gotta be careful, I'm going to talk myself into staying up late tonight building that.

[yoz-y]

I was too, thinking about making my own apps for a lot of stuff, but for now I’m sticking to web apps because distribution on mobile is still crap.

[tptacek]

Why are you distributing at all?

[iLemming]

> didn't own my data

Ownership can have different forms. Slack.app that doesn't let me easily extract code snippets from a thread - owns me. Jira that forces me to use their imbecilic, quirky wysiwyg owns me. Note taking app that keeps the data in their db and not my files - ain't my friend. The friction is the ownership. When extraction requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay in Slack/Jira/Dropbox/Evernote/Notion/etc. longer, search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.

Plain text, local files, standard formats - they don't fight you on extraction because there's nothing to protect. That's why investing in FOSS tools is almost always paying for your own liberation rather than your own imprisonment. Even when there isn't feature parity, even when the FOSS tool doesn't have a "polished UI" and it's "maintained by a teenager in Nebraska" - still a better choice.

[satvikpendem]

Not necessarily, you can ask the LLM to reverse engineer the protocol.