Thinking about it, it doesn’t seem like a misconception, though we may be making different assumptions: if data is uploaded via some app, but the data is on Autonomi, and the user retains a link to the data that can be accessed via a Dweb / Anttp / Other native Autonomi app, then the permanence and censorship resistance is still a benefit that applies to that data despite it being handled initially by a server based app.
I understand a server based app could be made that removes the benefits of permanence and censorship resistance by withholding the data addresses from the user, or formatting the data in a way that makes it unintelligible without the server based app, and in that case of course there’s little / no benefit to the user of the app using Autonomi on the back end.
So, server-based gateways could be done well, or badly with regards to user control of data. These could provide some benefits of Autonomi to users, or not depending on how they’re done, and they can clearly add benefits in terms of ease of use for people getting started.
It’s good to flag up concerns and risks, and to encourage people towards the solutions that make the most of the network, but server based systems may be helpful in getting started until a great user experience for direct Autonomi access exists (e.g. multi-platform Autonomi browser + app store + wallet that requires zero CLI stuff… why doesn’t this exist already… we pretty much had it on test networks 6 years ago: The Safe Browser).