fermisea
Joined 3 years ago
Joined 3 years ago
This is of course flawed because a person can be coerced to share their ID. In which case you could have a system in which the vote itself is encrypted and the encryption key is private. Any random encryption key works and will yield a valid vote (actual vote = public vote + private key), so under coercion you can always generate a key that will give the output that you want, but only you know the real one.
We’re trying to create a single unified cli to every service on the planet, and make sure that everything can be set up with 3 clicks
By which measure were they less advanced? Tenochtitlan had a population of north of 200k when the Spanish arrived - bigger than most European cities at that time, bar a couple. When you read the chronicles of the conquistadores you realise how advanced they were in many ways compared with Europeans.
Th Maya were contemporary to and very similar to Greece in many ways - definitely more advanced in some aspects of mathematics and astronomy, and had an extremely complex architecture.
The gap wasn’t so big, and in some cases American cities were even more advanced - probably the complex sanitation system of most mesoamerican cities contributed to the biggest asymmetry of all - European cities were a Petri dish of filth and disease.
I don't think every graph needs a graph database. For 99% of use-cases a relational database is the preferred solution to store a graph: provided that we have objects and ways to link objects, we're good to go. The advantages of graph dbs are in running more complex graph algorithms whenever that is required (transversal, etc) which is more efficient than "hacking it" with recursive queries in a relational db.
For us, I've yet to find the need for a dedicated graph db with few exceptions, and in those exceptions https://kuzudb.com/ was the perfect solution.
The customer service itself was surreal enough that it was easier just to migrate to Anthropic
Overall the model is tra