Imagine a smart contract transaction or application that is hosted via ipfs and whose name is resolved by Cardano like a Handle. What kind of metadata is available to the smart contract or ipfs application like IP address, geographic data, wallet or browser version?
What should that mean?
Usually dApps/“smart” contracts consist of an on-chain and an off-chain part.
The on-chain part happens exclusively on the blockchain, not on a website, not on IPFS, not anywhere else. It validates if a transaction spending something lying on the contract’s address is okay. And that’s all it does. It just says yes or no. And for that decision it only has the information of inputs given to it by whoever built that transaction.
All information not immediately available on inputs to the transaction has to be given to this on-chain code by so-called “oracles”, which take information from the outside world (exchange rates, weather information, policy decisions, you name it) and put them into transactions, datums, … on the blockchain. Those oracles have to be trusted by the people running and using the contract.
The off-chain part builds the contract transactions. It could be written with all the technologies available in current (web) development. It could evaluate the IP address, even give it to the contract transaction in some way (although probably a very bad idea from a data protection viewpoint), do geo location on it (imprecise as it usually is), …
You could host the off-chain part on IPFS, but anyone else could just write different off-chain code constructing a transaction and submitting it to the Cardano chain/network. And they could just fake the information evaluated in the “real” off-chain code.
I think, a lot of dApps restrict who can execute contract transactions by requiring one of the inputs to come from a certain address, by a certain token being present, … (A survey on this would be interesting.) This makes them a lot less “decentralised” than advertised, of course.
And it reduces the value of having the off-chain code on IPFS dramatically. You can still see it, but if you are not one of the privileged people who have that key token, you cannot execute it. While if you are one of them, you can still roll your own off-chain code circumventing whatever the IPFS-published code tries to enforce.
Thank you for that thorough explanation!
In my imagination, this means Plutus or Marlow on chain, wallet or browser execution on client or some kind of script hosted on ipfs, client or even inside an NFT on chain.
So when a wallet constructs a transaction there is no standard data included that identifies wallet version or other client details like a web browser useragent or other metadata?
Take whatismyip as an example. Let’s say I want to create an html with javascript app that lives only on ipfs. When a person opens that file, their public ip is displayed. Traditionally on Web2, that is figured out server side. Since ipfs doesn’t execute any server side stuff then we can’t do that? Or does ipfs return you any kind of metadata?
No, there is no standard for that.
Of course, the usual dApps running on one specific website (which is very much still web 2, far from the promised revolution, they just connect to a crypto blockchain, not your credit card company and trade strange tokens instead of tangible goods), could do anything – record such data in their own database so that they can reference it to the transaction, put it inside the transaction in encrypted or in clear-text form, …
Note: I haven’t tried that. It would be cool for a truly decentralised dApp, though. And I don’t see a fundamental problem there. Would just have to try if such an IPFS-hosted app is allowed by the dApp-/CIP-30-capable wallet apps.
IPFS just contains static files. (They have to be static. They are identified by hashes, which would change if there content changed.) Those can be HTML or JS files. But there is no way to contact the own originating server there. You won’t even know if the browser is able to do IPFS natively or if one of the web gateways and which of them was used.
But there are some ways to find such information in Javascript.
Identifying the browser is rather easy: https://stackoverflow.com/q/9847580
Getting the public IP address is more complicated, since in usual setups the computer, let alone the browser, doesn’t even know it (only your router connecting to the ISP knows it): https://stackoverflow.com/q/391979 All the answers contact remote third-party servers to get the IP address.
I found a tiny bit more info but not what I’m hoping for. Do IPFS nodes have a user agent string? - Old FAQ - IPFS Forums
Seems reasonable that there is no default on chain or transaction data given the desire to save space plus the general anonymity in crypto.
The fact that ipfs doesn’t exchange any metadata like IP address or useragent is surprising, that would be useful in developing web3 apps.
Totally different topic. That is about identifying IPFS node versions. HTML/JS off-chain dApp code would not reside and not run on a specific IPFS node.
The whole point of IPFS is that it can be retrieved from an arbitrary node.
And it would run on the user’s browser. And that would still provide things like the user agent string to the Javascript retrieved from IPFS. It really doesn’t care (much) if it comes from a website, a local file, or IPFS (except for some security rules).
Interestingly the JavaScript runs in Brave on my localhost but not once hosted on ipfs
ipfs://QmVHNjbMZvG4x2au35qeR9jb1q2RbqnpqsbQRBNnWXhGA6
https://gateway.pinata.cloud/ipfs/QmVHNjbMZvG4x2au35qeR9jb1q2RbqnpqsbQRBNnWXhGA6
Hmm, seems to depend a bit on the gateway (and how it embeds the hosted content).
The gateway you are using gives
for me while https://ipfs.io/ipfs/QmVHNjbMZvG4x2au35qeR9jb1q2RbqnpqsbQRBNnWXhGA6 gives only:
I haven’t found a gateway, where it really works.
But I also get
when using local resolution in Brave. … 
My goal is to get away from having to call any web2 infrastructure. Sadly there’s two counts of that here, the ipfs gateway and the call to ipify. Ideally Brave would execute the JavaScript when called via ipfs:// and there would be a way for the node serving the file to supply the public ip of the requester
I guess in the case where you have added the ipfs client to brave then you are the node and you’d want info from the penultimate node.
Ah, it works for me if I turn off the ad blocker in Brave.
I don’t quite understand what you want to do with the handle there. Up to now, it’s only an image and has nothing to do with the address that is really associated with the handle. (BTW: Nice collection of ADA handles there.)
Why? To reduce dependencies on external services continuing to function? Or for ideological reasons?
It does?
Won’t work if you use a local IPFS node, which somehow is the goal to avoid relying on gateways.
I envision a day where the browser resolves $handles to an address much like DNS does. And so I was trying to produce the same functionality as current sites that regurgitate client info.
Thanks, they are my babies!
Both, yes
Does it for you? I didn’t for me. Maybe ill try the pop-up blocker.
Maybe there is a need for a decentralized technology that could allow you identify and share your IP and other client info.
All those things are sent by your browser when requesting anything. The image is really some computer code that takes that as input and outputs an image.