3 ms·
Have you thought about defining an (optional) Integrator ID that would be dispensed by the central authority? There are a couple use cases here: 1- Some servic
by drusenko 15y ago
Have you thought about defining an (optional) Integrator ID that would be dispensed by the central authority? There are a couple use cases here:
1- Some services that are prone to abuse may require the Integrator ID to rate limit or prevent spam. The central authority could rely on a system that makes it difficult to obtain multiple IDs.
2- Some services may wish to provide a revenue share to integrators as an incentive -- we can imagine that Picnik is the service, and it collects revenue from usage through ads and premium upgrades, and opts to share that revenue with integrators.
- nikcub 15y agothis goes completely against the spirit of the web and the main reason why it was a success. I hate API keys. you have more then enough information about clients in each layer of the network stack to be able to block or throttle bad behaviour, we do not need to setup gatekeepers or control proxies throughout the web and butcher it
- drusenko 15y agoI respectfully disagree. As someone who deals a lot with spam and abuse issues, there's basically nothing left to identify unique clients on the web. IP addresses definitely don't work and CAPTCHAs don't work either (they're broken by hordes of humans in low-income countries solving them in near-realtime). How would you prevent automated abuse? It's become a very difficult problem.
- gbhn 15y agoA really key part of intents is that they're locally resolved. For centrally-resolved links, urls already work really well with the DNS system. Of course, features that prevent abuse will be a key support element for browsers. That's part of the rationale behind the choice of a pop-up window in Paul's demo for instance -- in-page elements have some vulnerabilities that pop-ups don't.