gates.wtf

We want to simplify access to personalized content for users, creators, and communities.

Today, we see a poor range of end-user experiences utilizing conditioned access, a narrow data source offering, and a troublesome developer experience.

We think there’s room for more custom condition logic, better end-user applications, and a smoother experience to set it up.

With gates, we expand the concept of access management by combining on- and off-chain identities, arbitrary conditions, and increased customizability. As a result, managing access and creating a world of personalized experiences cross-contexts has never been easier.

To protect users’ data, we’re utilizing DID (decentralized identities) for Ceramic, where only the user owns and can modify their (encrypted) data.

For creative communities and the humans who build them: let’s build a public good together.

To build Gates, we used Sign in with Ethereum and Ceramic to create a DID and let users store data connected to their identity. Since the data is on IPFS, we also encode it with a secret so only our server will be able to read from it and sensitive information is safe.

Furthermore, when reading the data from Ceramic, we decrypt it and only read the values on the server to determine if conditions are met.

The conditions that we create are supposed to be dynamic. Therefore, each condition is structured like 'service:method:args' that is converted to bytes and stored on-chain. With this structure, we can support any service we can think of.

When a user asks our API to verify, we decode the steps iterate through them, execute the connected method with our arguments and require all of them to pass. In the future, we are looking to implement OR/NAND/NOR. The API will only return a boolean to mimic a zkproof as much as possible.