Content
@
https://ethereum.org
0 reply
0 recast
0 reaction
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
@polymutex.eth
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
@polymutex.eth
EAS being the Ethereum Attestation Service https://attest.org/
1 reply
0 recast
1 reaction
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
@polymutex.eth
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
