> To validate the quality of the algorithms at scale, their performance was evaluated by collecting 2.5 million pairs of high-resolution infrared iris images from 303 different subjects. These subjects represent diversity across a range of characteristics, including eye color, skin tone, ethnicity, age, presence of makeup and eye disease or defects.
> It is important to note that many health conditions, like cataracts to a certain degree, do not impede iris biometrics. Already today, iris biometrics surpass the inclusivity of other PoP verification alternatives like official IDs since less than 50% of the global population has digitally verifiable identities. However, if the proof of personhood mechanism becomes essential for society, it is important that eventually every single person can verify if they want to. Although not currently established, there could be specialized verification centers to facilitate alternative means of verification for individuals with eye conditions, via e.g. facial biometrics. The introduction of alternative means of verification for World ID could potentially create loopholes.
So eyeless people have to jump through extra hurdles that the rest of us don't have to. The Worldcoin grand misvision is that their terrible World ID would be required to get government benefits, and yet makes it harder for some of the people who most need them to get them.
I don't 'believe in' or support Worldcoin, but I don't think it's realistic to expect any one verification system will serve everyone who needs/wants any given service. Government ID, and even governments themselves don't serve everyone in need.
They're talking about using it for things like government benefits.
The moment they opened that can of worms, they're on the hook for making it serve, at the minimum, everyone that the current government mechanisms serve.
I'm using eyeless people as an example here, because it's the obvious case of people who can't possibly use Worldcoin even if they wanted to. The direct implication today is that blind people would lose their benefits under Worldcoin. If that's not true, then either.
1. Government doesn't actually need Worldcoin's ideas as much as Worldcoin hopes they do.
2. There are workarounds that don't require Worldcoin, in which case let's just use those in the first place.
'Blind' is a much larger category than 'eyeless', and I think you're making the implicit assumption that the government's current identity verification methods work much better than they really do. Just look at the HN post yesterday about the woman whose identity was stolen and used to import 'counterfeit' goods. Worldcoin's system may not be perfect, but having it as an option might have helped in a case like that.
Again, I am not a Worldcoin booster, but I also didn't say it had the same disadvantages. Everything has trade-offs, and Worldcoin has definite advantages against using a small piece of plastic with a bad 2D picture on it.
A government ID is a lot more than that. I have an official ID card that has:
- A bunch of personal identifying data including a unique number (which is as much of a secret as my name or my date of birth)
- A bunch of old-timey security stuff like thumbprint and signature
- An RFID chip containing all this info, ICAO 9303 compliant
- A PIN protected certificate that I can use to sign documents digitally
- Several security measures to make falsifying it very hard
Everybody who lives in this country has one of these, and these features are not uncommon for ID cards to have in other countries. It also has the full backing of the state, which means that if I lose it I can easily get a new one, and is very illegal for somebody to use it to impersonate me, or to create a false one.
I'm not sure what advantages I or my fellow citizens would gain by moving to a distributed system in charge of some foreign capitalists who have never even been to this country.
Maybe, but who knows? The Worldcoin people are making this a problem, so it's up to them to fix it without increasing the burden on people who can't use it as-it.
Ah so this is why my hobby open-source project of 6+ years has been getting a surge in traffic :) https://github.com/opendnd
Totally unrelated to this of course, but very cool to see all the same. The OGL has been a cornerstone of innovation in this space and without it a lot of us would be dead in the water.
To me I think the approach of Hotwire, LiveView, Django-HTMX etc. is more interesting for a Go framework, since websockets/async are baked into the Go language.
In other words, render the HTML in Go and ship the diffs to a small blob of JS running in the client over a websocket, instead of baking a whole React build into your server-side app. Much simpler toolchain this way, much easier to reason about.
I appreciate that this is a fairly different solution; one of the author’s explicit goals is that it should “Feel like using a modern JS framework”. Personally I’d rather have it “feel like I’m using Django / Rails”, except with most of the superpowers that were historically FE-framework-only.
Where nextjs kicks ass is that coding front end interaction (sans back end interaction) and doing interaction in response to server feels almost identical.
There is no “ugh ok … better set up react now” feeling to make say an interactive chart because it was always there.
Similarly there is no “ugh ok … better set up a backend now” feeling you get using create-react-app as it was always there.
There is almost no mental gear switch as you switch from front to back to front.
The only small negative is you need to be careful what that first “server side” render produces and what it can access. But that is also part of the magic, as you can fine grain control the initial flash of content. For example include the layout/menus. Or include a cached view of a list that then updates on final render.
It just feels so well integrated more than any other framework I have tried (like aspnet mvc or RoR for example).
It will be hard to beat: If you want to beat it in Go you need at least a good Go->JS transpiler so you can use the same language. But even then anything other than JS/Typscript means I need a mental modal of what the transpiler is doing. I don’t get a free pass
on understanding JS or the DOM.
Agreed. I love Next.js and used it religiously for the first couple years. I'm not trying to beat Next.js or any framework. There's plenty of space in the web ecosystem for alternative solutions.
I hope is that Go <=> JS/Svelte won't be too much of a context switch for folks.
I'm not planning on innovating as hard in the frontend space as Next.js. I'll probably just stick with SSR, add support for pre-rendering and build up the client-side runtime with features like prefetching and client-side routing. If something really cool comes along, we'll see.
I'll instead focus on the area where Next.js neglects: backends. DB workflows, mailers, queues, scheduling, pubsub are all coming to Bud.
How realistic do you think it is that you'll be able to complete all the what-abouts everyone is proposing to you before you get burned out? Genuine question.
Yes, exactly. It is often required as a condition of employment and (pre-COVID) in the hospital I am aware of, if you would/could not get the flu shot then you were required to wear a surgical mask at all times during that year.
"By occupation, flu vaccination coverage was highest among physicians (98.0%), nurses (92.0%), pharmacists (90.6%), and nurse practitioners and physician assistants (88.8%)
Flu vaccination coverage was lowest among other clinical health care personnel (81.7%), assistants and aides (72.4%), and nonclinical health care personnel (76.7%)."
This is something I did for our DnD group, the map was created collectively in a photo editing tool and then split up with MapTiler (https://www.maptiler.com/) which generates HTML/CSS/JS you can throw up on a server I have here: http://maps.opendnd.org/ao/. The main issues I found are some skewing from the original map and some pretty bad pixelation when you get to some of the lower levels. That could all be remedied with a better vector graphic for the map -- something to work on in the future.
Very cool, I especially like that it’s faithful to the DMG. I saw the mention of Donjon, I’ve used the Donjon tools for years and have always loved using them but felt the lack of persistence and interconnectedness was missing.
It’s why I’ve been working on something similar over the past few years and dungeon generating is definitely on the roadmap. It’s called OpenDnD and it’s attempting to be a complete set of open source DM and player tools. The first 5 tools are fairly useable but very much still beta. For those interested, the code’s up on GitHub: https://github.com/opendnd/opendnd.
Awesome, contributors would be greatly appreciated :) I'm still working on writing up the main roadmap (it's a very ambitious project) to make it easier for new contributors. Currently, it'll be mostly focused around 5e although I'd love to add support for other editions as well. Especially for things that are highly useful to have support for like character sheets. But I see other things like supporting older versions of the generators described in the DMG will be a bit more difficult to do as it would require more fundamental changes to the code.
So, is there any reason to roll your own from scratch rather than contributing to one of the existing projects?
If it's to have your own project that you have complete control over, or if it's just to do something fun yourself, that's totally cool. I'd just like to know.
Great points, I'd be happy to give some background. I originally started working on the project just for our DnD group about 5 years ago. At that time there weren't many other projects available or if so I wasn't aware of them. It was mostly Donjon and a few others that were available and none were built as individual packages that could be composed together and weren't open source. The GitHub org you see now is actually already a merger of existing efforts that were started by other developers who were working on a character sheet generator. The opendnd repo was only started recently as the tools have grown over the years and needed a sort of all-encompassing project.
That being said, I'm aware that other projects are out there now that have similar goals -- some further along than us as it's mostly been me working on it in my free time. However, I would say that our design decision is pretty different from the others in that each component is designed to be a separate standalone tool that can be used as a component to build other things. Because the end goal is so ambitious I think this design decision is critical if the project is ever to get close to achieving that goal. If I had to summarize in one sentence what we're trying to achieve, it's kind of a Dwarf Fortress level of detail but fully open source and fully interconnected components.
Awesome work! One thing I would love to see here would be more examples on what each module generates, since it doesn't really provide those at the moment.
Thank you for the suggestion, I'll add some example outputs. Perhaps something like asciinema may be useful. I used to have some animated gifs of a recorded terminal session but I removed it as so many changes were happening it got outdated fast.
