People are going to have to learn the hard way that UI is designed on the backend first, unless you don't care about latency or bandwidth or IF you download all the data first and your AI has a local indexer.
Please talk to people who worked on any functional application and see how much back and forth goes into optimizing the API to fit the UI as much as possible without over fitting so as to keep the API as useful as possible to as many UI needs as possible.
AI agents can make your local data maximally useful, but it can't magically make usuable UIs to remote data that isn't already indexed with the UI in mind.
ABH3PO
You don't need it tbh, modern day interfaces could just be an AI prompt that can get you to wherever you need.
View quoted note →
Replies (14)
Bro do you even know me? Lol.
Not really and I don't have to to comment about a general claim. But since you are taking it personally, I checked what you worked on and proud of, and I am not impressed.
Yup.
That and the fact that :90percent: of what I want to read and write has the exact same format, filter, etc.. every day of the week.
I don't want to custom prompt things that aren't custom all the time. Let alone the unhabitual custom uis that come with it.
Since we’re talking about nostr, do you mean backend as in a relay or the actual client backbone?
The general idea that suddenly the world won't need well crafted UIs and APIs is retarded. People had 3rd printers and before that power tools, yet they didn't suddenly started creating furniture on demand on a whim. This disregard for craft is annoying. Also isn't Nostr a big ass experiment in how useless and worthless quickly developed and thoughtless apps are?
No I mean what people call AppView or Backend For Frontend, or the Indexer in the case of Pubky... Servers that aggregate data, map it to other forms, and index it based on many aspects and prepare the database indexes and API endpoints to return very specific data for very specific client needs.
Do you really enjoy your Nostr clients counting reactions in real time as they stream? Every time you open the note? Do you enjoy that you can't get consistent and fast counts and statistics? Do you enjoy that you can't get reliable notifications count and reliable cross device count down of notifications count as you open more and more of them?
All of these stuff require a server that isn't necessarily dealing in the raw data, but metadata. And metadata that you can't design at the protocol level, every app will need different stuff.
It is a shame that Bluesky knew all of this from the get go, and even Mastodon does a good job there, but here people are pretending the laws of the universe don't apply, because we are cool.
🎯
My 3D printer (when I was doing physical product design and engineering) was used for:
- custom mold making, to then make XXX time the same component with it
- pieces tailored to very "individual" individuals (children with cerebral palsy)
You literally commented on my claim as if you knew that I'm not already aware of the challenges of a superior UI, which is why I asked. What is even funnier is how insecure you felt that you needed judge my work 🤣 thanks, though, we keep improving everyday.
Agreed, though you could just as well save prompts
He will soon sell his protocol which is superior to nostr in every way. He's a grifter, you can move on.
I get where you’re coming from, but I wouldn’t bolt the primal caching server into the protocol.
Ideally nostr would be specced as p2p just like Bitcoin and if you feel like providing a server to those wimpy little phones you are free to do so.
No one said bolt to protocol. It is called AppView or Backend For Frontend specifically because it is designed and maintained by whoever is designing the client. But it does mean that you can't just switch to any relay in these clients, they only work with servers that provide their specific API.
