4 ms·

Show HN: Human Headers

25 points by randomdrake 13y ago

RossM 13y ago
Nice idea, there is always humans.txt (which a surprising number of sites have, try google for example). http://humanstxt.org/ http://humanstxt.org/
- randomdrake 13y ago
  This idea was partially inspired by the humans.txt idea. Something that you could just install in your browser and leave on as your browse the web. By configuring it at the header level, it makes it pretty easy to simply apply it to all HTTP requests. This allows the info to be parsed whether it's coming from an API response, or a website response, or anything else.
zrail 13y ago
There's a little page here that also links to the chrome extension: http://www.humanheaders.org http://www.humanheaders.org
greenyoda 13y ago
What's wrong with putting this kind of information on the site's "About" page, which doesn't require any special browser extension to display?
- zrail 13y ago
  Absolutely nothing! Human Headers is intended to be in the same spirit as putting "are you reading this? we're hiring!" in an HTML comment in your source, or the X-Bender header that used to be part of Slashdot responses. It's a fun little thing.
- randomdrake 13y ago
  Well, I can think of a couple reasons: What developers want to communicate to one-another is often not the best material for an about page. Many (if not most) organizations do not feature all of their development staff on their about page. Organizations that do feature developers on their about page rarely attribute what things they developed in the organization. Developers don't just create things for organizations with about pages. Do developers wish that organizations were better about this? Sure!
  - greenyoda 13y ago
    OK, I see what you're saying. But if an organization doesn't want their developers sharing this kind of information on their main web site, wouldn't they also object to developers setting up what's essentially their own hidden web page? Do you expect that developers will seek corporate approval before adding these headers?
    - randomdrake 13y ago
      I would guess it would depend on the organization. I would also guess it would depend on the developer. I'm not an organization and this isn't an implementation. It's just a possibility.
whileonebegin 13y ago
At first, I liked this idea. It's an ego boost. But then I realized this extra HTTP header information is going out with every request, and really only serves to increase bandwidth. Yes, I know, what's 72 more bytes per request? Still. With humans.txt, the request is on demand.
- randomdrake 13y ago
  Great point. With the goal being that this can run in your browser as you browse the web, would it be more expensive to make an additional entire HTTP request to a, possibly non-existent, humans.txt for every single domain? Or simply pass additional bytes along? In the discussion on github[1] I raised the suggestion of possibly having the browser extension pass a special accepts or requests header so that it's only passed for people who have the extension installed. Then a simple conditional would be used for the server configuration instead of a statement. Does that satisfy concerns with "bloat" or are there other considerations, do you think? [1] - https://github.com/randomdrake/human-headers/issues/1 https://github.com/randomdrake/human-headers/issues/1
michaelmcmillan 13y ago
To me this shouldn't be a header. Why not create something like humans.txt? Better to do something you can opt into, instead of jamming an extra header on some guys poor cellular connection.
- randomdrake 13y ago
  There's nothing preventing anyone from jamming extra headers onto some guy's poor cellular connection. There's also nothing preventing competent developers from making sure this header isn't implemented in a way that it would affect endusers poorly. Maybe it's only on a single page? Maybe just some developer documentation? Maybe an API endpoint? No one is saying how this should be implemented, or even if it is the best idea. It's just a PoC and an idea to share amongst developers.
  - michaelmcmillan 13y ago
    To be honest, I don't understand your reply. I was merely making a suggestion to avoid using headers for unnecessary data. "No one is saying how this should be implemented, [...]". The project is called "human-headers". I don't see the need to point out what the goal of the proposition is.
coherentpony 13y ago
Why not put this information in the html? Then it's only available on one page.
thebouv 13y ago
I'm with the others who mentioned humans.txt. No header overhead (little as it is), no need to have access to the web server (apache, nginx, etc) (how many professional devs are also their own sysadmin?). If you want to build a plugin to display the info when you surf the web, make it read humans.txt as that is already in the wild.
Raphael 13y ago
Hmm, human headers. I like it.
dclara 13y ago
I can smell a little bit Semantic Web flavor, but this solution made it more automatic. But using a plug-in sounds like too much. About Semantic Web, I've got a short report here: http://bit.ly/JP3KQO http://bit.ly/JP3KQO. Drop me a line if you have comment.

25 points by randomdrake 13y ago

RossM 13y ago

Nice idea, there is always humans.txt (which a surprising number of sites have, try google for example). http://humanstxt.org/ http://humanstxt.org/

randomdrake 13y ago
This idea was partially inspired by the humans.txt idea. Something that you could just install in your browser and leave on as your browse the web. By configuring it at the header level, it makes it pretty easy to simply apply it to all HTTP requests. This allows the info to be parsed whether it's coming from an API response, or a website response, or anything else.

zrail 13y ago

There's a little page here that also links to the chrome extension: http://www.humanheaders.org http://www.humanheaders.org

greenyoda 13y ago

What's wrong with putting this kind of information on the site's "About" page, which doesn't require any special browser extension to display?

zrail 13y ago
Absolutely nothing! Human Headers is intended to be in the same spirit as putting "are you reading this? we're hiring!" in an HTML comment in your source, or the X-Bender header that used to be part of Slashdot responses. It's a fun little thing.
randomdrake 13y ago
Well, I can think of a couple reasons: What developers want to communicate to one-another is often not the best material for an about page. Many (if not most) organizations do not feature all of their development staff on their about page. Organizations that do feature developers on their about page rarely attribute what things they developed in the organization. Developers don't just create things for organizations with about pages. Do developers wish that organizations were better about this? Sure!
- greenyoda 13y ago
  OK, I see what you're saying. But if an organization doesn't want their developers sharing this kind of information on their main web site, wouldn't they also object to developers setting up what's essentially their own hidden web page? Do you expect that developers will seek corporate approval before adding these headers?
  - randomdrake 13y ago
    I would guess it would depend on the organization. I would also guess it would depend on the developer. I'm not an organization and this isn't an implementation. It's just a possibility.

whileonebegin 13y ago

At first, I liked this idea. It's an ego boost. But then I realized this extra HTTP header information is going out with every request, and really only serves to increase bandwidth. Yes, I know, what's 72 more bytes per request? Still. With humans.txt, the request is on demand.

randomdrake 13y ago
Great point. With the goal being that this can run in your browser as you browse the web, would it be more expensive to make an additional entire HTTP request to a, possibly non-existent, humans.txt for every single domain? Or simply pass additional bytes along? In the discussion on github[1] I raised the suggestion of possibly having the browser extension pass a special accepts or requests header so that it's only passed for people who have the extension installed. Then a simple conditional would be used for the server configuration instead of a statement. Does that satisfy concerns with "bloat" or are there other considerations, do you think? [1] - https://github.com/randomdrake/human-headers/issues/1 https://github.com/randomdrake/human-headers/issues/1

michaelmcmillan 13y ago

To me this shouldn't be a header. Why not create something like humans.txt? Better to do something you can opt into, instead of jamming an extra header on some guys poor cellular connection.

randomdrake 13y ago
There's nothing preventing anyone from jamming extra headers onto some guy's poor cellular connection. There's also nothing preventing competent developers from making sure this header isn't implemented in a way that it would affect endusers poorly. Maybe it's only on a single page? Maybe just some developer documentation? Maybe an API endpoint? No one is saying how this should be implemented, or even if it is the best idea. It's just a PoC and an idea to share amongst developers.
- michaelmcmillan 13y ago
  To be honest, I don't understand your reply. I was merely making a suggestion to avoid using headers for unnecessary data. "No one is saying how this should be implemented, [...]". The project is called "human-headers". I don't see the need to point out what the goal of the proposition is.

coherentpony 13y ago

Why not put this information in the html? Then it's only available on one page.

thebouv 13y ago

I'm with the others who mentioned humans.txt. No header overhead (little as it is), no need to have access to the web server (apache, nginx, etc) (how many professional devs are also their own sysadmin?). If you want to build a plugin to display the info when you surf the web, make it read humans.txt as that is already in the wild.

Raphael 13y ago

Hmm, human headers. I like it.

dclara 13y ago

I can smell a little bit Semantic Web flavor, but this solution made it more automatic. But using a plug-in sounds like too much. About Semantic Web, I've got a short report here: http://bit.ly/JP3KQO http://bit.ly/JP3KQO. Drop me a line if you have comment.