Pillar — Engineered for privacy: Connections
I'll describe the technical challenges faced by the Pillar Project team while designing our "Personal Data Locker": a way to interact with others and services while respecting users’ privacy and identity.
Pillar was meant from the beginning to be much more than a crypto wallet. It’s a radical shift in the way people interact with digital services: from discovery (the Pull model and semantic search) to interaction (decentralised user accounts). It was also meant from the beginning to include social features — "connections".
The first part of this series will deal with how we chose to implement connections: which tradeoffs we chose, the shortcomings we encountered, and what we plan for the future.
Centralisation vs ease of use
As we started designing the wallet, our goal was always ease-of-use above all other priorities. Rather than cutting and pasting Ethereum addresses, we wanted our users to connect using a ‘friends list’ mechanism, similar to Skype’s. Then people can just send to another person, rather than to an address.
This challenge illustrates the tradeoffs we must make as we balance privacy and ease of use. While interesting from a UX standpoint, I was uncomfortable with centralizing all the names and contact information. Pillar would have access to the full social graph for its users, something that goes against our ethos.
We looked at several options. Ultimately, Jegor, one of our star developers, came up with a good solution: the shared-secret approach.
In shared secret, each party randomly generates a secret (a really big number) and two parties exchange this secret between them. Here’s how it looks in Node.JS:
