Hacker News Reader

Comment by marknadal | Hacker News Reader

Alex, could you clarify more? From initial glance of it and the blog it looks like either

(A) We have to go through your service, which clearly isn't decentralized.

(B) This somehow converts GraphQL queries to Ethereum lookups, somehow, all in the client? But the article says to use your endpoint, which suggests (A).

Could you explain how this is decentralized at all? I ask because I run one of the most popular P2P/decentralized projects and we have a GraphQL query layer on top ( https://github.com/brysgo/graphql-gun ) which happens all end-to-end on the peers.

I'd love to see more GraphQL dApp options out there, but I also want to make sure it doesn't lock people into a centralized service, when there are P2P alternatives.

Please let me know if I'm misunderstanding the API. If I'm not, maybe we could help you guys make it fully P2P? Cause this would be a really cool system.

View on HN

Hey Mark, thanks for taking a look and appreciate the feedback.

You can think of Cleargraph like a proxy for geth with some bonus features. You can point a local instance of Cleargraph to your own JSON RPC API endpoints using the helm charts we provide: https://github.com/dsys/charts. We're looking to make it even easier to use, so if you have suggestions please let me know.

We think it's important incorporate decentralized systems where it is practical (i.e. ENS). I'm aware of projects building the Ethereum blockchain secondary index features (for things like transaction filtering) in a decentralized manner, but haven't seen one live just yet. Maybe when they're live we can switch to them, or if you have ideas regarding Gun, would love to hear! :)

The primary "centralized" component is the privacy-preserving contact discovery, which we believe is a necessary evil. Afaict, any decentralized hashing scheme is susceptible to pre-image attacks due the space for phone numbers is small, which makes publishing the entire hashed address book leak everyone's info. Signal has a good write up on an improvement we may eventually incorporate that uses SGX: https://signal.org/blog/private-contact-discovery/

Okay, I think I understand more, you are saying you can run Cleargraph locally, and have things proxy to it rather than anybody else's server. Good, glad to hear that!!!

Yeah, I'm not really a fan of Signal's approach with the enclave and stuff. People wanting to have their phone numbers in the system is fine, but it certainly shouldn't be necessary (I don't assume it is, for you use?), and the system definitely shouldn't build on top of that assumption. Could you back up a little bit and explain how ENS and contact names are related to GraphQL queries?

Reply on news.ycombinator.com