Afaik, the PXE service is something users should run locally to preserve their privacy, but it sounds unrealistic to think every user would do it. In this doc page, it’s said, “For example, in future it could be run inside wallet software”. This would force most users to trust wallet providers as they can access private execution data inside the PXE they also run unless it’s a perfect black box that restricts the wallet provider from viewing what’s happening inside. I’m not sure if it is feasible for web wallets/extensions wallets that run PXE on the user’s behalf.
Correct me if I’m wrong regarding the above. My question is whether or not what PXE is responsible for can be done locally purely on the browser inside an app/wallet or through a web worker, instead. I’d like to know about the rationale: what makes PXE a server that has to be run by users?
Hello, PXE is expected to be run within a user’s software and in the vast majority of the cases user will not need to manage it in any way. It’s called a server simply because it exposes an HTTP API.
Hi thanks for the response! Good to hear that. But could you elaborate on how it could run within the user’s software without them bootstrapping/running it themselves? For example, how does a wallet provider, say browser extension wallet, somehow serve it in a way that doesn’t compromise the user’s privacy?
In case the communication with the PXE will be done over WalletConnect, it will not work because WalletConnect has payload limits and PXE RPC payloads are megabytes in size. Maybe a custom relay will work…
I implemented a POC of PXE over WalletConnect. There are a bunch methods that accept/return large payloads (>4 mb). I store them temporarily on firebase storage instead of sending over WalletConnect. And it works much slower than if I was connected to a PXE directly. Probably because requesting public data(e.g., txHash) over WalletConnect is not a good idea.