I’m trying to wrap my head around the Autonomi developer experience. Can you assist?
What I’m trying to figure out is how we can run a web app (i.e. server-side code & logic) on Autonomi, a la ASP.NET on IIS, etc. I do understand the basic principle at work here, yes—secure and private file handling—but as we know there’s a lot more to a business application than just file storage & retrieval.
For some reason I’m not able to get my head past the notion that an Autonomi-based website can only be comprised of static files, with no backend logic allowed.
e.g. If this do that, otherwise get a value from the array
Actually, this segues into a related topic that’s been on my mind for some time now.
What about data? How do we build a multi-user application that warehouses its data in a single location?
We need that Single Source of Truth™ that a central relational database provides. How do we go about using something like Entity Framework? Optimistic concurrency? Autoincrementing primary keys? Cascading deletes?
It seems a thorny problem.
Are these types of apps going to be possible at all with Autonomi?
This is what dweb enables. Not ASP.NET and other stacks but both the examples you described.
dweb provides a local REST API that lets a web app load from Autonomi and work exactly like a dynamic app using any REST API. The restriction is that the business logic is all in the app and not as middleware on the server.
The Fileman example shows how to do this using Svelte with dweb, but as it involves a REST API, any web framework can be used (though none is required).
Oh well - maybe worth mentioning that there really is not that many use cases where you need server side logic if you design the process correctly
As explained over there users of the autonomi network can verify who they are, they can sign data and data can be encrypted to only be read by them… So the ‘issue’ of not having server side computing is mainly a app design task in most use cases…
I know you keep saying that, but it’s pretty generic.
What does a ‘properly designed’ Autonomi web app actually look like? Are you saying all page logic must be client-side JavaScript? That could never work, as there’s vital info we must conceal from the visitor.
Think of a simple shopping cart, for example. If everything were client-side, it’d be trivial for a skilled attacker to spelunk the code and manipulate the price at checkout. Shucks, he might even build a browser add-in and distribute it!
Could you explain what you mean by ‘properly designed?’ Thanks!
Okay - so he sends you an order using different prices than you publish in your Web shop. So what?.. You simply decline the order /send him back an offer with corrected prices..? What’s the issue..?
I’ve just now had a better look at the repo. It seems that dweb is basically a console app that, when run, listens on a port at localhost. Any necessary ‘server-side’ logic exists in the running package.
Fair 'nuff. This is pretty easy to do with Kestrel serving ASP.NET pages as well. I’ve published an example here.
But it’s not optimal, at least not yet. Essentially, unless we mess with the user’s hosts file, which requires admin permissions, we don’t get human-readable domains. We have to use a unique port for every site. These are pretty cryptic requirements to force on a casual website visitor, if I may say so.
Further, I’m not seeing a way to avoid port collisions with another publisher.
Is the ability to run true server-side logic on the roadmap?
Any logic placed in the frontend is under the control of the user. Even with signing, he can:
Bypass validations
Submit altered payloads
Spoof behavior
Example: Suppose our app checks if a user has “enough balance” to make a purchase. If that check exists only in JavaScript, he can bypass it and submit a transaction anyway—relying on us to manually validate payment only after-the-fact.
You remember the days where you got catalogues with advertised articles, everything had a number and a price in that catalogue and on the last side there was a table you could fill out with the list of articles you wanted to order.
You put in the order number, how many you wanted and iirc you put in prices and the total too.
You’re making up stuff… Feel free to discuss with someone else since you just seem to want server side logic…
Server side logic is just ‘stuff that is done outside of the control of the visitor if a website’… If that calculations/validations/… Is executed on your server as server side logic or on your local PC when processing the order and accepting it /declining it/calculating the shipping cost and asking the customer to approve that finalised order doesn’t make a difference at all…
Sure it protects the logic of the signed offer… Because you don’t sign an offer that doesn’t stick with your rules/prices..?
Again… If your server side logic can check this a client side software on Our computer can check it too and accept or decline an order…
You need to calculate the stuff Anyway… If you do it to create a “order created with valid business logic” in the first place or if you do it when you validate the incoming orders doesn’t make a difference at all…
Yes, exactly. I’m trying to put myself in the place of an imaginative attacker.
Yes, and it’s a requirement. Anything less is dangerous. I can’t think of any merchant or service provider who would trust his sensitive, mission-critical infrastructure to such an arrangement. Can you?
Let’s progress beyond simple transactions. Let’s discuss proprietary business logic.
If all our business rules are exposed in client-side code, anyone can read, understand, and replicate them, including competitors.
Proprietary Business Logic
Pricing Algorithms
We calculate prices dynamically based on demand, time of day, user status, or other proprietary rules.
→ In a client-side-only model, these calculations are exposed and can be cloned or manipulated.
Discount Logic
Rules like “10% off for first-time users in Canada during weekends.”
→ A user can simulate any country or date if the logic is in JavaScript.
Product Matching or Recommendation Engines
Our core value might be in how we recommend products.
→ Competitors can copy or reverse-engineer the algorithm if it runs entirely in the browser.
Private Business Data
Inventory Levels
If we expose this data, competitors can track our inventory trends.
Supplier Contracts
Any internal rules about sourcing, margins, or third-party APIs must be kept secret.
Internal Performance Metrics
If our dashboard logic is in the client, we might expose conversion rates, retention data, etc.
Fraud Prevention and Abuse Detection
Rate Limiting
Users can bypass rate limits by tampering with headers or opening multiple browser sessions.
Bot Detection
CAPTCHA or behavioral checks can be spoofed if validation is only in JavaScript.
Usage Analytics Validation
All client-side analytics can be faked or manipulated. If you reward users for actions (like referrals), they can simulate actions locally.
Okay - if I sell honey for 6 bucks a glass I sell it for 6 bucks a glass…
And if I’m out of a certain type of honey I tell my customers “sorry I’m out of that type of honey”
I now understand the issue you have… But I honestly won’t invest any of my lifetime in trying to ‘solve this issue’… We’re living in different worlds my friend… I’m a simple person…
Are you aware of any business transaction website that relies solely on client-side logic? Personally, I believe it to be a fallacy. I’m certainly willing to be convinced otherwise, but you haven’t convinced me yet. I invite you to keep trying.
Consider me to be the attacker that you want to keep out. He gives not a whit for your feelings. He’s out to get you.
Yes something like Premium Features don’t really work on autonomi… You could put it into an encrypted Javascript Web component and just give the key out to your premium customers … But as soon as one of those customers leaks the key it’s as if it wasn’t encrypted in the first place (well… But ofc it comes with overhead to use that cracked premium feature..)
… Anti features don’t stick with open source… And I would consider everything running client side as more or less open source…
If you want to do such stuff you can use p2p communication with your customer to push arbitrary live-prices with opaque logics - as well as whole premium features as Javascript Web components… Not being stored on autonomi and (because they’re communicated via instant messages instead of being loaded from autonomi) only exist temporarily in your customers browser and are pretty hard to extract and make available to others/yourself without paying for the premium service…
Then ofc you would be running a “server” again =D and autonomi would just be the rendezvous server/host only a part of your service
But your shop still has the final say. All they can do is submit the order and pay for it. They are not running your internal shop software, just a shop front and ordering app. Your internal shop software runs inventory, order fulfilment, billing and so on
Obviously the shop will run their internal shop software on their own computer. Not too much different to a shop that takes email orders.
@InteXX you have to think differently about app design and architecture with autonomi. Using conventional techniques doesn’t fit.
You can’t stop a client entering junk orders, bypassing logic, etc, but that doesn’t mean an order isn’t validated. It just isn’t done by the code running on a server.
The back end of an online shop wouldn’t trust what the user has done, it would validate it. If there are discrepancies, the backend would suggest rejecting it.
In short, the app is split into two halves - the consumer facing side which suggests logic, but cannot be trusted, and a backend that validates whether the consumer facing logic has been followed.
Consider that apps also aren’t hosted in a traditional sense, they run locally. Security is completely different and needs no logins etc.
Performance metrics dont apply, unless the consumer complies to them. There is no server or requests in a traditional sense. Rate limiting is meaningless. Bots would be pretty pointless. Conversion rates are private/voluntary.
You have to think more deeply about this stuff, from a different perspective
