233 karma · joined June 9, 2015
Not necessarily. Look at the reprojection trick that lots of VR uses to double framerates with the express purpose of decreasing latency between user movements and updated perspective. Caveat: this only works for movements and wouldn't work for actions.
AuthZed is changing the way top tier companies add rich permissions experiences to their applications. Modeled after Google's Zanzibar, AuthZed offers a low-latency, high-scale permissions system, that scales to millions of QPS with milliseconds of latency.
Apply using https://www.ycombinator.com/companies/authzed/jobs
If the roles above aren't for you, we're adding new roles regularly so keep your eye on our work at a startup page!
This exactly. They don't reduce the resolution too much, but it's visible to an outside observer watching on a monitor.
This is not at all true. All of the AVP, the Quest Pro, and the PSVR2 do eye tracking based foveated rending. They lower the clarity of the things you're not looking at. And reviewers say it works perfectly, like magic. They are unable to "catch" the screen adjusting for what they're looking at.
https://bigthink.com/strange-maps/parking-lots-eat-american-...
> Detroit was, or is, Motor City. Its center can pull off another automotive-related nickname: Parking Central. Fully one-third of downtown Detroit is dedicated to letting cars do what they’re not designed for: standing still.
20 milliseconds at the 99.5 percentile and five-nines (99.999) of uptime. Those are our goals for our globally-distributed permissions system as a service. If you’re interested in helping us achieve these goals, we would like to talk. We’re currently using best-in-class open source solutions on the public cloud for delivering this vision: Kubernetes, CockroachDB, PostgreSQL, Prometheus, Pulumi, Cuelang, Let’s Encrypt, etc.
As part of our small team, you will help to build our application platform, delivery pipelines, data architecture, and the application itself. You should be passionate about both software development and infrastructure. In this role you will be required to code. You will also participate in our on-call rotation which is responsible for the health of our highly-available globally-distributed service.
About the Company
At Authzed, we’re solving application permissions. We’re building a highly available, highly reliable, multi-tenant permissions system as a service which is deployed globally. Modeled after Google’s Zanzibar, our core open-source component SpiceDB is revolutionizing the way developers build powerful, flexible permissions into any application. With our founding team formerly of Red Hat and CoreOS, open-source is deeply ingrained in the fabric of our company.
It might even be this exact one: https://www.youtube.com/watch?v=9vNRY6natiY
Very sorry about the "work in progress" moniker on our v1 APIs. We developed the v1 APIs based on our real-world experience running the Authzed.com service for ourselves and others, and we just finished their implementation and porting everything over. We will remove that warning ASAP!
One thing to note though, is that we thought about calling our v1 APIs v5 or something, because we didn't want to give the impression that they will never change. We intend to continue to improve the APIs, sometimes in backward incompatible ways, but will just keep the existing APIs around for a very long™ period of time, similar to how Stripe handles their API versioning.[1]
[0] https://authzed.com/blog/acl-filtering-in-authzed/
[1] https://buf.build/authzed/api/docs/main/authzed.api.v1#authz...
The simplest choice to get started with is to add it directly to your application logic. The main pro of this solution is that you can directly handle the semantics of when and how to add/remove permissions. For example, it's sometimes safe and idempotent to write permissions for data that may fail to commit, because permissions for the data will never be queried in the future. You can also directly control the management of ZedTokens and effectively eliminate the new enemy problem[0]. As far as I know, this is how Zanzibar is used within Google.
Solutions which tail a primary source of truth, such as the database logs, kafka topic, event queue, etc. may perform better in some applications where eventual consistency on permissions is ok. With these systems you are adding some delay in between writing the data and the permissions, which can open you up to new enemy or require UX compensation like adding data on the client side and hoping the permissions replicate before they are ever queried for real.
We will work to write a guide that talks about some of these architectures and their pros and cons.
The docs are built around the idea of using Authzed.com, the hosted SpiceDB solution for protecting your first app. We will try to put together a guide around self-hosting SpiceDB.
For usage from CloudFlare workers and other non-http/2 friendly environments, we're considering adding a gateway which can speak regular http natively. Bolt-on solutions like grpc-web or more invasive solutions like adding twirp support will be considered. Do you have a preference?
Right now, the business model is around running a single SpiceDB service globally so that you as a user don't have to figure out how to deploy and manage the service at scale.
This service is especially tricky to run because of the need for low latency, high availability, and a single globally replicated service. For an individual company to run HA clusters all over the world would be cost prohibitive, but when all Authzed.com customers share the cost it becomes more reasonable.