The hole in this system is that there is still no good mechanism for verification, at least in my eyes. What is to stop a tamperer from creating UUIDs not associated with a citizen? That's why I would consider tying to a person quite publicly.
At the same time, perhaps such a system reduces the surface area for bad actors. Now, perhaps, just the registry/database of UUIDs is a primary target.
Interesting. Sure, voter intimidation is particularly possible w/ public information, but I wonder why voters should be any less accountable for their decisions & actions than elected officials. Do not both owe some sort of responsibility to the country?
I have two open-ended questions on the subject of technology in U.S. voting.
(1) Why doesn't our electoral system require public disclosure of each voter's record? What would the ramifications of publishing each voter's identity & ballot online be? My thinking, like other comments here, is that a transparent voting system would make results more easily verifiable, if not easy to verify.
(2) At what point could we transition toward more of a democracy (in contrast to the representative, republican system) through the use of digital voting, which has a lower "barrier to entry" than turning out to a polling center? Particularly on nationwide issues like healthcare, I presume there are relatively few technological barriers to letting every citizen vote individually on a bill and immense political and social consequences. I can't fathom the outcomes -- do you know of any discussion of such a system?
Non sequitur: I've always wanted to see a "name brand" professional sports team run, down to the minutiae, by online fan voting. I know it's out there in small leagues already.
Do I understand correctly that a checkpoint is just a snapshot of the model at a point in time? i.e. "Here are the probabilities of each outcome given the characteristics I have observed already."
Also, what does "fully converged" signify? Are there points in the course of training the model at which it is more appropriate to "save" progress than at other times?
First, a huge congratulations to the Apollo team! You have more than delivered on the original promise of the Meteor group.
I am really excited about the proliferation of GraphQL APIs as they replace standard REST endpoints! When I heard that GitHub released a beta of their API with a GQL endpoint, I immediately wanted to try it out.
I learned, however, that it is extraordinarily difficult to connect to multiple GQL endpoints with a single Apollo client. I cannot even imagine how that would work. Should a single GraphQL endpoint have "clients" of its own, through which it could proxy requests to other endpoints? Should the front-end application have multiple clients, each with its own endpoint? There are a lot of easy, inelegant solutions which come to mind.
Several GitHub issues reference similar ideas, but there is no clear solution. Do you have any thoughts about how an application can conceptually replicate the simplicity of REST requests to multiple & diverse endpoints, when the endpoints are GraphQL-structured?