Degengineering | $DGNGX on Farcaster

Content pfp

https://ethereum.org

0 reply

0 recast

0 reaction

Degengineering | $DGNGX pfp

Degengineering | $DGNGX

@degengineering.eth

The beta for Web3PGP is open and live on Kraken Ink testnet. Come & Play. Feedbacks and reactions are welcome 🙏 https://w3pgp-3izi8135u-gbdevws-projects.vercel.app/

1 reply

0 recast

26 reactions

polymutex pfp

Very cool, I've been looking forward to something like this for a while. Qs: - Is it using EAS for publishing to the chain, or custom events? - Any plans to import existing keys from the MIT keyserver? - Can I gpg --fetch-keys from this registry, or are you planning to send an upstream GnuPG patch to add this feature?

2 replies

0 recast

1 reaction

polymutex pfp

EAS being the Ethereum Attestation Service https://attest.org/

1 reply

0 recast

1 reaction

Degengineering | $DGNGX pfp

Degengineering | $DGNGX

@degengineering.eth

I'll take time to explore EAS. About my usecase (W3PGP), there is no validation of the OpenPGP messages posted onchain: it is not doable so users have to do it offchain - OpenPGP has automated verification procedures for that. I was thinking about creating some kind of oracle to tell which keys are valid, revoked, etc... do the offchain work then post the result onchain and make it available to everyone (this can act as a feedback loop). The second enhancement will be some kind of registry where key owners can bind an identity to their published public key. I have to think more about it: with what level of verification? what level of autonomy/decentralization? With ENS/EAS/Other? Anyway thank you for what you have shared, I'll definitely take a look at it and continue building 😏

1 reply

0 recast

1 reaction

polymutex pfp

I think adding an oracle for PGP message validation would remove one of the positive attributes of blockchains: censorship resistance. The oracle could suppress a key, or suppress a revocation or a co-signature, by denying the truth about the latest state of a key or simply refusing to posting updates about what it has verified. To prevent this, users need to be able to permissionlessly post OpenGPG data and have it verifiable onchain. IMO to implement such verification, if it's too expensive to do onchain currently, it can probably be done in ZK then post+verify the proof onchain. That ZK verification itself might be too expensive still at the moment, but I hear there may be some ZK-ish precompiles coming to the EVM that may make it cheaper in the future. Solutions like a Cartesi rollup might help in the interim; that lets you verify it in a RISC VM and allow others to challenge you if they disagree with your execution result.

1 reply

0 recast

2 reactions

Degengineering | $DGNGX pfp

Degengineering | $DGNGX

@degengineering.eth

Yes you are right: this would be "off" the trustless infrastructure as my oracle can introduce bugs, errors and frauds (after all, OpenPGP is a protocol with different implementations). If I do that, I will be crystal clear that we are so back in web2.5 🤣 I have to finish exploring EAS first (it is interesting but big so I'll need time to read it and find what I can do with it). ZK are on my list as well but currently, I do not have enough knowledge to fully understand your answer and how to apply it. Maybe soon 🙂

1 reply

0 recast

1 reaction

polymutex pfp

ZK proofs lets you prove that the result of some function on some input is equal to some output, without the caller having to re-run the function. Here, the "function" would be the computation of the current set of valid OpenGPG keys, and the input would be (previous set of valid OpenGPG keys, new OpenGPG data message being appended). So given someone posting new OpenGPG data onchain, you could run OpenGPG loaded with all previous keys, run `opengpg --import` with the newly-added message, get the resulting keyset, and post a ZK proof of this result onchain. This way, observers won't have to trust that you evaluated the effect of adding this message correctly, and won't need to perform the same computation that you did. The ZK proof is sufficient evidence. Hope this makes sense!

1 reply

0 recast

1 reaction